Game system, management program, server, and game processing method

Abstract

This invention provides a game system, management program, server, and game processing method that enable the determination of which users to allow to participate in a session based on priority and other factors. [Solution] When the total number of accounts participating in a game session as operators and accounts participating as viewers meets a predetermined condition, at least one account participating in the game session as a viewer is removed from the game session, and the transmission of game information to the information processing terminal corresponding to the removed account is stopped.

Description

Technical Field

[0001] The present invention relates to a game system, a management program, a server, a game processing method, etc. that perform processing using a virtual space.

Background Art

[0002] Conventionally, there is a game system in which a game player playing an online game can be watched by other players (for example, see Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in the game system disclosed in Patent Document 1 above, when the number of game players and viewers increases, the server side cannot determine which player participates in the game.

[0005] Therefore, an object of the present invention is to provide a game system, a management program, a server, and a game processing method that can determine which user participates in a session according to priorities and the like.

Means for Solving the Problems

[0006] In order to achieve the above object, the present invention can adopt configurations such as the following (1) to (15) for example.

[0007] (1) One example of the configuration of the game system of the present invention includes at least one server that manages a game session and a plurality of information processing terminals that can connect to the server, and allows accounts corresponding to each of the information processing terminals to participate in the game session and execute the game among the accounts. In response to a participation request received from an information processing terminal, the server allows the account corresponding to the information processing terminal to participate in the game session as at least one of the operators who operate the player object corresponding to the account in the game and at least one of the viewers who view the in-game content in the game, transmits game information regarding the state of the game to the information processing terminals corresponding to the accounts participating in the game session, and updates the game information based on update information received from the information processing terminals. The first information processing terminal among multiple information processing terminals sends data to the server, including the first account corresponding to the first information processing terminal, as a first participation request to participate as an operator in a game session based on the first operation input of the user; sends data to the server, including the first account, as a second participation request to participate as a viewer in a game session containing in-game content among multiple game sessions based on a second operation input specifying in-game content to be included in one of the game sessions among multiple game sessions; if the first account is participating in the game session as an operator, it generates a game space including the first player object corresponding to the first account based on the game information, performs first virtual camera control to control the virtual camera in the game space based on the position of the first player object, and sends update information to the server based on the state of the game space; if the first account is participating in the game session as a viewer, it generates a game space including the in-game content specified by the second operation input based on the game information, updates the state of the in-game content based on the game information, and performs second virtual camera control to control the virtual camera in the game space based on the position of the in-game content specified by the second operation input.Furthermore, if the total number of accounts participating in a game session as operators and accounts participating as viewers meets a predetermined condition, the server will remove at least one account participating in the game session as a viewer from the game session and stop transmitting game information to the information processing terminal corresponding to the removed account.

[0008] According to the configuration described in (1) above, when the number of players who participate in a game session by manipulating player objects and viewers who participate in a game session by viewing in-game content increases, the system manages which accounts can participate in the game session, making it possible to determine which accounts can participate in the game session based on priority, etc.

[0009] (2) In the configuration described in (1) above, the server may further allow a second account to participate in the game session as an operator when it receives a first participation request from a second account corresponding to a second information processing terminal among a plurality of information processing terminals. The first information processing terminal may send a second participation request to the server to participate as a viewer in the game session including the second player object, based on a second user input specifying the second account or a second player object corresponding to the second account.

[0010] According to the configuration described in (2) above, the first account can be allowed to participate in the game session as a viewer who is viewing the second player object corresponding to the second account.

[0011] (3) In the configuration of (1) or (2) above, the server may include means for managing a first game session and means for managing a second game session among a plurality of game sessions. The means for managing the second game session may, upon receiving a second participation request from a first account participating in the first game session as an operator to participate in the second game session as a viewer, allow the first account to participate in the second game session as a viewer. The means for managing the first game session may, upon receiving a first participation request from a first account participating in the second game session as a viewer to participate in the first game session as an operator to participate in the first game session as an operator.

[0012] According to the configuration described in (3) above, the operator of the first game session can switch to being a viewer of the second game session and have the first account participate.

[0013] (4) In the configuration of (3) above, the means for managing the first game session further stores the number of accounts participating in the first game session as operators and the number of accounts participating as viewers, and does not need to subtract the number of accounts participating in the first game session as operators when an account participating in the first game session as an operator joins the second game session as a viewer.

[0014] According to the configuration described in (4) above, it is possible to prevent situations where, while temporarily participating in another game session as a viewer, certain conditions are met and the user is unable to return to the original game session as an operator.

[0015] (5) In the configuration of (4) above, the means for managing the first game session may further subtract the number of accounts participating in the first game session as operators in accordance with the amount of time that has elapsed since the first account joined the second game session as a viewer.

[0016] According to the configuration described in (5) above, it is possible to prevent a game session participation slot from being occupied for an extended period of time when the user is not participating as an operator.

[0017] (6) In any one of the configurations described in (3) to (5) above, the first information processing device may further, when a first account participates in a second game session as a viewer from a first game session in which the first account is participating as an operator, place a first object with a different appearance from the first player object at a position based on the position of the first player object in the game space of the first game session, send update information including first object position information regarding the position of the first object to the server, and when a second account corresponding to the second information processing terminal among the multiple information processing terminals participates in the first game session as an operator, generate a game space including the first object at a position based on the object position information.

[0018] According to the configuration described in (6) above, other accounts can know that an account is participating as a viewer.

[0019] (7) In the configuration of (6) above, the first information processing device may further generate a game space in which, when the first account joins the first game session as an operator from a second game session in which the first account is participating as a viewer, the first player object is placed in place of the first object at a position based on the first object position information.

[0020] According to the configuration of (7) above, by placing the first object in the game space, when returning as an operator, the first player object can be returned to the position where the first player object was placed before participating as a viewer.

[0021] (8) In the configuration of (6) or (7) above, the second information processing terminal may further restrict the change of the state of the first object based on the user's operation input.

[0022] According to the configuration of (8) above, it is possible to prevent the position where the first player object is to be returned from being changed during participation as a viewer.

[0023] (9) In the configuration of (3) above, when the means for managing the second game session causes the first account to withdraw from the second game session based on the second game session satisfying a predetermined condition after the first account participates in the second game session as a viewer, the means for managing the first game session may allow the first account to participate in the first game session as an operator.

[0024] According to the configuration of (9) above, when an account participating as a viewer in a game session withdraws, the account can be returned and allowed to participate in the game session in which the account participated as an operator.

[0025] (10) In any one of the configurations of (1) to (9) above, when the server further satisfies a predetermined condition, it may determine an account to withdraw from the game session based on the length of time elapsed since participating in the game session that satisfies the predetermined condition as a viewer.

[0026] According to the configuration in (10) above, when removing viewers from a game session, it is possible to select which viewers to remove based on the amount of time they have been watching.

[0027] (11) In any one of the configurations (1) to (10) above, if the first account is participating in the first game session as an operator, the first information processing terminal may place a second object in the game space based on the user's third operation input and send update information including second object position information regarding the location of the second object to the server. The server may further store the first account as a placer in association with the first game session based on the receipt of the update information including second object position information, and if the first game session meets predetermined conditions due to the receipt of a second participation request from the first information processing terminal corresponding to the first account stored as a placer to participate in the first game session as a viewer, the server may remove an account that is not stored as a placer but is participating in the first game session as a viewer from the first game session.

[0028] According to the configuration described in (11) above, accounts that have already placed a second object in the game space of a game session can be given priority and allowed to participate as viewers of that game session.

[0029] (12) In any one of the configurations (1) to (11) above, if the first information processing terminal is participating as an operator in the first game session among multiple game sessions, it may place a second object in the game space based on the user's third operation input, send update information including second object position information regarding the position of the second object to the server, and if the first account is participating in the first game session as a viewer in response to the user's second operation input specifying the second object, it may send a first participation request to the server in response to the user's fourth operation input to participate in the first game session as an operator. The server may allow the first account to participate in the first game session as an operator in response to the first participation request sent in response to the fourth operation input.

[0030] According to the configuration in (12) above, when an account that has already placed a second object in the game space of a game session is viewing the second object, it is possible to define the user action required to allow that account to participate in the game session as an operator.

[0031] (13) In any one of the configurations described in (1) to (12) above, the first information processing terminal may, when the first account is participating in the first game session as an operator, place a second object in the game space based on the user's third operation input and send update information to the server including second object position information regarding the location of the second object. The second information processing terminal among the plurality of information processing terminals may, when the second account corresponding to the second information processing terminal is participating in the first game session as an operator, send a second participation request to the server to participate as a viewer in the game session in which the first account is participating as an operator, based on the user's fifth operation input to the second object.

[0032] According to the configuration described in (13) above, an account that has placed a second object in the game space can easily participate as a viewer in a game session in which the account is participating.

[0033] (14) In any one of the configurations (1) to (12) above, the first information processing terminal may, when the first account is participating in the first game session as an operator, place a second object in the game space based on the user's third operation input and send update information to the server including second object position information regarding the location of the second object. The second information processing terminal among the plurality of information processing terminals may, when the second account corresponding to the second information processing terminal is participating in the first game session as an operator, acquire an item corresponding to the second object based on the user's fifth operation input to the second object, and based on the sixth operation input in which the user uses the acquired item, send a second participation request to the server to participate as a viewer in the game session in which the first account is participating as an operator.

[0034] According to the configuration described in (14) above, an account that has placed a second object in the game space can hold an item that allows it to easily request to join a game session as a viewer.

[0035] (15) In any one of the configurations described in (1) to (14) above, the first information processing terminal may further send a second participation request to the server specifying a second account corresponding to a second information processing terminal among multiple information processing terminals. If the second account is participating as a viewer in a third game session among multiple game sessions, the server may, in response to the second participation request, allow the first account to participate as a viewer in the third game session.

[0036] According to the configuration in (15) above, if the account to be viewed is participating as a viewer in another game session, it can participate as a viewer in that other game session.

[0037] Furthermore, the present invention may be implemented in the form of a management program, a server, and a game processing method. [Effects of the Invention]

[0038] According to the present invention, it is possible to determine which accounts will participate in a game session based on priority, etc. [Brief explanation of the drawing]

[0039] [Figure 1] This diagram shows an example of the main unit 2 with the left controller 3 and right controller 4 attached. [Figure 2] This diagram shows an example of the state in which the left controller 3 and right controller 4 have been removed from the main unit 2. [Figure 3] A six-view drawing showing an example of the main unit 2. [Figure 4] A six-view drawing showing an example of the left controller 3. [Figure 5] A six-view drawing showing an example of the right controller 4. [Figure 6] Block diagram showing an example of the internal configuration of the main unit 2. [Figure 7] Block diagram showing an example of the internal configuration of the main unit 2, left controller 3, and right controller 4. [Figure 8] Block diagram showing an example of the configuration of an information processing system. [Figure 9] Block diagram showing an example of the configuration of server 102. [Figure 10] This diagram shows an example of a game image displaying multiple player character PCs placed within the same game space. [Figure 11] This diagram illustrates an example of generating an array of terrain objects L1 in the game space by moving multiple terrain objects. [Figure 12]This diagram shows an example of how terrain objects La, edited into a single block, are displayed. [Figure 13] This diagram shows a game image illustrating an example of the first stage of the action in which the first player character PC1 places the first area setting object A1 within the game space. [Figure 14] This diagram shows a game image illustrating an example of the second stage of the action in which the first player character PC1 places the first area setting object A1 within the game space. [Figure 15] This diagram shows an example of the first region R1 that is set when the first region setting object A1 is placed in the game space. [Figure 16] Figure showing an example of the shape of the first region R1. [Figure 17] This figure shows an example of a partition information image displayed on display 12. [Figure 18] This diagram shows an example of a game image illustrating the state of player character PC1 entering area A. [Figure 19] This diagram shows an example of a game image where the piece OBJp1 is placed in section A. [Figure 20] This diagram shows an example of a game image where the first user is watching the area setting object A1 in section B as a viewer. [Figure 21] This diagram shows an example of a game image where the first user is watching player character PC3 in section C as a viewer. [Figure 22] An example of a game image displayed when a user corresponding to a target of viewing is also a viewer of another target of viewing. [Figure 23] A diagram showing an example of the capacity requirements for each section. [Figure 24] A diagram showing an example of the trend in the number of participants in section A and section B. [Figure 25] This diagram shows an example of a data area set in DRAM85 of game system 1. [Figure 26] A flowchart showing an example of game processing performed by game system 1. [Figure 27]A subroutine showing an example of player character control processing in step S124 of Figure 26. [Figure 28] Figure 27 shows an example of a subroutine for the transition process to spectator mode in step S146. [Figure 29] A subroutine showing an example of the dwelling area movement process in step S148 of Figure 27. [Figure 30] A subroutine showing an example of spectator mode processing in step S151 of Figure 27. [Figure 31] A subroutine showing an example of the spectator area movement process in step S187 of Figure 30. [Figure 32] Figure 30 shows an example of a subroutine for transitioning to a stay mode in step S190. [Figure 33] A subroutine showing an example of other player character control processing in step S124 of Figure 26. [Figure 34] This figure shows an example of a data area set in the storage unit 105 of the server 102. [Figure 35] A flowchart showing an example of the first half of the process executed on server 102. [Figure 36] A flowchart showing an example of the latter half of the process executed on server 102. [Modes for carrying out the invention]

[0040] The following describes a game system according to an example of this embodiment. An example of the game system 1 in this embodiment includes a main unit (information processing device; functioning as the game device main unit in this embodiment) 2, a left controller 3, and a right controller 4. The left controller 3 and the right controller 4 are detachable from the main unit 2. In other words, the game system 1 can be used as an integrated device by attaching the left controller 3 and the right controller 4 to the main unit 2. Alternatively, the game system 1 can be used with the main unit 2 and the left controller 3 and right controller 4 as separate components (see Figure 2). The hardware configuration of the game system 1 in this embodiment will be described below, followed by a description of the control of the game system 1 in this embodiment.

[0041] As shown in Figure 1, the left controller 3 and the right controller 4 are each mounted on and integrated with the main unit 2. The main unit 2 is a device that performs various processes (e.g., game processing) in the game system 1. The main unit 2 is equipped with a display 12. The left controller 3 and the right controller 4 are devices equipped with operation sections for user input.

[0042] As shown in Figures 1 and 2, the left controller 3 and the right controller 4 are detachable from the main unit 2. In the following, the left controller 3 and the right controller 4 will be collectively referred to as "controllers."

[0043] As shown in Figure 3, the main unit 2 includes a roughly plate-shaped housing 11. In this embodiment, the main surface of the housing 11 (in other words, the front surface, i.e., the surface on which the display 12 is provided) is roughly rectangular in shape.

[0044] The shape and size of the housing 11 are arbitrary. For example, the housing 11 may be portable. The main unit 2 alone, or the integrated unit in which the left controller 3 and right controller 4 are attached to the main unit 2, may be a portable device. The main unit 2 or the integrated unit may be a handheld device. The main unit 2 or the integrated unit may also be a portable device.

[0045] As shown in Figure 3, the main unit 2 includes a display 12 provided on the main surface of the housing 11. The display 12 displays images generated by the main unit 2. In this embodiment, the display 12 is a liquid crystal display (LCD). However, the display 12 may be any type of display device.

[0046] Furthermore, the main unit 2 is equipped with a touch panel 13 on the screen of the display 12. In this embodiment, the touch panel 13 is of a type that allows multi-touch input (for example, a capacitive touch panel). However, the touch panel 13 may be of any type, for example, a type that allows single-touch input (for example, a resistive touch panel).

[0047] The main unit 2 is equipped with a speaker (i.e., speaker 88 shown in Figure 6) inside the housing 11. As shown in Figure 3, speaker holes 11a and 11b are formed on the main surface of the housing 11. The sound output from speaker 88 is emitted from these speaker holes 11a and 11b, respectively.

[0048] Furthermore, the main unit 2 is equipped with a left terminal 17, which is a terminal for the main unit 2 to communicate with the left controller 3 via wired connection, and a right terminal 21, which is for the main unit 2 to communicate with the right controller 4 via wired connection.

[0049] As shown in Figure 3, the main unit 2 is equipped with a slot 23. The slot 23 is located on the upper side of the housing 11. The slot 23 has a shape that allows a predetermined type of storage medium to be inserted. The predetermined type of storage medium is, for example, a storage medium (e.g., a dedicated memory card) specifically for the game system 1 and similar information processing devices. The predetermined type of storage medium is used, for example, to store data used by the main unit 2 (e.g., application save data, etc.) and / or programs executed by the main unit 2 (e.g., application programs, etc.). The main unit 2 is also equipped with a power button 28.

[0050] The main unit 2 is equipped with a lower terminal 27. The lower terminal 27 is a terminal for the main unit 2 to communicate with the cradle. In this embodiment, the lower terminal 27 is a USB connector (more specifically, a female connector). When the integrated device or the main unit 2 alone is placed on the cradle, the game system 1 can display the images generated and output by the main unit 2 on a stationary monitor. In this embodiment, the cradle also has the function of charging the integrated device or the main unit 2 alone that is placed on it. The cradle also has the function of a hub device (specifically, a USB hub).

[0051] As shown in Figure 4, the left controller 3 includes a housing 31. In this embodiment, the housing 31 has a vertically elongated shape, that is, it is long in the vertical direction (i.e., in the y-axis direction as shown in Figures 1 and 4). When the left controller 3 is detached from the main unit 2, it can also be held in a vertically elongated orientation. The housing 31 is shaped and sized to be held with one hand, especially the left hand, when held in a vertically elongated orientation. The left controller 3 can also be held in a horizontally elongated orientation. When the left controller 3 is held in a horizontally elongated orientation, it may be held with both hands.

[0052] The left controller 3 is equipped with an analog stick 32. As shown in Figure 4, the analog stick 32 is provided on the main surface of the housing 31. The analog stick 32 can be used as a directional input unit that can input direction. The user can input direction (and magnitude according to the angle of tilt) by tilting the analog stick 32. In addition, the left controller 3 may be equipped with a directional pad or a slide stick that allows slide input instead of the analog stick as the directional input unit. Furthermore, in this embodiment, input by pressing the analog stick 32 is also possible.

[0053] The left controller 3 is equipped with various operation buttons. The left controller 3 has four operation buttons 33-36 (specifically, a right direction button 33, a down direction button 34, an up direction button 35, and a left direction button 36) on the main surface of the housing 31. In addition, the left controller 3 is equipped with a record button 37 and a minus button 47. The left controller 3 has a first L button 38 and a ZL button 39 on the upper left side of the side of the housing 31. Furthermore, the left controller 3 has a second L button 43 and a second R button 44 on the side of the housing 31 that is attached when mounted to the main unit 2. These operation buttons are used to give instructions according to various programs (e.g., OS programs and application programs) executed on the main unit 2.

[0054] Furthermore, the left controller 3 is equipped with a terminal 42 for wired communication between the left controller 3 and the main unit 2.

[0055] As shown in Figure 5, the right controller 4 includes a housing 51. In this embodiment, the housing 51 has a vertically elongated shape, that is, it is long in the vertical direction. When the right controller 4 is detached from the main unit 2, it can also be held in a vertically elongated orientation. The housing 51 is shaped and sized to be held with one hand, especially the right hand, when held in a vertically elongated orientation. The right controller 4 can also be held in a horizontally elongated orientation. When the right controller 4 is held in a horizontally elongated orientation, it may be held with both hands.

[0056] The right controller 4, like the left controller 3, is equipped with an analog stick 52 as a directional input unit. In this embodiment, the analog stick 52 has the same configuration as the analog stick 32 of the left controller 3. Alternatively, the right controller 4 may be equipped with a directional pad or a slide stick capable of slide input instead of the analog stick. The right controller 4, like the left controller 3, is equipped with four operation buttons 53-56 (specifically, A button 53, B button 54, X button 55, and Y button 56) on the main surface of the housing 51. Furthermore, the right controller 4 is equipped with a + (plus) button 57 and a home button 58. The right controller 4 is also equipped with a first R button 60 and a ZR button 61 on the upper right side of the housing 51. The right controller 4, like the left controller 3, is also equipped with a second L button 65 and a second R button 66.

[0057] Furthermore, the right controller 4 is equipped with a terminal 64 for wired communication between the right controller 4 and the main unit 2.

[0058] In addition to the configuration shown in Figure 3, the main unit 2 includes the components 81-91, 97, and 98 shown in Figure 6. Some of these components 81-91, 97, and 98 may be mounted as electronic components on an electronic circuit board and housed within the housing 11.

[0059] The main unit 2 includes a processor 81. The processor 81 is an information processing unit that performs various information processing operations performed in the main unit 2, and may consist of, for example, only a CPU (Central Processing Unit), or it may consist of an SoC (System-on-a-chip) that includes multiple functions such as CPU function and GPU (Graphics Processing Unit) function. The processor 81 performs various information processing operations by executing information processing programs (for example, game programs) stored in a storage unit (specifically, an internal storage medium such as flash memory 84, or an external storage medium installed in slot 23).

[0060] The main unit 2 includes, as an example of an internal storage medium built into itself, a flash memory 84 and a DRAM (Dynamic Random Access Memory) 85. The flash memory 84 and DRAM 85 are connected to the processor 81. The flash memory 84 is a memory mainly used to store various types of data (which may be programs) stored in the main unit 2. The DRAM 85 is a memory used to temporarily store various types of data used in information processing.

[0061] The main unit 2 is equipped with a slot interface (hereinafter abbreviated as "I / F") 91. The slot I / F 91 is connected to the processor 81. The slot I / F 91 is connected to slot 23 and reads and writes data to a predetermined type of storage medium (for example, a dedicated memory card) installed in slot 23, according to instructions from the processor 81.

[0062] The processor 81 performs the above-mentioned information processing by appropriately reading and writing data to and from the flash memory 84 and DRAM 85, as well as to each of the above-mentioned storage media.

[0063] The main unit 2 includes a network communication unit 82. The network communication unit 82 is connected to the processor 81. The network communication unit 82 communicates with external devices via a network (specifically, wirelessly). In this embodiment, the network communication unit 82 communicates with external devices by connecting to a wireless LAN using a method compliant with the Wi-Fi® standard as a first communication mode. The network communication unit 82 also communicates wirelessly with other main unit 2 of the same type using a predetermined communication method (for example, communication using a proprietary protocol or infrared communication) as a second communication mode. The wireless communication using the second communication mode is possible with other main unit 2 located within a closed local network area, and realizes a function that enables so-called "local communication" in which data is transmitted and received by communicating directly between multiple main unit 2.

[0064] The main unit 2 includes a controller communication unit 83. The controller communication unit 83 is connected to the processor 81. The controller communication unit 83 communicates wirelessly with the left controller 3 and / or the right controller 4. The communication method between the main unit 2 and the left controller 3 and the right controller 4 is arbitrary, but in this embodiment, the controller communication unit 83 communicates with the left controller 3 and with the right controller 4 in accordance with the Bluetooth® standard.

[0065] The processor 81 is connected to the left terminal 17, right terminal 21, and lower terminal 27 described above. When the processor 81 communicates with the left controller 3 via a wired connection, it transmits data to the left controller 3 via the left terminal 17 and receives operation data from the left controller 3 via the left terminal 17. When the processor 81 communicates with the right controller 4 via a wired connection, it transmits data to the right controller 4 via the right terminal 21 and receives operation data from the right controller 4 via the right terminal 21. When the processor 81 communicates with the cradle, it transmits data to the cradle via the lower terminal 27. Thus, in this embodiment, the main unit 2 can perform both wired and wireless communication with the left controller 3 and the right controller 4, respectively. Furthermore, when the left controller 3 and the right controller 4 are mounted on the main unit 2 as an integrated unit, or when the main unit 2 alone is mounted on the cradle, the main unit 2 can output data (e.g., image data and audio data) to a stationary monitor or the like via the cradle.

[0066] Here, the main unit 2 can communicate simultaneously (in other words, in parallel) with multiple left controllers 3. Furthermore, the main unit 2 can communicate simultaneously (in other words, in parallel) with multiple right controllers 4. Therefore, multiple users can simultaneously input to the main unit 2 using their respective sets of left controllers 3 and right controllers 4. For example, while the first user inputs to the main unit 2 using the first set of left controllers 3 and right controllers 4, the second user can input to the main unit 2 using the second set of left controllers 3 and right controllers 4.

[0067] The display 12 is also connected to the processor 81. The processor 81 displays images generated (for example, by performing the above information processing) and / or images acquired from an external source on the display 12.

[0068] The main unit 2 includes a codec circuit 87 and speakers (specifically, a left speaker and a right speaker) 88. The codec circuit 87 is connected to the speakers 88 and the audio input / output terminals 25, as well as to the processor 81. The codec circuit 87 is a circuit that controls the input and output of audio data to the speakers 88 and the audio input / output terminals 25.

[0069] The main unit 2 comprises a power control unit 97 and a battery 98. The power control unit 97 is connected to the battery 98 and the processor 81. Although not shown in the figures, the power control unit 97 is also connected to various parts of the main unit 2 (specifically, the parts that receive power from the battery 98, the left terminal 17, and the right terminal 21). Based on commands from the processor 81, the power control unit 97 controls the power supply from the battery 98 to the aforementioned parts.

[0070] The battery 98 is also connected to the lower terminal 27. When an external charging device (for example, a cradle) is connected to the lower terminal 27 and power is supplied to the main unit 2 via the lower terminal 27, the supplied power charges the battery 98.

[0071] The left controller 3 includes a communication control unit 101 that communicates with the main unit 2. As shown in Figure 7, the communication control unit 101 is connected to each component, including the terminal 42. In this embodiment, the communication control unit 101 can communicate with the main unit 2 both by wired communication via the terminal 42 and by wireless communication without using the terminal 42. The communication control unit 101 controls the method of communication that the left controller 3 performs with the main unit 2. That is, when the left controller 3 is attached to the main unit 2, the communication control unit 101 communicates with the main unit 2 via the terminal 42. When the left controller 3 is detached from the main unit 2, the communication control unit 101 performs wireless communication with the main unit 2 (specifically, the controller communication unit 83). Wireless communication between the controller communication unit 83 and the communication control unit 101 is performed according to, for example, the Bluetooth® standard.

[0072] The left controller 3 also includes a memory 102, such as flash memory. The communication control unit 101 is composed of, for example, a microcontroller (also called a microprocessor) and performs various processes by executing firmware stored in the memory 102.

[0073] The left controller 3 is equipped with buttons 103 (specifically, buttons 33-39, 43, 44, and 47). The left controller 3 is also equipped with an analog stick (referred to as "stick" in Figure 7) 32. Each button 103 and the analog stick 32 repeatedly output information about the operations performed on them to the communication control unit 101 at appropriate intervals.

[0074] The communication control unit 101 acquires information about the input (specifically, information about the operation or detection results from the sensor) from each input unit (specifically, each button 103 and the analog stick 32). The communication control unit 101 transmits operation data, including the acquired information (or information that has been processed in a predetermined manner), to the main unit 2. The operation data is transmitted repeatedly at a rate of once at predetermined intervals. The interval at which information about the input is transmitted to the main unit 2 may or may not be the same for each input unit.

[0075] When the above operation data is transmitted to the main unit 2, the main unit 2 can obtain the input made to the left controller 3. In other words, the main unit 2 can determine the operation of each button 103 and the analog stick 32 based on the operation data.

[0076] The left controller 3 includes a power supply unit 108. In this embodiment, the power supply unit 108 includes a battery and a power control circuit. Although not shown, the power control circuit is connected to the battery and to each part of the left controller 3 (specifically, each part that receives power from the battery).

[0077] As shown in Figure 7, the right controller 4 includes a communication control unit 111 that communicates with the main unit 2. The right controller 4 also includes a memory 112 connected to the communication control unit 111. The communication control unit 111 is connected to each component, including the terminal 64. The communication control unit 111 and the memory 112 have the same functions as the communication control unit 101 and memory 102 of the left controller 3. Therefore, the communication control unit 111 can communicate with the main unit 2 both by wired communication via the terminal 64 and by wireless communication without the terminal 64 (specifically, communication according to the Bluetooth® standard), and controls the method of communication that the right controller 4 performs with the main unit 2.

[0078] The right controller 4 is equipped with the same inputs as the left controller 3. Specifically, it has buttons 113 and an analog stick 52. These inputs have the same functions and operate in the same way as the inputs of the left controller 3.

[0079] The right controller 4 is equipped with a power supply unit 118. The power supply unit 118 has the same functions and operates in the same manner as the power supply unit 108 of the left controller 3.

[0080] As described above, in this embodiment, the left controller 3 and the right controller 4 of the game system 1 are detachable from the main unit 2. Furthermore, by attaching an integrated device in which the left controller 3 and the right controller 4 are mounted on the main unit 2, or by attaching the main unit 2 alone to the cradle, images (and sound) can be output to an external display device such as a stationary monitor. In the following description, the game system 1 will be described using a usage mode in which images are displayed on the display 12. Note that when using the game system 1 in a usage mode in which images are displayed on the display 12, a game system 1 in which the left controller 3 and the right controller 4 are fixed to the main unit 2 (for example, a configuration in which the main unit 2, the left controller 3, and the right controller 4 are integrated into a single housing) may also be used.

[0081] Gameplay is performed using the game space displayed on the display 12, in response to the operation of the buttons and sticks on the left controller 3 and / or the right controller 4 in the game system 1, or to touch operations on the touch panel 13 of the main unit 2. In this embodiment, as an example, gameplay using a player character PC that operates within the game space is possible in response to user operations using the above-mentioned buttons and sticks.

[0082] In this embodiment, it is possible to run a game in which multiple users operate their respective player characters within the same game space. The game is realized by multiple users utilizing a system in multiple configurations. As a first example, multiple users each operate their respective player characters using the game system 1, and the game is realized by utilizing an information processing system (for example, an information processing system in which multiple main units 2 communicate via a network) connected by the network communication unit 82 of each game system 1 communicating via the network in the first communication configuration described above. As a second example, the game is realized by utilizing an information processing system (for example, an information processing system in which multiple main units 2 communicate directly) connected by the network communication unit 82 of each game system 1 communicating directly in the second communication configuration described above. As a third example, the game is realized by having multiple users input operation data for operating the left controller 3 and / or right controller 4 into a single main unit 2, and then controlling each user's player character within the same game space using that single main unit 2. This embodiment may use any of the systems described, but the following description will use an example of implementing a game using the information processing system of the first example.

[0083] Using Figure 8, we will describe the information processing system of the first example described above, which is composed of multiple game systems 1 and servers 102.

[0084] As shown in Figure 8, an information processing system 100 is constructed by connecting multiple game systems 1 (main unit 2) and servers 102 via a network 110. The game system 1 is configured to connect to the network 110 using wireless or wired communication in the first communication mode described above, and forms a client-server system with the server 102. For example, the game system 1 is capable of executing a predetermined application (e.g., a game application). Furthermore, by executing the predetermined application, the game system 1 establishes a connection with the server 102 via the network 110, enabling communication with the server 102.

[0085] As shown in Figure 9, the server 102 has a communication unit 103, a control unit 104, and a storage unit 105. The communication unit 103 communicates with the game system 1 etc. via the network 110 by sending and receiving communication packets. For example, the control unit 104 manages the progress of the game with the game system 1, manages the game space used for the game, manages the number and capacity of participants in the game session (e.g., a section described later) used for the game, manages each user's score, manages information related to billing, etc., and establishes a communication link with the game system 1 etc. via the communication unit 103, and performs data transport control and route selection in the network 110. Furthermore, when a game is played with multiple game systems 1 (e.g., a game in which multiple users operate their respective player characters within the same game space), the control unit 104 manages the combination of game systems 1 playing the game and the data communication between the game systems 1. The storage unit 105 stores programs executed by the control unit 104, various data necessary for the above processing, and various data necessary for communication with the game system 1. Furthermore, if the system requires a predetermined login process for sending and receiving data or participating in games using the network 110, the server 102 may perform an authentication process to determine whether the user attempting to log in is a legitimate user. The server 102 may consist of a single server machine or multiple server machines. In the former case, the data storage area of ​​the server 102 may be divided and used as physical server resources, each managing one of the game sessions. In the latter case, the server 102 may consist of server machines, each managing one of the game sessions.

[0086] In this embodiment, within the information processing system 100, each game system 1 exchanges operation information via the server 102, thereby enabling a communication game in which multiple player characters corresponding to each user operate within the same shared game space. The operation information exchanged when playing this communication game may be information about the player character being controlled by each user using a controller, information about the game space edited by the actions of the player character, information indicating the content of the controller operations performed by each user controlling each player character, or any other information that allows each user to understand the progress of the game.

[0087] Using Figures 10 to 24, we will explain an overview of a game processing example performed in the game system 1 that constitutes the information processing system 100. First, in order to explain the overview of the above game processing example, we will refer to Figure 10 and explain the overview of the game space used in the game processing example.

[0088] In Figure 10, in this embodiment, the game field is composed of multiple unit regions. For example, a unit region is a region that divides the game field into a square grid when viewed from the vertical direction, and each unit region is the same size. Specifically, if the x and z axes are set to be mutually orthogonal in the horizontal direction of the game field, and the y axis is set in the vertical direction, then a unit region is a single region divided into a grid by multiple planes parallel to the xy plane and multiple planes parallel to the yz plane. As a result, the game field is configured such that the unit regions are arranged side by side in the horizontal direction (specifically, the front-to-back direction and the left-to-right direction) in the game space.

[0089] The shape of the game field is defined using terrain objects L (pieces) as the unit. Terrain objects L are elements that make up the game field, and the shape of the game field can be changed by editing them, such as moving, adding, and deleting them. One terrain object L has a horizontal size in the game space equal to one of the above-mentioned unit areas, and its vertical length is the same as the horizontal length of the above-mentioned unit area.

[0090] The terrain object L has a rectangular parallelepiped shape (more specifically, a cubic shape) and is arranged in a grid pattern in the game space to form the game field. As an example, in this embodiment, the game system 1 has parameters related to the terrain object L set for coordinates set in the game space, and stores parameters for multiple coordinates that indicate whether or not a terrain object L exists at that coordinate. In this way, the game system 1 can define the shape of multiple terrain objects L in the game space by managing whether or not a terrain object L exists for each coordinate in the game space (i.e., storing the above parameters for each coordinate). The terrain object L may have irregularities on its surface, or its corners may be rounded.

[0091] In other embodiments, the game system 1 may have parameters set for each terrain object L present in the game space. The parameters set for each terrain object L indicate at least the position of the terrain object L in the game space. In this way, the game system 1 can define the shape of the game field (the shape of the game field) formed by multiple terrain objects L in the game space by managing the position of each terrain object L in the game space (i.e., storing the above parameters for each terrain object L).

[0092] In this embodiment, based on user input, the player character PC can perform predetermined actions to edit terrain objects and update their state. For example, updating the state of terrain objects includes placing new terrain objects in the game space, removing terrain objects already placed in the game space, changing the appearance (texture and shape) of terrain objects already placed in the game space, and embedding information into terrain objects already placed in the game space.

[0093] Editing terrain objects includes creating new terrain objects in the game space by moving and joining existing terrain objects L or new terrain objects already placed in the game space. Editing terrain objects also includes updating the generated terrain objects by moving them, changing their appearance or properties, or joining them with other terrain objects. In this embodiment, the player character PC who edits the terrain objects is referred to as the editor.

[0094] Furthermore, in this embodiment, other objects different from the terrain object L may be placed in the game space. Also, these other objects may be editable based on predetermined actions of the player character PC in the game space. In this case, the parameters corresponding to each of these other objects may also include data indicating the editor. As an example of these other objects, decorative objects, which are content that the player character PC can wear or equip in the game space, may be editable based on predetermined actions of the player character PC.

[0095] Terrain objects may be joined with other adjacent terrain objects, allowing for editing of the unified terrain object. For example, when a player character PC performs a predetermined action, multiple terrain objects that are the target of that action may be joined together and unified.

[0096] In this embodiment, a game is played using a game space composed of multiple terrain objects L, in which multiple users operate their respective player characters PCs. For example, in the example shown in Figure 10, a first player character PC1 and a second player character PC2 are placed on terrain composed of multiple terrain objects L. The first player character PC1 is a player character corresponding to a user of game system 1 (hereinafter referred to as the first user), and operates within the game space in response to the operation of the left controller 3 and / or right controller 4 of game system 1 by the first user. The second player character PC2 is a player character corresponding to another user of game system 1 (hereinafter referred to as the second user), and operates within the same game space where the first player character PC1 is placed, in response to the operation of the left controller 3 and / or right controller 4 of the other game system 1 by the second user.

[0097] Multiple users can change the state of the game space by operating their respective player character PCs and performing actions such as editing terrain objects, which are an example of content within the game space. For example, based on the input of the first user, the first player character PC1 can move a terrain object L corresponding to the position in the game space corresponding to that position, delete a terrain object L corresponding to the position in the game space corresponding to that position, place a new terrain object at the position in the game space corresponding to that position, or duplicate a generated terrain object. Similarly, based on the input of the second user, the second player character PC2 can change the state of the same game space in the same way as the first player character PC1.

[0098] Furthermore, in this embodiment, it is also possible to change and edit the state within the game space by placing, moving, or deleting a specific object different from the terrain object L. Below, with reference to Figures 13 and 14, an example of how the game space is modified using a region setting object, which is an example of such a specific object, will be explained.

[0099] In Figure 13, the first player character PC1 is positioned on the ground (terrain object L) in the game space, holding the first area setting object A1 in their hand. The first area setting object A1 can be moved or stored by the first player character PC1 by performing a predetermined acquisition operation (for example, lifting or storing the first area setting object A1 placed in the game space). When the first player character PC1 moves within the game space while holding or storing the first area setting object A1, the first area setting object A1 moves along with the first player character PC1. Alternatively, the first player character PC1 may move the first area setting object A1 along with the first player character PC1 by pushing it on the ground (terrain object L) in the game space, causing the first area setting object A1 to move in the direction of the push.

[0100] Furthermore, the first area setting object A1 may be an object that is pre-placed in the game space (on terrain object L) at the start of the game, or it may be an object that is placed in a predetermined location when the player level reaches a predetermined level or when predetermined acquisition conditions such as clearing a mission are met, or it may be an object that is dropped by another character, placed in response to another character being defeated, or obtained from an object that is not an area setting object. In addition, the first area setting object A1 may be an object that changes into the first area setting object A1 when a specific action is performed on that specific object.

[0101] In Figure 14, the first player character PC1 performs placement actions such as placing or throwing the first area setting object A1 it is holding in response to an action instruction input from the first user. As a result, the first area setting object A1 is placed on the terrain object L that constitutes the ground of the game space, based on the placement action corresponding to the user input, with the position of the first player character PC1 as the reference point. For example, if the first player character PC1 performs a placement action of placing the first area setting object A1 it is holding, the first area setting object A1 will be placed so as to be in contact with the terrain object L that is placed directly in front of the first player character PC1. As another example, if the first player character PC1 performs a placement action of throwing the first area setting object A1 it is holding, the first area setting object A1 will be thrown and placed so as to be in contact with the terrain object L that is placed at a predetermined distance (a distance that makes the terrain object L a predetermined number of units) in the direction in front of the first player character PC1.

[0102] In this embodiment, interaction data (e.g., "likes") based on interactions between player character PCs (between users operating player character PCs) is assigned to the parties involved. For example, interaction data is assigned to another user when it is deemed that the user has performed an arbitrary action toward that user. This data may be assigned automatically in response to the actions of the player character PC operated by that user, or it may be assigned in response to the user's actions. The targets to which the above interaction data can be assigned may also be other player characters, area setting objects, edited terrain objects, and dwelling pieces (described later). Regardless of the user's gameplay status related to these in-game contents, interaction with the user can be realized.

[0103] The first area setting object A1 is an object associated with at least one first player character PC1, and when placed in the game space, it has the function of setting the first area R1 associated with the first player character PC1 in the game space. Here, the state of being associated with the first player character PC1 means that it is usable only by the first player character PC1 among multiple player characters, or that its effect is granted only to the first player character PC1. As will be described later, the first area R1 may be displayed in a display manner that makes it distinguishable from other areas in the game space. In this embodiment, area information indicating a user area (e.g., the first area R1) set in the game space by the user is managed in association with user information indicating the user who set the user area (e.g., the first user who operates the first player character PC1). Here, the area information includes the ID of the area setting object (e.g., the first area setting object A1) and the coordinate information of the area setting object in the game space. In other embodiments, the above-mentioned area information may be information about the user area itself, instead of information related to the above-mentioned area setting object. Furthermore, the above-mentioned user information includes information such as the user's account ID and username. Note that although the first area setting object A1 is described as an object associated with the first player character PC1, this is equivalent to being associated with the first user who operates the first player character PC1 (more specifically, the game account and the first user's user ID, which is an identifier assigned to the user). In this case, the first area setting object A1 can be said to have the function of setting the first area R1 associated with the first user in the game space. Here, the state of being associated with the first user means, for example, a state in which, among multiple users, only the first user can change the parameters, only the first user can use them, or only the first user is granted the effect.

[0104] In this embodiment, within the first region R1, editing of the game space is restricted, except for editing by the first player character PC1. For example, as described above, each player character PC can edit terrain objects L in the game space. However, within the first region R1, editing by characters other than the first player character PC1 who set up the first region R1 (including other player character PCs such as the second player character PC2) is restricted, and the right to edit the game space is granted to the first player character PC1.

[0105] In this way, by granting the first player character PC1 editing rights to the game space within the first area R1, the state of the game space within the first area R1 when the first area setting object A1 was placed, or the state of the game space within the first area R1 after the last modification based on the first user's input, is further restricted from being modified by other users. Here, the restriction on changes to the game space is not limited to restrictions on changes based on other users' operations, but may also include restrictions on changes made by characters automatically controlled by the computer (e.g., non-player characters) and changes caused by phenomena in the game space other than character movements (such as collapse or alteration due to environmental factors like wind, rain, or vibration).

[0106] Furthermore, the first area setting object A1 may function as a destination for gifts and messages sent from other users to the first user. For example, if another user sends a UGC (User Generated Content) object such as an object, an object containing text, an object containing an image, or an object containing audio to the first user, the UGC object will be placed in the game space near the first area setting object A1 set by the first user.

[0107] Next, with reference to Figures 15 and 16, we will describe an example of the position, shape, and size of the first region R1, which is set by placing the first region setting object A1 in the game space. In Figures 15 and 16, the upper figure is a top view looking down from above at the first region setting object A1 and the first region R1 in the game space, and the lower figure is a side view looking from the side at the first region setting object A1 and the first region R1 in the game space, respectively.

[0108] As illustrated in Figure 15, the first region R1 is defined as a region that includes the horizontal position of the first region setting object A1, and when defined in a three-dimensional game space, it is defined to include at least a portion of the first region setting object A1 as it is positioned in the game space when viewed from above. Here, including at least a portion of the first region setting object A1 as it is positioned in the game space when viewed from above means that the region (the first region R1) includes at least the space in the game space where the first region setting object A1 exists, the space directly above the first region setting object A1 in the game space, and / or the space directly below the first region setting object A1 in the game space. As an example, the first region R1 is formed by a cylindrical space that extends up to the height limit in the vertical direction, with a vertical line in the game space passing through the position of the first region setting object A1 as the cylindrical axis.

[0109] Note that the shape of the first region R1 is not, for example, a cylindrical shape that extends to the height limit in the direction of game space, but may also be a shape like the one illustrated in Figure 16. As illustrated in Figure 16, other examples of the shape of the first region R1 are set as a hemispherical cylinder shape, which combines a cylinder whose axis is a vertical line in game space passing through the position of the first region setting object A1, and a hemisphere whose center is the position of the first region setting object A1 and whose vertex is above the first region setting object A1.

[0110] Furthermore, if the first region setting object A1 moves within the game space, the first region R1 may also move along with it. In this way, by moving the first region setting object A1 to a different location, the first region R1 can be set to a different location than the one it was initially set to.

[0111] In other embodiments, a user area (e.g., a first area R1) set by the user within the game space may be set independently of an area setting object (without placing an area setting object in the game space). For example, a predetermined range in the game space may be given to the user in exchange for a predetermined item (e.g., in-game currency or points awarded to the user during the game), and this range may be set as the user's user area. As another example, a user area corresponding to each user may be provided in advance.

[0112] In this embodiment, the game space within the user area is set to an explored state, with the aforementioned unit areas as the unit. In this embodiment, the game field can be either untouched or explored for each unit area. In the initial state of the game, all unit areas within the game field are set to an untouched state, and the display manner of the game field may be changed for unit areas set to an explored state. For example, explored unit areas within explored area Ra may be made brighter than untouched unit areas to distinguish them from other areas.

[0113] In this embodiment, the game field is divided into multiple sections. Each section consists of multiple unit areas. In this embodiment, the game field is not divided into multiple sections in the vertical direction, but in other embodiments, it may be divided into multiple sections in the vertical direction as well. Also, the size of each section (i.e., the number of unit areas contained in one section) is the same for each section (for example, one section has 512 x 512 unit areas), but in other embodiments, the size of each section may differ. In this embodiment, the sections function as an example of a game session that constitutes a player group in which player characters controlled by multiple users participate. Therefore, in this embodiment, by providing multiple sections, it becomes possible to play games using multiple game sessions.

[0114] The development status of a section may be changed from an incomplete state to a completed state in response to the player character's development of a unit area. For example, if the number of unit areas within a section that have been developed reaches a predetermined value, the development condition may be met, and the section may be set to a completed state.

[0115] Furthermore, depending on the development status of the area, the system may control whether to allow or prohibit the movement of player characters between areas based on at least one of the following criteria. Movement from one section to another is permitted only if both of the following two conditions are met. The first condition is that both the source section and the destination section are in an open state. Here, "open state" means that at least one of the adjacent sections is in a developed state. The second condition is that either the source section or the destination section is in a developed state. - It is possible to move to another area if the area from which you are moving is already developed. - If the destination area is in a developed state, and the group of areas the player character was last staying in matches the group of areas the player character is moving to, the player character can move to an area belonging to that group of areas. Here, the group of areas refers to a set of multiple adjacent areas that are in a developed state. This determination item allows the player character to move within the same group of areas where they are staying, and prevents the player character from moving to another group of areas via an undeveloped area that is adjacent to multiple different groups of areas. Furthermore, due to the capacity requirements for each section described later, movement of player characters between sections may be prohibited, even if such movement is permitted under the above criteria. Also, even if movement of player characters between sections is permitted due to the capacity requirements for each section described later, such movement may be prohibited if such movement is prohibited under the above criteria.

[0116] In this embodiment, area information images can be displayed for each area, showing the placement of area setting objects and player characters within each area on the game field. For example, in this embodiment, when a user inputs an instruction to display an area information image, a map image is displayed that makes the current area information visible for each area. The information used to display the area information image may be at least one piece of information obtained from the server 102 at the time of display, or at least one piece of information that the main unit 2 periodically obtains from the server 102 may be used.

[0117] Figure 17 shows an example of a section information image displayed on display 12. In Figure 17, the example of a section information image is displayed in the form of a map image that looks down from directly above the game space, encompassing a predetermined range of game fields. The section information image displays each section of the game field arranged in a horizontal grid. In the example shown in the lower part of Figure 17, sections A to F are displayed as the map image on display 12. Specifically, in the map images shown in the upper and lower parts of Figure 17, the player character PC1 is in section A, and the area setting object A1 for the player character PC1 is placed in section B.

[0118] In this embodiment, a first map image may be displayed showing first section information for a section in which the user is participating as either an operator or a viewer (section A in the example of Figure 17; hereinafter referred to as the participating section). Here, the first section information is information about the participating section that is displayed by enlarging the map image, and contains a relatively large amount of detailed information. The first section information may include, for example, the current position of the player character operated by the user, the current position of the player character operated by another user, the movement path (footprints) of the player character operated by the user, information showing the editing history of objects placed in the game space, the location where area setting objects are placed, information showing a section-shared object that can be associated with up to one per section (for example, the object shown by the As icon in Figure 17), and information showing the coordinates of the developed unit area. Furthermore, the user may be able to check more detailed information by manipulating the cursor within the first map image. For example, by the user hovering the cursor over an icon showing a player character operated by another user (for example, the PC2 icon shown in Figure 17), the account name of the user operating that player character may be displayed.

[0119] In this embodiment, a second map image may be displayed showing second section information for the participating section and surrounding sections (sections B and C in the example of Figure 17) in which the user is participating as either an operator or a viewer. Here, the second section information is information about the participating section and surrounding sections displayed by reducing the map image. The information about section A shown in the first map image may contain more information than the information about section A shown in the second map image, and may include more detailed information such as the player character's position compared to the information about section A shown in the second map image. The second section information may include, for example, information indicating whether the section has met the development completion conditions, information indicating the development status of the section, information regarding interactions that have taken place within the section, and information indicating a section-shared object that can be associated with up to one per section. The surrounding sections may be the four sections adjacent to the participating section, the eight sections surrounding the participating section, or a wider area. Furthermore, the second section information may not be displayed for surrounding sections that do not meet the predetermined conditions. For example, the second section information does not need to be displayed for sections that do not have the above-mentioned shared section object, sections that do not have either a region setting object or a player character, or sections whose development value is less than a predetermined value. Furthermore, if the surrounding sections include a section where the user has placed a region setting object, information indicating that a region setting object is placed (for example, the region setting object indicated by the A1 icon in section B in the example of Figure 17) may be included. In this embodiment, either the first map image or the second map image is displayed based on the user's operation of zooming in or out of the map image. In other embodiments, both the first map image and the second map image may be displayed simultaneously. For example, when displaying a section information image that includes the participating section and the surrounding sections, the first map image may be displayed for the participating section while the second map image is displayed for the surrounding sections.

[0120] Thus, in this embodiment, the first map image displays more detailed information than the second map image. Therefore, if a user wishes to obtain the first section information, they must participate in the section from which they wish to obtain the information as an operator or viewer, as described later. In other embodiments, the first section information may also be displayed in the second map image.

[0121] Furthermore, the update frequency of the second parcel information displayed in the second map image may be lower than the update frequency of the first parcel information displayed in the first map image. Also, the second map image may be accessed by zooming out from the first map image, or the first map image may be accessed by zooming in from the second map image. As another example, a third map image with less information per parcel may be displayed by zooming out further from the second map image.

[0122] Furthermore, the map image described above may be displayed in a manner that shows the game field included within a predetermined range viewed diagonally from above in the game space. Also, the horizontal direction in the section information image described above may be along the direction of a sphere. For example, if the entire game field is composed of a spherical celestial body, the horizontal direction in the section information image will be along the direction of a sphere corresponding to the shape of that celestial body. In this case, the sections arranged in a grid in the section information image will be displayed arranged in a grid along the direction of the sphere.

[0123] In this embodiment, a user of game system 1 can participate in each of the above-mentioned sections as either an operator or a viewer. The operator can enter a section with a player character PC corresponding to the user's game account (hereinafter simply referred to as account or user account) and participate in that section, and by operating the player character PC, can also edit the game space as described above.

[0124] The operator can control the player character PC corresponding to the operator, edit the terrain and other elements within the game space, and participate in the game as a participant in the area. On the other hand, the viewer can participate in the area where the object of viewing is located by at least watching the in-game content (e.g., other player character PCs or area setting object A) in the game. The viewer watches the in-game content (e.g., area setting object A of other player character PCs) as the object of viewing and basically participates in the game as a viewer in a read-only area, not sending game space update information to server 102. An account participating as a viewer cannot edit the game space as described above because it cannot control the player character PC, but can participate in the area as a viewer in a section where it is possible to control the virtual camera that views the object of viewing and to add interaction data to the object of viewing (e.g., adding evaluation data such as "like"). Furthermore, when a viewer sets a region setting object A in the game space as their viewing target, gifts and messages sent by other users may be placed near region setting object A, as mentioned above, making it suitable for viewing such gifts and messages.

[0125] In this embodiment, a user participating in a section as an operator can change the section they are participating in as an operator to the target section, provided that the capacity limit of that section is not exceeded. A user participating in a section as an operator can change from being an operator to becoming a viewer in the section they wish to watch, provided that the capacity limit of that section is not exceeded. A user participating in a section as a viewer can change the section they are participating in as a viewer to the target section, provided that the capacity limit of that section is not exceeded. A user participating in a section as a viewer can change from being a viewer to becoming an operator in the section they wish to participate in, provided that the capacity limit of that section is not exceeded.

[0126] Referring to Figures 18 to 22, an example of a user participating as a viewer instead of the operator described above will be explained. Figure 18 is an example of a game image showing player character PC1 entering area A. Figure 19 is an example of a game image showing a resident piece OBJp1 placed in area A. Figure 20 is an example of a game image showing the first user as a viewer observing area setting object A1 in area B. Figure 21 is an example of a game image showing the first user as a viewer observing player character PC3 in area C. Figure 22 is an example of a game image displayed when the user corresponding to the object being observed is a viewer of another object being observed.

[0127] In Figure 18, the first user, who controls the player character PC1, enters area A with the player character PC1 and participates as an operator of area A. In this embodiment, participation in the requested area as an operator becomes possible when the participation request sent from the game system 1 is permitted by the server 102. For example, the game system 1 operated by the first user sends a participation request to the server 102 for the first user to participate in area A as an operator. The server 102 then permits the participation request if the number of operators increased by the received participation request does not exceed the capacity limit of area A. If the participation request is permitted, the server 102 sends game information regarding the state of the game in area A to the game system 1 corresponding to the account of the first user who will participate in the permitted area A. The game system 1 of the first user then generates the game space of area A, including the player character PC1, based on the game information received from the server 102.

[0128] As illustrated in Figure 18, the virtual camera for displaying the game image on the display 12 of the first user's game system 1 is controlled based on the position of the player character PC1. Furthermore, based on the state of the game space in section A, which has been updated based on the actions of the player character PC1, update information for the game space is sent to the server 102. The server 102 then updates the game information for section A, which it manages, based on the received update information.

[0129] In this embodiment, a user participating in the game as an operator can request to participate as a viewer in the section they are participating in or in another section by performing a predetermined operation.

[0130] As a first example, a request to participate as a viewer of a spectator can be made by selecting a spectator from the images showing the player character PC or area setting object A displayed in the map image (see Figure 17) described above. In the first example above, only player character PCs placed in the area in which the operator is participating may be selected as spectators. Also, in the first example above, only area shared objects or area setting object A placed in the game space by the operator may be selected as spectators.

[0131] As a second example, a user can request to participate as a viewer of a player character by selecting the target from a list of players participating in the game. This list may be displayed in response to any action or by any animation performed during the game. The list may also consist of users (player characters) who have been pre-registered under any conditions, such as the operator's friends or other player characters that the operator's player character PC has previously interacted with in the game space. This interaction may include actions such as greeting someone or sending / receiving interaction data (e.g., "likes") in the game space.

[0132] As a third example, a player character can perform an action based on a predetermined input on a predetermined in-game content (e.g., a region setting object) in the game space, thereby requesting participation from a player character controlled by a user associated with that in-game content, or from a viewer who views that in-game content as a spectator. This participation request may be made immediately upon the action being performed, or it may be made after an item (e.g., a spectator card) acquired in response to the action is used. This item may be stored in the inventory of the user who acquired it. As another example, a player character can stand on a terrain object with embedded data about the spectator, thereby making the embedded data-based in-game content a spectator.

[0133] In Figure 19, during periods when the first user participating in the game as the operator is performing an action to request participation as a viewer, or during the period when the user is participating as a viewer, or during any other period when actions other than those performed by the player character PC1 are being taken, the resident piece OBJp1 is placed in place of the player character PC1. The resident piece OBJp1 is a virtual object with a different appearance from the player character PC1, and is placed at a position based on the last position where the player character PC1 was placed in the section in which the operator was participating. The resident piece OBJp1 indicates the appearance position when the player character PC1 returns to the section after the above period ends, and this return occurs when the player character PC1 appears in the game space in place of the resident piece OBJp1. Therefore, the placement of the resident piece OBJp1 makes it possible to notify that one of the users participating in the section in which the resident piece OBJp1 is placed is performing an action other than those performed by the operator of that section.

[0134] Furthermore, the resident piece OBJp1 is set to be uneditable in the game space. For example, in addition to restricting editing that would destroy or move the resident piece OBJp1 itself, editing of other objects surrounding the resident piece OBJp1 may also be restricted. Specifically, editing that would place other objects on top of the resident piece OBJp1, or editing that would delete other objects directly below the resident piece OBJp1, may also be restricted. This prevents the resident character PC1, controlled by the first user, from being unable to return to the area or becoming unable to move after returning to the area if other objects are placed at or around the location of the resident piece OBJp1 during the spectating session when the first user rejoins the area as an operator. However, there is no need to restrict moving resident pieces that have been placed by other users. Also, the resident piece OBJp1 may be removed from the game space after a predetermined time (for example, 1 hour) has elapsed since it was placed in the game space.

[0135] As shown in Figure 20, when a user is permitted to participate in section B as a viewer, with area setting object A1 located in section B as the target of viewing, a frame indicating the target of viewing is displayed on the display 12 of the first user's game system 1, and a game image of section B being viewed is displayed within that frame. In this embodiment, when a request for participation in section B as a viewer is permitted for the first user, game information regarding the state of the game in section B is transmitted from the server 102 to the game system 1 corresponding to the account of the first user who is permitted to participate in section B. The first user's game system 1 then generates a game space for section B, including the in-game content that is the target of viewing (in this case, area setting object A1 placed in the game space by the player character PC1), based on the game information received from the server 102.

[0136] As illustrated in Figure 20, the virtual camera for displaying the game image on the display 12 of the first user's game system 1 is controlled based on the position of the object to be viewed (area setting object A1). For example, the virtual camera may be controlled to rotate around the object to be viewed, with the object of view as the point of focus, based on the operation of the first user who is participating as a viewer in area B. In this way, when a user participates in the game as a viewer watching area setting objects placed within an area, the game image can be displayed as if the user themselves were inside that area.

[0137] As shown in Figure 21, if a first user is permitted to participate in section C as a viewer, with player character PC3 being the subject of spectating, a frame indicating the subject of spectating will be displayed on the display 12 of the first user's game system 1, and a game image of section C being viewed will be displayed within that frame. In this embodiment, when a first user's request to participate in section C as a viewer is permitted, game information regarding the state of the game in section C is transmitted from server 102 to the game system 1 corresponding to the first user's account that is permitted to participate in section C. The first user's game system 1 then generates a game space for section C, including the in-game content (in this case, player character PC3) that is the subject of spectating, based on the game information received from server 102.

[0138] As illustrated in Figure 21, the virtual camera for displaying the game image on the display 12 of the first user's game system 1 is controlled based on the position of the spectator (player character PC3). For example, if the spectator, player character PC3, moves within the game space, the virtual camera also moves to follow that movement. The virtual camera may also be controlled to rotate around the spectator, with the spectator as the point of focus, based on the operation of the first user participating as a viewer in section C. In this way, when a user participates in the game as a viewer watching other player characters that have entered a section, the game image can be displayed as if the user themselves were inside that section.

[0139] Furthermore, when a user participates in a game as a viewer of a section, a hidden player character PC corresponding to the viewer may be placed in that section, and the hidden player character PC may be placed so as to overlap with the object being viewed. In this case, the virtual camera for displaying the game image of the section is controlled based on the position of the hidden player character PC. For example, based on the viewer's actions to move the object being viewed or move the hidden player character PC within the game space, the virtual camera also moves to follow those movements. Alternatively, based on the viewer's actions, the virtual camera may be controlled to rotate around the hidden player character PC, with the hidden player character PC as the point of focus. In this case, since the viewer's account directly moves to the section and places a virtual camera to obtain the game image, rather than receiving game footage from a user related to the object being viewed, it becomes possible to perform predetermined interactions with the object being viewed (e.g., providing interaction data). Additionally, by borrowing the control rights of the object being viewed, the viewer may be able to control the object being viewed on behalf of the operator of the object being viewed. In other embodiments, when a user participates in a game as a viewer of a section, the server 102 may receive the user's gameplay video related to the viewing target, and the gameplay video may be displayed as the game image for the viewer to watch.

[0140] Furthermore, the in-game objects that can be selected as spectators may be any objects placed within the game space. For example, the in-game objects that can be selected as spectators may include the area setting objects and other player characters mentioned above, as well as area-shared objects placed within each area. These area-shared objects may be placed when an area is created, when an adjacent area is completed (i.e., when the area becomes open), or based on the first time a user joins an area. As another example, these area-shared objects may be placed in advance (for example, when the virtual space is configured). These area-shared objects can be selected as spectators by all users, and may be selectable from the second map image or selection list mentioned above, even if they are placed in an area where the first area information has not been unlocked.

[0141] Furthermore, if a user participates in the game as a viewer of another section (for example, if the shared section object As is selected as a spectator in the second map image shown in Figure 17, the user participates as a viewer of the section in which the shared section object As is placed), information regarding the area setting object A and player character PC within that section (for example, information regarding placement location, type, number, development value, etc.) may be made available to the viewer of that section by obtaining it from the server that manages the first section information for that section.

[0142] Furthermore, if another user corresponding to the player character PC that a user is watching (referred to as the first spectator) is watching another spectator (referred to as the second spectator), the game image of the second spectator that the other user is watching may be displayed.

[0143] For example, suppose a third user corresponding to player character PC3 is participating in section B as a viewer, with area setting object A3 located in section B as the target of their spectating. In this case, when the first user sends a request to participate as a viewer with player character PC3 as the target of their spectating, server 102 determines whether the first user is eligible to participate as a viewer with area setting object A3 located in section B as the target of their spectating. If the participation request is approved, the display 12 of the first user's game system 1 will display a game image of the area setting object A3 located in section B, which the third user is spectating, as the target of their spectating.

[0144] In this case, as illustrated in Figure 22, the display 12 of the first user's game system 1 displays an outer frame indicating the first spectator (player character PC3) that the first user has requested to participate in. Inside this outer frame, an inner frame is displayed indicating the second spectator (area setting object A3) that the third user corresponding to the first spectator is watching, and the user information (account name) associated with area setting object A3. Then, within the inner frame, a game image of the area B where the second spectator is located is displayed.

[0145] As illustrated in Figure 22, the virtual camera for displaying the game image after the aforementioned spectator has transitioned is controlled based on the position of the second spectator (for example, area setting object A3). For example, if the second spectator moves within the game space, the virtual camera also moves to follow that movement. The virtual camera may also be controlled to rotate around the second spectator, with the second spectator as the point of focus, based on the operation of the first user. By displaying the game image after the spectator has transitioned in this way, the user can find out the current gameplay status of other users they wish to spectate.

[0146] In other embodiments, if another user corresponding to a player character PC that a user is watching is currently watching another player character as a viewer, that user may instead choose a resident piece (see Figure 19) placed in the game space as their spectator and participate as a viewer in the area where the resident piece is located.

[0147] Furthermore, if another user corresponding to the player character PC that the user has initially been watching changes from a viewer to the operator of that player character PC, the game screen may switch from watching the viewer's target to watching the player character PC as the target of viewing. In this case, server 102 will determine whether the user can participate as a viewer in the area where the player character PC corresponding to the other user is located, and if a positive determination is obtained, the game image with the switched target of viewing may be displayed.

[0148] Furthermore, as an example, a limit may be placed on the number of times the aforementioned spectator object can be changed. By limiting the number of times the spectator object can be changed in this way, it is possible to prevent the phenomenon of a spectator object looping, where a spectator object that has requested to participate as a viewer transitions to the player character PC corresponding to the user who made the participation request. As another example, if the aforementioned looping phenomenon occurs, the participation request to become a viewer may be denied.

[0149] Next, with reference to Figures 23 and 24, we will explain examples of capacity conditions for participating in each section and examples of the changes in the number of participants in each section. Figure 23 is a diagram showing an example of the capacity conditions for each section. Figure 24 is a diagram showing examples of the changes in the number of participants in sections A and B.

[0150] As illustrated in Figure 23, in this embodiment, the capacity for each reserved person, operator, and viewer in each section, the capacity for a resident who is either a reserved person or an operator, and the total viewing capacity for operators and viewers are set. Here, an operator refers to a user who participates in a section by entering the section with a player character and operating that player character (a participant in the section). A viewer refers to a user who participates in a section by watching the viewing target in that section (a viewer in the section). A reserved person refers to a user who has set up a user area within the section (for example, the first area R1 illustrated in Figures 15 and 16).

[0151] The occupancy limit is set based on the processing capacity (e.g., processing costs and communication costs) that the server 102 managing the area can handle for that area, and in the example in Figure 23, it is set to 100. For example, the occupancy limit is set based on the maximum number of terminal devices that can participate, which at least allows the server 102 and the terminal device (game system 1) to perform processes such as editing the game space within the area and sending and receiving game information related to the editing with the server 102 to construct the latest game space. Here, a reserved user is counted even if they do not actually participate in the area as an operator, as long as they have set up a user area within the area. In other words, the occupancy limit is set so that the number of reserved users is predetermined, and while this limits the number of operators that can participate in the area, it ensures that reserved users can always participate in the area as operators.

[0152] The spectator capacity is also set based on the processing capacity of the server 102 managing the section, and is set to 120 in the example shown in Figure 23. Here, viewers primarily perform the task of watching the spectators within the section. Therefore, compared to the operators mentioned above, the processing and communication costs incurred by viewers are lower, and the capacity can be increased by the number of viewers participating, making it possible to relax the spectator capacity compared to the stay capacity. The spectator capacity may be increased or decreased according to the number of people participating in each role in the section. For example, the spectator capacity may be increased if the number of people participating as operators in the section decreases. As an example, the spectator capacity may be set to 100 when the number of people participating as operators in the section is 50, and to 120 when the number of people participating as operators in the section is 20, so that the spectator capacity can be varied.

[0153] The operator capacity, like the occupancy capacity, is set based on the processing capacity of the server 102 managing the area, and is set to 100 in the example shown in Figure 23.

[0154] The capacity for reserved users is set to be less than the number based on the capacity that can be handled by the aforementioned section (e.g., the number of guests or the number of operators), and in the example in Figure 23, it is set to 50. If the capacity for reserved users is set to the number based on the capacity that can be handled by the aforementioned section, it is permissible for the section to be filled only with reserved users, in which case no new operators other than reserved users will be able to join the section. Therefore, the capacity for reserved users may be set based on what is considered an appropriate proportion of reserved users in the section.

[0155] The viewer capacity is set based on the maximum number of terminal devices that can at least perform the necessary processing for users to view the target within the designated area, and is set to 200 in the example shown in Figure 23. As mentioned above, since the processing and communication costs incurred for viewers are lower compared to operators, the viewer capacity can be set higher than the capacity for operators or reserved users.

[0156] Each section may be controlled by the following rules regarding occupancy: A. Areas that have reached their occupancy limit will not be able to accommodate new operators. B. In areas that have reached their spectator capacity, new viewers will not be allowed to participate, except for viewers who have made reservations (i.e., viewers who have placed area setting objects in that area). C. In sections where the spectator capacity has been reached, new operators will be allowed to participate if Rule A is met, and existing viewers will be forcibly removed. D. In sections where the spectator capacity has been reached, new viewers who have made reservations will be allowed to enter, and existing viewers will be forcibly removed. E. If an operator participates as a viewer in the same section, they will be treated as if they are participating in that section as an operator.

[0157] The above rules can be expected to have the following effects: Rule A guarantees that the person who reserves a section will participate as an operator, and that a new operator will not force an existing operator to leave the section. Rules B and D ensure that an increase in viewers in a section does not result in existing operators being forcibly removed from that section. According to Rule C, the operator has priority in joining a section. According to rules B and D, those who have reserved a section will have priority in participating in that section as viewers. According to Rule E, in a section in which you are participating as an operator, you can freely switch between roles as operator and spectator. According to Rule E, even if an operator becomes a viewer of a section they are participating in, they will not forcibly remove other viewers from that section.

[0158] Forced removal from the above-mentioned area may be carried out according to the following rules: F. Viewers who are forcibly removed will be determined based on the elapsed time since they started watching, and will be either the newest or longest-attending viewer (viewers who are forcibly removed may also be selected based on the time of joining or the order of joining). Viewers who have reserved section G will not be subject to forced removal. H. Viewers who are forcibly removed will return to the section where they were before becoming the viewer, acting as the operator. I. If there is no area to return to according to Rule G, move to a different designated game space. For example, the "designated game space" is a special management area (instance room) that does not belong to the aforementioned sections. This management area is where player characters are placed at the start of the game, etc. Furthermore, this management area is a game space that cannot be edited by user operations, and multiple management areas with the same functions are provided. For example, when the participant capacity of a certain management area is reached, a new management area may be created, thereby increasing the participant capacity of that management area. As an example, in this management area, player characters can purchase items, level up according to their game score, receive distributions of items and parameters, select the section they wish to participate in, and be assigned to the section they participate in. As another example, this management area may be a game space with no participant limit (capacity) for operators (player characters).

[0159] In other embodiments, Rule F may also be used to forcibly remove viewers who are watching a different viewing target than the one requested to participate (for example, the viewer example explained using Figure 22).

[0160] In this embodiment, users participating in each section are managed by server 102 using role-based participant lists. For example, server 102 may set up reservation lists, operator lists, and viewer lists for each section and manage participants by describing the accounts of participating users in each participant list. User accounts in each participant list may be described based on arbitrary rules. For example, there may be duplicate user accounts in each participant list, or if certain conditions are met, one of the accounts may be deleted to prevent such duplication.

[0161] Figure 24 illustrates the changes in participants listed in the participant lists for section A and section B. For example, in the top row of Figure 24, section A lists 20 accounts as reservations, 20 accounts as operators, and 20 accounts as viewers. Section B lists 10 accounts as reservations, 10 accounts as operators, and 10 accounts as viewers.

[0162] In this situation with participants in sections A and B, a user who has made a reservation for section A is permitted to participate as an operator for section A. In this case, in the second row of Figure 24, the number of operators for section A is increased by 1, resulting in 21 operator accounts for section A. However, even if a reservation holder participates in section A as an operator, it is only counted as 1 person staying in section A. Specifically, the number of people staying is derived as follows. Number of current reservations + Number of current operators - Number of reservations currently acting as operators = Number of occupants This prevents a reduction in the number of available operators when a reserved person participates as an operator. In this way, when a reserved person participates as an operator in a section, their operator count is increased, but the number of occupants does not increase. Therefore, the occupancy capacity of section A will not be exceeded, but if the spectator capacity of section A is exceeded, one of the existing viewers will be forcibly removed from section A. Note that the participant list for section B will not change due to the participation of the operators mentioned above.

[0163] In other embodiments, when a reservation holder participates as an operator, the number of operators in the participating section may be increased by 1, and the number of reservations in that section may be decreased by 1. For example, in the example of section A above, the number of operators in section A is increased by 1, so there may be 21 operator accounts in section A, and the number of reservations in section A is decreased by 1, so there may be 19 reservation account accounts in section A.

[0164] Next, a user who was participating in section A as an operator is permitted to participate in section B as a viewer. In this case, in the third row of Figure 24, the number of viewers in section B is increased by 1, resulting in 11 viewer accounts in section B. Meanwhile, the number of operators in section A, in which the user was participating as an operator, remains the same in order to ensure that there is a slot available for the user to return to section A as an operator. Also, in section A, the resident piece OBJp1 (see Figure 19) is placed in place of the player character PC1 that was being controlled by the operator. If this process exceeds the viewing capacity of section B, and a newly participating viewer is also a reserved person for section B, one of the existing viewers will be forcibly removed from section B. If the viewing capacity of section B is exceeded, and a newly participating viewer is not a reserved person for section B, participation as a viewer in section B will not be permitted, and the user will continue to play as an operator in section A.

[0165] Next, the user who was participating in section B as a viewer is permitted to return to section A as an operator. In this case, in the fourth row of the diagram in Figure 24, the number of viewers in section B is reduced by 1, so there are 10 viewer accounts in section B. Also, the number of operators in section A to which the user returns as an operator remains the same as the list description, as the slots for the return have been reserved. Then, the player character PC1 that the user was operating is placed in place of the resident piece OBJp1 located in section A.

[0166] On the other hand, as shown in the bottom diagram of Figure 24, if a user has participated in section B as a viewer and a predetermined time (for example, 1 hour) has elapsed, the number of slots available for the user to return to section A as an operator is released. Also, the resident piece OBJp1 that was placed in section A is removed from section A. As a result, the number of operators in section A is reduced by 1, so there are 20 operator accounts in section A. Although the operator who was also a reservation holder has left section A, the number of slots available for that reservation holder to rejoin section A is reserved because the number of reservation holder accounts in section A remains at 20. Furthermore, there is no change in the participant list for section B due to the passage of the predetermined time. After this process is performed, if a user who was participating in section B as a viewer requests to return to section A as an operator, the number of slots available for the user as a reservation holder is reserved in section A, so the number of people allowed in section A will not exceed the capacity of section A, and the user will be able to return to section A as an operator. On the other hand, after this process is completed, if a user who was participating in section B as a viewer requests to return to section A as an operator, and the number of people staying in section A exceeds the capacity, and the user is not a reserved user of section A, then the player character PC1 corresponding to that user will move to a designated game space (e.g., the management area) and play will continue. Alternatively, as another example, if a viewer has joined section B and the aforementioned predetermined time has elapsed, the viewer may be forced to leave section B and return to section A as an operator.

[0167] In the above-mentioned capacity management example, a predetermined number of slots were reserved for participants to return to their section as operators when they participate as viewers. However, such slots may also be reserved in relation to participation in the section in other ways. For example, if an operator of the first section moves to the second section as an operator, or moves to the management area as an operator, a predetermined number of slots may be reserved for them to return to the first section as an operator. This prevents situations where a participant who has temporarily stayed in another section or management area is unable to return to their original section because the original section's capacity is full.

[0168] Furthermore, the process of reserving the aforementioned number of users for a predetermined time indicates that the user slot will be canceled once that predetermined time has elapsed. This process prevents the reservation of a user slot for the original area from remaining if a viewer logs out (ends the game) while watching an area, or if an operator logs out while moving to another area. This process is particularly effective when coordination between server resources managing different areas is difficult. In another embodiment, if it is easy to exchange the logout information mentioned above between server resources managing different areas, the process of canceling the user slot after the predetermined time has elapsed may not be necessary.

[0169] Furthermore, in this embodiment, the area to which a viewer returns to being an operator may be different from the area to which they were participating before becoming a viewer. For example, the user may be allowed to select the area to which they will return as an operator, or it may be one of the areas to which the user is registered as a reserved user. In the former case, a viewer who has area setting object A1 as the object to watch may be able to perform an operation to specify area setting object A1 as the location where player character PC1 will appear in the game space in order to participate as an operator. In response to such an operation, the specified location may be set as the stay location, and a request to participate as an operator is made to the area including the stay location, and if the participation request is approved, player character PC1 may appear near area setting object A1 and participate as an operator in the above area. In this case, a predetermined fee (for example, in-game currency) may be required to realize the appearance of player character PC1 near the object to watch as described above. In the latter case, the area to which the user returns may be selected in the game system 1 that the user is operating, or it may be selected in server 102. In this embodiment, when a user is spectating an area setting object associated with themselves, they can participate as an operator in a section where the area setting object is located in accordance with a predetermined operation. Alternatively, when a user is spectating an area setting object associated with another user, they may be allowed to participate as an operator in a section where the area setting object is located in accordance with a predetermined operation.

[0170] Next, with reference to Figure 25, an example of a specific process executed by game system 1 will be described. Note that DRAM 85 stores data used in other processes in addition to the data shown in Figure 25, but a detailed explanation will be omitted.

[0171] The program memory area of ​​DRAM 85 stores various programs Pa that are executed by the game system 1. In this embodiment, the various programs Pa include application programs (e.g., game programs) for performing information processing based on data acquired from the left controller 3 and / or the right controller 4 and the main unit 2, and communication programs for communicating with other devices (server 102 or other game systems 1). The various programs Pa may be pre-stored in flash memory 84, acquired from a storage medium that can be attached to the game system 1 (e.g., a predetermined type of storage medium installed in slot 23) and stored in DRAM 85, or acquired from other devices via a network such as the Internet and stored in DRAM 85. The processor 81 executes the various programs Pa stored in DRAM 85.

[0172] Furthermore, the data storage area of ​​the DRAM 85 stores various types of data used in information processing and other processes performed in the game system 1. In this embodiment, the DRAM 85 stores operation data Da, communication data Db, player character data Dc, other player character data Dd, game space data De, AC data Df, map data Dg, virtual camera data Dh, spectator mode flag data Di, and image data Dj, etc.

[0173] The operation data Da is operation data acquired as appropriate from the left controller 3 and / or the right controller 4 and the main unit 2, respectively. As described above, the operation data acquired from the left controller 3 and / or the right controller 4 and the main unit 2 includes information about input from each input unit (specifically, each button, analog stick, and touch panel) (specifically, information about operation). In this embodiment, operation data is acquired from the left controller 3 and / or the right controller 4 and the main unit 2, and the operation data Da is updated as appropriate using the acquired operation data. The update cycle of the operation data Da may be updated every frame, which is the cycle of processing executed by the game system 1 described later, or it may be updated every cycle in which the above operation data is acquired.

[0174] The communication data Db includes data to be sent to other devices (server 102 and other game systems 1) and data to be received from other devices. For example, the transmitted data includes information about the operation and status of a player character PC operated by a user of game system 1, and information about the game space modified by the operation of that player character PC. The received data also includes information about the operation and status of other player character PCs operated by users of other game systems 1, and information about the game space modified by the operation of those other player character PCs.

[0175] Player character data Dc is data that shows the position, orientation, posture, actions, state, abilities, and remaining energy parameters of the player character (hereinafter referred to as the first player character PC1) controlled by the user of game system 1 in the game space. Other player character data Dd is data that shows the position, orientation, posture, actions, state, abilities, and remaining energy parameters of the other player characters (hereinafter referred to as the second player character PC2) controlled by the users of other game systems 1 in the game space.

[0176] Game space data De is data that indicates the state of the game space. For example, for each coordinate set in the game space, Game space data De has parameters set regarding the state of terrain objects and the state of decorative objects. For multiple coordinates, parameters are stored that indicate whether or not an object (terrain object, area setting object, decorative object, resident piece, other object, etc.) exists at that coordinate, as well as the type and state of the existing object (including editor, embedded information, and textures).

[0177] Interaction data Df is data related to interaction points assigned to the player character (first player character PC1) controlled by the user of game system 1 (which can also be called interaction points assigned to the user of game system 1) and interaction points assigned to other player characters.

[0178] Map data Dg is data used to display area information images, showing placement information for each area, such as player characters, area setting objects, and area-shared objects, as well as development value information.

[0179] Virtual camera data Dh is data that indicates the position, direction, field of view, etc., of virtual cameras placed in the game space.

[0180] The Spectator Mode Flag Data Di is data that indicates the spectator mode flag, which is set to "on" when the game is being played in spectator mode.

[0181] Image data Dj is data used to display images (for example, images of each player character PC, images of various objects, map images, background images, etc.) on a display screen (for example, the display 12 of the main unit 2).

[0182] Next, with reference to Figures 26 to 32, a detailed example of game processing, which is an example of information processing in this embodiment, will be described. Figure 26 is a flowchart showing an example of game processing executed by game system 1. Figure 27 is a subroutine showing an example of player character control processing in step S124 of Figure 26. Figure 28 is a subroutine showing an example of spectator mode transition processing in step S146 of Figure 27. Figure 29 is a subroutine showing an example of dwell area movement processing in step S148 of Figure 27. Figure 30 is a subroutine showing an example of spectator mode processing in step S151 of Figure 27. Figure 31 is a subroutine showing an example of spectator area movement processing in step S187 of Figure 30. Figure 32 is a subroutine showing an example of dwell mode transition processing in step S190 of Figure 30. Figure 33 is a subroutine showing an example of other player character control processing in step S124 of Figure 26. In this embodiment, the series of processes shown in Figures 26 to 33 are performed by the processor 81 executing predetermined application programs (game programs), communication programs, etc., included in various programs Pa. Furthermore, the timing at which the game processing shown in Figures 26 to 33 begins is arbitrary.

[0183] The processing steps in the flowcharts shown in Figures 26 to 33 are merely examples; the order of the steps can be changed, or other processing can be performed in addition to (or instead of) the processing of each step, as long as similar results can be obtained. Furthermore, in this embodiment, the processing of each step in the flowchart is described as being performed by the processor 81, but some of the processing steps in the flowchart can be performed by a processor other than the processor 81 or a dedicated circuit. In addition, some of the processing performed in the main unit 2 may be performed by other information processing devices that can communicate with the main unit 2 (for example, a server 102 or other game system 1 that can communicate with the main unit 2 via a network). In other words, each of the processes shown in Figures 26 to 33 may be performed by multiple information processing devices, including the main unit 2, working together.

[0184] In Figure 26, the processor 81 performs initial setup for game processing (step S121) and proceeds to the next step. For example, in the initial setup described above, the processor 81 initializes the parameters for the processing described below and updates each data. As an example, if login to the server 102 is required to start a game in which multiple users participate, the processor 81 performs login processing with the server 102 in accordance with the login operation indicated by the operation data Da. The processor 81 also sends a participation request to the server 102 requesting the allocation of a section in which the user will participate as an operator (for example, allocation of a section in which the user is set as a reserved user) based on the user operation instruction input, obtains data related to the game space in the allocated section, and constructs the game space based on that data. The processor 81 then places the first player character PC1 in a predetermined posture at the default position in the game space, and places a virtual camera etc. at a position based on the position of the first player character PC1, and updates the player character data Dc, game space data De, and virtual camera data Dh. Furthermore, the processor 81 sets a user area based on the position where the area setting object is located, and sets the game space data De, depending on the status of the area setting object associated with the first player character PC1 in the game space (for example, when the game is first started, the area setting object is placed in the default position, and when the game is resumed midway, it is set to the state before the game was interrupted based on the data obtained in the login process, etc.).

[0185] Next, the processor 81 acquires operation data from the left controller 3, the right controller 4, and / or the main unit 2, updates the operation data Da (step S122), and proceeds to the next step.

[0186] Next, the processor 81 determines whether or not to display the map (step S123). For example, the processor 81 refers to the operation data Da and makes a positive determination in step S123 if a user operation instruction input to display the map has been made or if the map image is currently being displayed. The processor 81 also refers to the operation data Da and makes a negative determination in step S123 if a user operation instruction input to terminate the map display has been made or if the map image is not currently being displayed. If the processor 81 decides not to display the map, it proceeds to step S124. On the other hand, if the processor 81 decides to display the map, it proceeds to step S126.

[0187] In step S124, the processor 81 performs player character control processing and proceeds to the next step. The player character control processing in step S124 will be described below with reference to Figure 27.

[0188] In Figure 27, the processor 81 refers to the spectator mode flag data Di to determine whether the system is currently in spectator mode (step S141). If the spectator mode flag is set to off, the processor 81 proceeds to step S142. On the other hand, if the spectator mode flag is set to on, the processor 81 proceeds to step S151.

[0189] In step S142, the processor 81 performs a process to set the actions of the first player character PC1 and proceeds to the next step. For example, the processor 81 sets the position, direction, posture, actions, and state of the first player character PC1 based on the operation input indicated by the operation data Da and virtual physics calculations in the game space (e.g., virtual inertia and gravity), and updates the player character data Dc.

[0190] Next, the processor 81 determines whether the first player character PC1 is configured to edit objects (terrain objects, decorative objects, area setting objects, other objects, etc.) (step S143). If the processor 81 is configured to edit objects, it proceeds to step S144. On the other hand, if the processor 81 is not configured to edit objects, it proceeds to step S145.

[0191] In step S144, the processor 81 performs the process of editing an object in the game space and proceeds to step S145. For example, the processor 81 updates the game space data De by editing the object to be edited in the game space based on the actions of the configured first player character PC1 and updating the parameters of the object according to the edit. The processor 81 also sets the editor of the edited object to the first player character PC1 and updates the game space data De. As an example, if a region setting object in the game space is edited in step S144, the processor 81 updates the parameters of the region setting object based on the edit, and also sets the user area (e.g., first area R1) of the user operating the first player character PC1 according to the placement of the region setting object and updates the game space data De. As mentioned above, object editing includes updating the state of various objects such as creation, movement, deletion, duplication, joining, appearance change, and information embedding, but a detailed explanation is omitted here.

[0192] In step S145, the processor 81 determines whether or not to transition to a viewing mode in which the target of viewing will be viewed. For example, the processor 81 refers to the operation data Da and determines in step S145 that the user has entered an operation instruction to transition to a viewing mode in which the user becomes a viewer and watches the target of viewing (for example, when an operation instruction is entered in step S128 described later in which the target of viewing is set) or when the process of transitioning to viewing mode is in progress. If the processor 81 decides to watch the target of viewing, it proceeds to step S146. On the other hand, if the processor 81 decides not to watch the target of viewing, it proceeds to step S147.

[0193] In step S146, the processor 81 performs the spectator mode transition process and proceeds to step S147. The spectator mode transition process in step S146 will be explained below with reference to Figure 28.

[0194] In Figure 28, the processor 81 sets the spectator target that the user wishes to watch (step S161) and proceeds to the next step. For example, the processor 81 sets the spectator target according to the method described in the overview of the game processing example above, based on the operation instruction input for selecting the spectator target indicated by the operation data Da.

[0195] Next, the processor 81 sets a participation request (step S162) to request participation as a viewer in the section where the above-configured spectators are located, and proceeds to the next step. For example, the processor 81 includes information about the spectators and the section where the spectators are located in the participation request and sets it in the communication data Db. Then, the processor 81 sends the participation request in the set notification data Db as transmission data to the server 102 in the communication processing in step S131, which will be described later, to make the participation request.

[0196] Next, the processor 81 determines whether or not the server 102 has granted permission for spectating in the participation request (step S163). For example, if the processor 81 has received server instruction data indicating permission to spectate by referring to the communication data Db received from the server 102 in the communication processing described later in step S131, it makes a positive determination in step S163. If spectating is permitted, the processor 81 proceeds to step S164. On the other hand, if spectating is not permitted, the processor 81 proceeds to step S168.

[0197] In step S164, the processor 81 places the resident piece OBJp1 (see Figure 19) in the game space in place of the first player character PC1, updates the player character data Dc and game space data De, and proceeds to the next step. If the resident piece OBJp1 has already been placed in the game space in place of the first player character PC1 before the processing in step S164 is executed, the processing in step S164 may be canceled.

[0198] Next, the processor 81 performs a process to determine the spectator target set in step S161 (step S165) and proceeds to the next step. For example, the processor 81 constructs a game space based on the data regarding the game space in the area where the spectator target is located, obtained from the server 102 along with the data indicating permission to watch, and updates the game space data De. Then, the processor 81 extracts the spectator target set in step S161 from the constructed game space, determines the spectator target in that game space, and updates the game space data De. Note that the spectator target determined in step S165 may be different from the spectator target set in step S161. For example, if another user corresponding to the spectator target set in step S161 is watching another spectator target, that spectator target being watched may be determined in step S165. In this case, the server 102 determines whether or not the other spectators can be viewed and sends data indicating that viewing is permitted in response to the participation request. Based on this data, the spectators are determined in step S165. In addition, if a hidden first player character PC1 is placed within the area, the hidden first player character PC1 may be placed near or overlapping with the spectators. In this case, the processor 81 updates the player character data Dc based on the placement of the hidden first player character PC1 and may also determine that the hidden first player character PC1 is a spectator.

[0199] Next, the processor 81 updates the spectator mode flag data Di by setting the spectator mode flag to ON (step S166), and proceeds to the next step.

[0200] Next, the processor 81 sets up a virtual camera based on the position of the object to be viewed determined in step S165 (step S167), and terminates the processing by the subroutine. For example, the processor 81 sets up a virtual camera at a predetermined distance away in a predetermined direction, using the object to be viewed determined in step S165 as the point of focus, and updates the virtual camera data Dh. The processor 81 also sets up a frame indicating the object to be viewed at the current time (see Figures 20 and 21), or an outer frame indicating the object to be viewed at the current time and an inner frame indicating other objects being viewed by other users corresponding to that object (see Figure 22), and controls the display in the drawing process in step S130, which will be described later.

[0201] On the other hand, in step S168, the processor 81 determines whether or not the server 102 has denied permission to watch the match as requested. For example, if the processor 81 receives server instruction data indicating that the viewing is denied by referring to the communication data Db received from the server 102 in the communication processing in step S131 described later, it makes a positive determination in step S168. If the viewing is denied, the processor 81 proceeds to step S169. On the other hand, if the viewing is not denied, the processor 81 terminates the processing by the subroutine.

[0202] In step S169, the processor 81 notifies the user that the spectator request has been denied, terminates the process of transitioning to spectator mode, and ends the processing by the subroutine. For example, the processor 81 sets an image indicating that the spectator request has been denied and displays it on the display 12 in the drawing process in step S130, which will be described later. Also, if the resident piece OBJp1 is placed in the game space instead of the first player character PC1, the processor 81 returns the resident piece OBJp1 to the first player character PC1 and updates the player character data Dc.

[0203] Returning to Figure 27, in step S147, the processor 81 determines whether the first player character PC1 is attempting to move to another section. For example, the processor 81 refers to the operation data Da and determines in step S147 that an operation instruction input has been made for the first player character PC1 to move to another section (for example, an adjacent section) or that the section movement process is in progress. If the first player character PC1 is attempting to move to another section, the processor 81 proceeds to step S148. On the other hand, if the first player character PC1 is not attempting to move to another section, the processor 81 proceeds to step S149.

[0204] In step S148, the processor 81 performs a residency area movement process and proceeds to step S149. The residency area movement process in step S148 will be described below with reference to Figure 29.

[0205] In Figure 29, the processor 81 sets the destination area (step S171) and proceeds to the next step. For example, based on the operation instruction input that moves the first player character PC1 indicated by the operation data Da, the processor 81 sets the area to which the first player character PC1 is to move.

[0206] Next, the processor 81 sets a participation request (step S172) to request the operator to join the designated destination area, and proceeds to the next step. For example, the processor 81 includes information such as the destination area to which the operator is to move in the participation request and sets it in the communication data Db. Then, the processor 81 sends the participation request in the set notification data Db as transmission data to the server 102 in the communication processing in step S131, which will be described later, to make the participation request.

[0207] Next, the processor 81 determines whether or not the server 102 has granted permission for participation by movement in the participation request (step S173). For example, if the processor 81 has received server instruction data indicating permission for participation by movement by referring to the communication data Db received from the server 102 in the communication processing in step S131 described later, it makes a positive determination in step S173. If the participation is permitted, the processor 81 proceeds to step S174. On the other hand, if the participation is not permitted, the processor 81 proceeds to step S176.

[0208] In step S174, the processor 81 initiates a movement animation to move the first player character PC1 to another area and proceeds to the next step. In a single execution of step S174, the processor 81 controls actions that span multiple frames (for example, the movement animation of the first player character PC1) to proceed at the rate of one frame. As a result, the process of step S174 is repeatedly executed over multiple frames, causing the first player character PC1 to perform a series of actions related to the movement animation.

[0209] Next, the processor 81 sets the position where the first player character PC1 will be placed in the destination area after the move to the current area is completed (step S175), and then terminates the processing by the subroutine. For example, the processor 81 constructs a game space based on the data regarding the game space in the destination area obtained from the server 102 along with the data indicating permission to participate, and updates the game space data De. Then, the processor 81 sets the position where the first player character PC1 will be placed in the constructed game space, and updates the player character data Dc based on this setting.

[0210] On the other hand, in step S176, the processor 81 determines whether or not the server 102 has denied the participation request. For example, if the processor 81 receives server instruction data indicating that participation is denied by referring to the communication data Db received from the server 102 in the communication processing in step S131 described later, it makes a positive determination in step S176. If the participation is denied, the processor 81 proceeds to step S177. On the other hand, if the participation is not denied, the processor 81 terminates the processing by the subroutine.

[0211] In step S177, the processor 81 initiates a "cannot move to another area" animation to inform the player that the first player character PC1 cannot move to another area, and then terminates the processing by the subroutine. In a single execution of step S177, the processor 81 is controlled to perform only one frame of an action that takes place over multiple frames (for example, the "cannot move to another area" animation by the first player character PC1). As a result, the first player character PC1 performs a series of actions related to the "cannot move to another area" animation by repeatedly executing step S177 over multiple frames.

[0212] Returning to Figure 27, the processor 81 determines whether the configured action for the first player character PC1 is any other action. If the other action is configured, the processor 81 proceeds to step S150. On the other hand, if the other action is not configured, the processor 81 terminates the processing by the subroutine.

[0213] In step S150, the processor 81 performs other control processing and terminates the processing by the subroutine. For example, if the processor 81 refers to the operation data Da and receives an operation instruction to display and move the targeting reticle T, it moves the position of the targeting reticle T in accordance with the operation instruction and sets the display information of the object that is overlapping with the targeting reticle T to be displayed. As another example, if the processor 81 refers to the operation data Da and receives an operation instruction to assign interaction data (for example, evaluation data such as "like") to another player character PC, it sets the operation of the first player character PC1 based on a predetermined action in accordance with the operation instruction, updates the player character data Dc, stores the interaction data to be assigned in the communication data Db, and terminates the processing by the subroutine.

[0214] On the other hand, in step S151, the processor 81 performs spectator mode processing and terminates the processing by the subroutine. The spectator mode processing in step S151 will be described below with reference to Figure 30.

[0215] In Figure 30, the processor 81 determines whether the spectator being watched in spectator mode is also watching another spectator (step S181). If the spectator is not watching another spectator, the processor 81 proceeds to the next step S182. On the other hand, if the spectator is not watching another spectator, the processor 81 proceeds to the next step S183.

[0216] In step S182, the processor 81 controls the virtual camera based on the user's input and the object being viewed, and proceeds to step S184. For example, the processor 81 controls the position and / or orientation of the virtual camera so that the object being viewed (e.g., another player character or area setting object) becomes the point of focus, and updates the virtual camera data Dh by controlling the position and / or orientation of the virtual camera based on the user operation instructions indicated by the operation data Da. The processor 81 also sets a frame (see Figures 20 and 21) that indicates the current object being viewed, and controls its display in the drawing process in step S130, which will be described later. If a hidden first player character PC1 is positioned corresponding to the viewer, the processor 81 may control the position and / or orientation of the virtual camera so that the hidden first player character PC1 becomes the point of focus, and updates the virtual camera data Dh by controlling the position and / or orientation of the first player character PC1 and the virtual camera based on the user operation instructions indicated by the operation data Da.

[0217] Meanwhile, in step S183, the virtual camera is controlled based on the user's input and the object being viewed by the viewing target, and the process proceeds to step S184. For example, the processor 81 controls the position and / or orientation of the virtual camera so that the viewing target (e.g., another player character) is viewed by another user, and updates the virtual camera data Dh by controlling the position and / or orientation of the virtual camera based on the user operation instructions indicated by the operation data Da. The processor 81 also sets an outer frame indicating the current viewing target and an inner frame (see Figure 22) indicating the other viewing target being viewed by the other user corresponding to that viewing target, and controls the display in the drawing process in step S130, which will be described later.

[0218] In step S184, the processor 81 refers to the operation data Da to determine whether or not there was an operation instruction from the user while the spectator was watching the game. If there was an operation instruction from the user, the processor 81 proceeds to step S185. On the other hand, if there was no operation instruction from the user, the processor 81 proceeds to step S186.

[0219] In step S185, the processor 81 performs processing according to the operation instruction and proceeds to step S186. For example, if the processor 81 refers to the operation data Da and an operation instruction has been given to assign interaction data (e.g., evaluation data such as "like") to the object being watched, the processor 81 stores the interaction data to be assigned in the communication data Db according to the operation instruction.

[0220] In step S186, processor 81 determines whether the spectator is attempting to move to another section. If the spectator is attempting to move to another section, processor 81 proceeds to step S187. On the other hand, if the spectator is not attempting to move to another section, processor 81 proceeds to step S188.

[0221] In step S187, the processor 81 performs the spectator area movement process and proceeds to step S188. The spectator area movement process in step S187 will be described below with reference to Figure 31.

[0222] In Figure 31, the processor 81 sets the spectator area to which the object to be moved will be (step S201) and proceeds to the next step. For example, the processor 81 sets the spectator area to which the object to be spectated will be moved.

[0223] Next, the processor 81 sets a participation request to request participation as a viewer in the designated viewing area (step S202), and proceeds to the next step. For example, the processor 81 includes information such as the area to which the viewer is to move in the participation request and sets it in the communication data Db. Then, the processor 81 sends the participation request in the set notification data Db as transmission data to the server 102 in the communication processing in step S131, which will be described later, to make the participation request.

[0224] Next, the processor 81 determines whether or not the server 102 has granted permission for participation by movement in the participation request (step S203). For example, if the processor 81 has received server instruction data indicating permission for participation by movement by referring to the communication data Db received from the server 102 in the communication processing in step S131 described later, it makes a positive determination in step S203. If the participation is permitted, the processor 81 proceeds to step S204. On the other hand, if the participation is not permitted, the processor 81 proceeds to step S206.

[0225] In step S204, the processor 81 initiates a viewing area transition animation to move to another viewing area and proceeds to the next step. In a single execution of step S204, the processor 81 is controlled to perform only one frame of animation for actions that span multiple frames (for example, a viewing area transition animation to move to another viewing area). As a result, the process of step S204 is repeatedly executed over multiple frames, thereby performing a series of animations related to the viewing area transition animation.

[0226] Next, after the spectator section movement is completed, the processor 81 sets the spectator position in the destination section (step S205) and terminates the processing by the subroutine. For example, the processor 81 constructs a game space based on the data regarding the game space in the destination section obtained from the server 102 along with the data indicating permission to participate, and updates the game space data De. Then, the processor 81 sets the position of the virtual camera based on the position of the spectator in the constructed game space and updates the virtual camera data Dh.

[0227] On the other hand, in step S206, the processor 81 determines whether or not the server 102 has denied the participation request. For example, if the processor 81 receives server instruction data indicating that participation is denied by referring to the communication data Db received from the server 102 in the communication processing in step S131 described later, it makes a positive determination in step S206. If the participation is denied, the processor 81 proceeds to step S207. On the other hand, if the participation is not denied, the processor 81 terminates the processing by the subroutine.

[0228] In step S207, the processor 81 starts a viewing area movement restriction animation to inform the viewer that they cannot move to another viewing area, and then terminates the processing by the subroutine. In a single execution of step S207, the processor 81 is controlled to perform only one frame of animation for actions that span multiple frames (for example, the viewing area movement restriction animation indicating that it is not possible to move to another viewing area). As a result, the process of step S207 is repeatedly executed over multiple frames, resulting in a series of animations related to the viewing area movement restriction animation.

[0229] In this embodiment, if the player object PC, which is the object being watched, moves to another section, a request to participate as a viewer in that other section will be made to follow the movement. However, in other embodiments, if the object being watched moves to another section, the spectating mode may be terminated and the mode may be changed to stay mode. In this case, the spectating section movement process in step S187 may be canceled, and an affirmative determination may be made in step S189, which will be described later.

[0230] Returning to Figure 30, in step S188, the processor 81 determines whether or not to transition to a stay mode in which the first player character PC1 stays in the game space and plays the game. For example, the processor 81 refers to the operation data Da and makes a positive determination in step S188 if the user has given an operation instruction to end the spectator mode or if the process of transitioning to stay mode is underway. As another example, the processor 81 refers to the operation data Da and makes a positive determination in step S188 if an operation instruction has been given to specify the position in which the first player character PC1 will appear (for example, an operation instruction to specify an area setting object as the position in which the first player character PC1 will appear). If the processor 81 transitions to stay mode, it proceeds to step S190. On the other hand, if the processor 81 does not transition to stay mode, it proceeds to step S189.

[0231] In step S189, the processor 81 determines whether or not forced exit has been instructed. For example, if the processor 81 receives forced exit data from the server 102, or if spectator movement is denied in step S187, it makes a positive determination in step S189. If forced exit has been instructed, the processor 81 proceeds to step S190. On the other hand, if forced exit has not been instructed, the processor 81 terminates the processing by the subroutine.

[0232] In step S190, the processor 81 performs a stay mode transition process and terminates the processing by the subroutine. The stay mode transition process in step S190 will now be described with reference to Figure 32.

[0233] In Figure 32, the processor 81 sets the dwelling area and dwelling position where the first player character PC1 will stay (step S211), and then proceeds to the next step. As a first example, if the operation data Da indicates an operation instruction input specifying a position where the first player character PC1 will appear (for example, an area setting object is specified as the position to appear), the processor 81 sets the specified position as the dwelling position and sets the area containing that dwelling position as the dwelling area. As a second example, if the position where the first player character PC1 will appear is not indicated by user operation input, the processor 81 sets the position where the first player character PC1 was staying before transitioning to spectator mode as the dwelling position and sets the area containing that dwelling position as the dwelling area.

[0234] Next, the processor 81 sets a participation request (step S212) to request the user to join as an operator at the configured location and area, and proceeds to the next step. For example, the processor 81 includes information about the configured location and area, as well as information such as the user account that will be the operator and the first player character PC1, in the participation request and sets it in the communication data Db. Then, the processor 81 sends the participation request in the set notification data Db as transmission data to the server 102 in the communication processing in step S131, which will be described later, to make the participation request.

[0235] Next, the processor 81 determines whether or not the server 102 has granted permission for the stay in the participation request (step S213). For example, if the processor 81 has received server instruction data indicating permission for the stay by referring to the communication data Db received from the server 102 in the communication processing described later in step S131, it makes a positive determination in step S213. If the stay is permitted, the processor 81 proceeds to step S214. On the other hand, if the stay is not permitted, the processor 81 proceeds to step S218.

[0236] In step S214, the processor 81 performs a process to determine the dwelling area and dwelling location set in step S211, and proceeds to step S217. For example, the processor 81 constructs a game space based on the data regarding the game space in the dwelling area obtained from the server 102 along with the data indicating permission to stay, and updates the game space data De. Then, the processor 81 places the first player character PC1 in the constructed game space and updates the player character data Dc. If a dwelling piece OBJp1 (see Figure 19) is placed at the dwelling location, the processor 81 places the first player character PC1 in place of the dwelling piece OBJp1. The dwelling area and dwelling location determined in step S214 may differ from the dwelling area and dwelling location set in step S211. For example, if the server 102 instructs participation in a different dwelling area or dwelling location, that dwelling area or dwelling location may be determined in step S214. In this case, server 102 determines whether or not the person can stay in the different accommodation areas or locations mentioned above, and sends data indicating that the person is permitted to stay in response to the participation request. Based on this data, the person to be watched is determined in step S214.

[0237] On the other hand, in step S215, the processor 81 determines whether or not the server 102 has denied permission to stay as requested. For example, if the processor 81 receives server instruction data indicating that the stay is denied by referring to the communication data Db received from the server 102 in the communication processing in step S131 described later, it makes a positive determination in step S215. If the stay is denied, the processor 81 proceeds to step S216. On the other hand, if the stay is not denied, the processor 81 terminates the processing by the subroutine.

[0238] In step S216, the processor 81 places the first player character PC1 in the management area and proceeds to step S217. For example, the processor 81 constructs a game space based on the data regarding the game space in the management area obtained from the server 102 along with the data indicating that the stay is not permitted, and updates the game space data De. Then, the processor 81 places the first player character PC1 in the constructed game space and updates the player character data Dc.

[0239] In step S217, the processor 81 updates the spectator mode flag data Di by setting the spectator mode flag to off, and proceeds to the next step.

[0240] Next, the processor 81 sets a virtual camera based on the position of the first player character PC1 set in step S214 or S216 (step S218), and terminates the processing by the subroutine. For example, the processor 81 sets a virtual camera at a predetermined distance away in a predetermined direction, with the first player character PC1 as the point of focus, and updates the virtual camera data Dh. The processor 81 also removes the frame indicating the spectator object, etc., that was displayed in spectator mode, and terminates the process of transitioning to stay mode.

[0241] Returning to Figure 26, after the player character control processing in step S124, the processor 81 performs other player character control processing (step S125) and proceeds to step S130. The other player character control processing in step S125 will now be explained with reference to Figure 33.

[0242] In Figure 33, the processor 81 determines whether the processing in steps S222 to S226 has been completed for all other player character PCs placed in the game space (step S221). If the processing in steps S222 to S226 has not been completed for any of the other player character PCs, the processor 81 proceeds to step S222. On the other hand, if the processing in steps S222 to S226 has been completed for all other player character PCs, the processor 81 terminates the processing by the subroutine.

[0243] In step S222, the processor 81 selects a player character PC from among the other player character PCs placed in the game space that has not completed the processing in steps S222 to S226, and proceeds to the next step.

[0244] Next, the processor 81 sets the operation of the other player character PC being processed based on the communication data Db (step S223), and proceeds to the next step. For example, the processor 81 obtains information about the other player character PC from the communication data Db, which was received via the server 102 from the game system 1 of another user that is operating the other player character PC being processed. Based on this information, the processor 81 sets the operation of the other player character PC and updates the other player character data Dd. In the other user's game system 1, the process including step S124 is performed with the player character PC operated by that other user as the processing target, and the communication data generated according to the processing result is transmitted from the game system 1 via the server 102. Then, in step S131, which will be described later, the data transmitted from the other user's game system 1 via the server 102 is appropriately received and stored in the communication data Db, and the data stored in the communication data Db is used in the process of step S223 and the processes of steps S224 to S226 described later.

[0245] Next, the processor 81 determines, based on the communication data Db, whether the game space has been altered by the actions of another player character PC being processed (step S224). For example, the processor 81 determines, based on information about the game space received via the server 102 from the game system 1 of another user operating the other player character PC being processed, whether the game space has been altered by that other player character PC. If the game space has been altered by the actions of the other player character PC being processed, the processor 81 proceeds to step S225. On the other hand, if the game space has not been altered by the actions of the other player character PC being processed, the processor 81 proceeds to step S226.

[0246] In step S225, the processor 81 performs a process to modify the game space based on the actions of the other player character PC being processed, based on the communication data Db, and proceeds to step S226. For example, the processor 81 obtains information from the communication data Db regarding the game space modified by the actions of the other player character PC, which was received via the server 102 from the game system 1 of the other user operating the other player character PC being processed. Then, based on the above information, the processor 81 updates the game space data De by updating the parameters in the coordinates within the game space relating to the object edited by the actions of the other player character PC being processed. As an example, if a region setting object has been edited in the game space by the actions of the other player character PC being processed, the processor updates the game space data De by setting a user region based on the position of the region setting object.

[0247] In step S226, the processor 81 performs other processing related to other player character PCs that are being processed, and then returns to step S221 to repeat the process.

[0248] Returning to Figure 26, if it is determined in step S123 that a map display should be performed, the processor 81 performs a map generation process (step S126) and proceeds to the next step. For example, the processor 81 sets transmission data in communication data Db to request server 102 to send map data used to display the map image. Then, the processor 81 refers to map data Dg to obtain map display information received from server 102 and sets up a virtual space for generating a section information image (map image; see Figure 17) based on that information. During the period in which step S126 is performed, the processor 81 may place a resident piece OBJp1 (see Figure 19) in the game space in place of the first player character PC1 and update the player character data Dc and game space data De.

[0249] Furthermore, the map generation process in step S126 described above may also be made executable in the initial setup in step S121 in response to user operation instructions. In this case, based on a user operation instruction to select one of the map-displayed sections, the selected section may be assigned as the section where the first player character PC1 will initially stay. Alternatively, based on a user operation instruction to select one of the map-displayed section information images, the user may initially participate as a viewer of the section where the in-game content corresponding to the selected section information image is placed, with the selected content being the object of viewing.

[0250] Next, the processor 81 refers to the operation data Da and determines whether or not a user operation instruction input has been made to select a parcel information image displayed on the map image (step S127). If a user operation instruction input to select a parcel information image has been made, the processor 81 terminates the map display and proceeds to step S146 (see Figure 27). On the other hand, if a user operation instruction input to select a parcel information image has not been made, the processor 81 proceeds to step S130.

[0251] In step S130, the processor 81 performs drawing processing and proceeds to the next step. In this embodiment, the processor 81 controls the display 12 to display images of the game space and map images that reflect the results of the processing in steps S122 to S127. As an example, the processor 81 sets up a game space including each object, user area, aiming reticle, text information, image information, etc., based on the results of the above processing and game space data De. The processor 81 also places and operates the player character PCs in the game space based on the player character data Dc and other player character data Dd. The processor 81 also sets the position and / or orientation of a virtual camera for generating display images based on virtual camera data Dh and places the virtual camera in the game space. Then, it generates an image of the game space as seen from the set virtual camera and controls the display 12 to display the game space image. As another example, the processor 81 places a virtual camera in the virtual space for map image generation set in step S126 above, updates the virtual camera data Dh, generates a map image of the virtual space as seen from the virtual camera, and controls the display 12 to display the map image. In either example, the processor 81 may move the virtual camera and update the virtual camera data Dh based on the operation data Da.

[0252] Next, the processor 81 performs communication processing (step S131) ​​and proceeds to the next step. For example, the processor 81 prepares transmission data to be sent to the server 102, stores it in the communication data Db, and sends it to the server 102. The processor 81 also stores received data from the server 102 in the communication data Db. For example, the processor 81 prepares information regarding the operation and state of the player character PC (first player character PC1) operated by the user, based on the player character data Dc, and stores it in the communication data Db as part of the transmission data. The processor 81 also prepares information regarding objects edited by the player character PC operated by the user, information regarding the user area associated with the player character PC operated by the user, etc., as information regarding the game space modified by the operation of the player character PC, based on the game space data De, and stores it in the communication data Db as part of the transmission data. The processor 81 also stores data indicating that AC data should be assigned to another player character, based on the data for assigning AC data to other player characters stored in the AC data Df, in the communication data Db as part of the transmission data. Furthermore, if the received data from the server 102 contains map display information, the processor 81 updates the map data Dg using that map display information.

[0253] Next, the processor 81 determines whether to end the game process (step S132). As conditions for ending the game process in step S132, for example, there are cases where the conditions for ending the game process are satisfied, the user has performed an operation to end the game process, the user has performed an operation to log off, and so on. If the processor 81 does not end the game process, it returns to step S122 and repeats the process. Also, if the processor 81 ends the game process, it transmits data indicating that the game has ended (logged off) to the server 102 and ends the process according to this flowchart. Thereafter, the series of processes from step S122 to step S132 are repeatedly executed until it is determined in step S132 to end the process.

[0254] Next, referring to FIG. 34, the data and management program stored in the storage unit 105 of the server 102 will be described. Note that in addition to the data shown in FIG. 34, the server 102 also stores data used in other processes, but detailed descriptions thereof are omitted.

[0255] As shown in FIG. 27, in the data storage area of the storage unit 105, communication data Dm, login data Dn, game space data Do, participation list data Dp, capacity data Dq, communication data Dr, and map data Ds, etc. are stored. Also, in the program storage area of the storage unit 105, various program groups Pb are stored as management programs for realizing the above processes.

[0256] The communication data Dm stores the received data received from each of the plurality of game systems 1 and also stores the transmission data to be transmitted to each of the plurality of game systems 1.

[0257] The login data Dn is data used in the login process for each user of the game system 1. The login data Dn includes, in addition to the ID and password for each user confirmed in the login process, data indicating the login / logoff status, login history, game spaces where the participation of the logged-in user is permitted, and so on.

[0258] The game space data Do is data indicating the state of each game space and the state of the player character PC based on data related to the player character PC received from each game system 1, data related to objects and user areas in each game space received from each game system 1, and the like.

[0259] The participation list data Dp is data indicating user accounts registered by role (reserver, operator, viewer) in each section.

[0260] The capacity data Dq is data indicating the capacity of each section.

[0261] The communication data Dr is management data that aggregates the communication data assigned to each user (that is, the player character PC operated by the user).

[0262] The map data Ds is data indicating area setting objects arranged in each game space, the arrangement positions of player characters, the development values for each section, etc. for creating a section information image in the game space for each section.

[0263] Next, referring to FIGS. 35 and 36, the details of the processing performed in the server 102 will be described. Here, in the flowcharts shown in FIGS. 35 and 36, mainly the above-described game processing in which a plurality of users play while sharing a game space by operating player characters PC will be described, and detailed description of other processing not directly related to these processes will be omitted. Also, in FIGS. 35 and 36, each step executed by the control unit 104 is abbreviated as "S".

[0264] The processing steps in the flowcharts shown in Figures 35 and 36 are merely examples, and the order of the steps can be changed if similar results can be obtained, or other processes can be performed in addition to and / or instead of each step. Furthermore, in this embodiment, the processing of each step in the flowchart is described as being performed by the control unit 104 (CPU), but the processing of some steps in the flowchart can be performed by the control unit 104 and the processing of other steps can be performed by a processor other than the control unit 104 or a dedicated circuit, or all steps in the flowchart can be performed by a processor other than the control unit 104 or a dedicated circuit.

[0265] In Figure 35, the control unit 104 of the server 102 sets the game space, capacity, and participant list (step S251), and then proceeds to the next step. For example, the control unit 104 initializes the game space, which is divided into multiple sections, and updates the game space data Do. The control unit 104 also sets the capacity for each section used in the game processing and updates the capacity data Dq, in accordance with the method described in the overview of the game processing example above. The control unit 104 also writes the user accounts to be registered as reservers for each section used in the game processing into the participant list and updates the participant list data Dp, in accordance with the method described in the overview of the game processing example above.

[0266] Next, the control unit 104 receives the transmission data sent from each of the game systems 1 and stores it in the communication data Dm (step S252), and then proceeds to the next step.

[0267] Next, the control unit 104 determines whether the data received in step S201 is data indicating login / logoff (step S253). If the data is login data or logoff data, the control unit 104 proceeds to step S254. On the other hand, if the data is neither login data nor logoff data, the control unit 104 proceeds to step S255.

[0268] In step S254, the control unit 104 performs login / logoff processing and proceeds to the next step. As an example, the control unit 104 determines whether or not to allow the user of game system 1 who sent the login data to log in. If the control unit 104 allows the login, it sets the user of game system 1 who sent the login data to the logged-in state and updates the login data Dn. The control unit 104 then sets transmission data indicating information about login permission to the user in communication data Dm and sends the login data to the user's game system 1. As another example, the control unit 104 sets the user of game system 1 who sent the logoff data to the logged-off state and updates the login data Dn. The control unit 104 then sets transmission data indicating that the player character PC operated by the logged-off user will be removed from the section and sends it to the user's game system 1 related to the section in which the user was participating. Furthermore, the control unit 104 deletes the user account of a logged-off user from the section where the user account is registered as an operator or viewer, and re-registers the user account as a reservation holder in the section where the user account has been temporarily removed from the reservation list, thereby updating the participant list data Dp.

[0269] In step S255, the control unit 104 determines whether the data received in step S252 is gameplay data. If it is gameplay data, the control unit 104 proceeds to step S256. If it is not gameplay data, the control unit 104 proceeds to step S258.

[0270] In step S256, the control unit 104 performs game space data management processing and proceeds to the next step. For example, based on the data regarding the player character PC and the data regarding objects and user areas in the game space indicated by the received game play data, the control unit 104 updates the state of the game space in each section and the state of the player character PC, and updates the game space data Do. When the state of the game space is updated, if there is a section in which a new user area has been set, the control unit 104 may register the user account that set the user area as the reserved user of that section and update the participant list data Dp.

[0271] Next, the control unit 104 performs the process of transmitting game space data (step S257) and proceeds to step S258. For example, the control unit 104 sets the data regarding the state of the game space and player character PC in each section, which has been updated based on the game play data of each user received in step S252, into communication data Dm as transmission data to be sent to the game system 1 of each user participating in game play using that section, and transmits it to the game system 1 of each user.

[0272] In step S258, the control unit 104 performs a process to calculate map display information and proceeds to the next step. For example, based on the game play data received in step S252, the control unit 104 sets the position of the in-game content in the game space of the target area, calculates the development value of the area, and updates the map data Ds.

[0273] Next, the control unit 104 determines whether the data received in step S252 is data requesting map data (step S259). If it is a request for map data, the control unit 104 proceeds to step S260. On the other hand, if it is not a request for map data, the control unit 104 proceeds to step S271 (see Figure 36).

[0274] In step S260, the control unit 104 performs the process of transmitting map display information and proceeds to step S271 (see Figure 36). For example, the control unit 104 refers to the map data Ds to obtain map display information that shows the development value for each section in the game space and the placement status of in-game content, sets the transmission data indicating the map display information in the communication data Dm, and sends it to the requesting user's game system 1.

[0275] Moving on to Figure 36, in step S271, the control unit 104 determines whether the data received in step S252 indicates a request to join a section or a request to move to another section. If the data is a request to join or a move, the control unit 104 proceeds to step S272. On the other hand, if the data is not a request to join or a move, the control unit 104 proceeds to step S278.

[0276] In step S272, the control unit 104 determines whether to permit the participation request or the move request made in step S271. For example, based on the capacity of each section set in the capacity data Dq, the control unit 104 determines whether to permit participation in a section based on a participation request or movement to another section based on a move request, in accordance with the method described in the overview of the game processing example above. If the control unit 104 permits the request, it proceeds to step S273. On the other hand, if the control unit 104 does not permit the request, it proceeds to step S276.

[0277] In step S273, the control unit 104 performs a process of transmitting permission data and proceeds to the next step. For example, the control unit 104 sets permission data indicating permission for an operator or a viewer to participate in the section requested for participation or movement in the communication data Dm and transmits it to the game system 1 of the requesting user. Further, the control unit 104 refers to the game space data Do and includes information on the game space in the section for which participation is permitted in the permission data set in the communication data Dm and transmits it to the game system 1. When the received participation request requests the allocation of sections in the initial settings, the control unit 104 sets permission data indicating permission for an operator to participate in one of the sections registered as a reservation by the user who made the participation request and information on the game space in the section in the communication data Dm and transmits it to the game system 1 of the requesting user.

[0278] Next, the control unit 104 determines whether there is a user account to be forcibly exited from the section due to the participation permission in the processes of steps S272 and S273 (step S274). For example, the control unit 104 makes an affirmative determination in step S274 if there is a user account of a viewer to be forcibly exited from the section according to the method described in the outline of the game processing example described above. Then, if there is a user account to be forcibly exited from the section, the control unit 104 proceeds to step S275. On the other hand, if there is no user account to be forcibly exited from the section, the control unit 104 proceeds to step S277.

[0279] In step S275, the control unit 104 performs a process of transmitting forced exit data and proceeds to step S277. For example, the control unit 104 sets forced exit data indicating forced exit from the section in the communication data Dm and transmits it to the game system 1 of the user to be forcibly exited.

[0280] Meanwhile, in step S276, the control unit 104 performs the process of sending denial data and proceeds to step S277. For example, the control unit 104 sets denial data in communication data Dm indicating that participation as an operator or viewer in the requested area is denied, and sends it to the requesting user's game system 1.

[0281] In step S277, the control unit 104 performs a process to update the participant list and proceeds to step S278. For example, based on the permission to join a section in step S273 or the forced exit from a section in step S275, the control unit 104 registers / deletes user accounts registered by role (reserved player, operator, viewer) in each section according to the method described in the overview of the game processing example above, and updates the participant list data Dp. In addition, if there is a user account that has been registered as a viewer for a predetermined time (e.g., 1 hour), the control unit 104 deletes the registration of that user account as an operator, and re-registers that user account as a reserved player in sections where that user account has been temporarily removed as a reserved player, and updates the participant list data Dp.

[0282] In step S278, the control unit 104 determines whether the data received in step S252 indicates that AC data should be added. If the data is one to which AC data should be added, the control unit 104 proceeds to step S279. On the other hand, if the data is not one to which AC data should be added, the control unit 104 returns to step S252 (see Figure 35) and repeats the process.

[0283] In step S279, the control unit 104 performs AC data management processing and returns to step S252 (see Figure 35) to repeat the process. For example, the control unit 104 updates the AC data Dr based on the content to be assigned to the received AC data (type of AC data, player character PC to be assigned, etc.). Then, the control unit 104 sets transmission data in communication data Dm indicating that the AC data will be assigned to the recipient (player character PC to be assigned), and transmits the AC data to the game system 1 of the user who will be the recipient (the user operating the player character PC to be assigned).

[0284] The processing performed by server 102 described above may be executed using multiple server machines, or using multiple server resources configured on at least one server machine. For example, the above processing may be performed by multiple section server machines (or multiple section server resources) that manage the game space for each section, and a management server machine (or management server resource) related to those multiple section server machines. In this case, a request to join a section is sent from game system 1 to the management server machine, and the management server machine checks the participation status with the relevant section server machines. If participation in the section is possible, key data that enables participation in that section is sent from the management server machine to game system 1 that made the participation request, and game system 1 accesses the section server machine that manages that section using the key data, thereby enabling gameplay using that section. In this case, the capacity management for each section may be performed by the management server machine (or management server resource), by a section server machine (or section server resource) for each section, or by both.

[0285] Furthermore, at least some of the processes performed by the game system 1 described above may be executed on the server 102 or other devices.

[0286] Thus, in this embodiment, when the number of operators who enter and participate in a game session (section) with player characters, and viewers who participate by watching the game session (section), increases, the server 102 manages which users can participate in the game session, and can determine which users can participate in the game session based on priority, etc.

[0287] In this embodiment, examples are given of data management targeting the player character PC, related processing targeting the player character PC's actions, and partition control targeting the player character PC. However, these examples are equivalent to performing the same actions targeting the user operating the player character PC (more specifically, the game account or the user ID, which is the identifier assigned to that user). Similarly, examples are given of data management targeting the user (account), related processing targeting the user, and capacity control targeting the user. However, these examples are equivalent to performing the same actions targeting the player character PC operated by that user. For example, in this embodiment, the target designated by the user as a spectator may be either the game account or the player character.

[0288] In other embodiments, the system may have a function to refuse spectating from other users. In this case, user accounts that refuse spectating may be managed by server 102. In this case, if a participation request is made for in-game content such as a player character PC or area setting object A associated with the above user account to be the target of spectating, server 102 may make a determination to deny the participation request, thereby realizing the above function.

[0289] Furthermore, in this embodiment, a game was used in which in-game content such as player character PCs and area setting object A are placed in one of the sections (game sessions) set up in the game space, and the game space within that section is edited. However, the game played in a game session is arbitrary. For example, the in-game content could be a competitive game played between multiple player characters in one of the multiple game sessions.

[0290] Furthermore, while this embodiment uses an example where objects (terrain objects, decorative objects) are edited by the actions of the player character PC, the objects may also be edited in response to user operations without involving the player character PC. For example, by performing a user instruction operation in which the user directly specifies a position (coordinates) in the game space, an object associated with that user may be edited at the specified position. In this case, the player character controlled by the user does not need to appear in the game space, and an editor of the object may be registered in response to the user giving an operation instruction to perform a predetermined action on the object that the user directly specified.

[0291] Furthermore, game system 1 may be any device, including portable game devices, any portable electronic device (PDA (Personal Digital Assistant), mobile phone, smartphone, personal computer, camera, tablet, etc.).

[0292] Furthermore, although the above description uses an example in which information processing (game processing) is performed by the game system 1, at least a part of the above processing steps may be performed by other devices. For example, if the game system 1 is configured to communicate with other devices (e.g., a server, another information processing device, another image display device, another game device, another mobile terminal), the above processing steps may be performed by the cooperation of these other devices. In this way, by performing at least a part of the above processing steps by other devices, processing similar to the above processing becomes possible. In addition, the above information processing can be performed by the cooperation of one processor or multiple processors included in an information processing system composed of at least one information processing device. Furthermore, in the above embodiment, the processor 81 of the game system 1 can perform information processing by executing a predetermined program, but some or all of the above processing may be performed by a dedicated circuit provided in the game system 1.

[0293] As described above, the invention can be realized in so-called cloud computing system configurations, distributed wide-area networks, and local network system configurations. For example, in a distributed local network system configuration, the above processing can be performed collaboratively between a stationary information processing device (stationary game device) and a portable information processing device (portable game device). It goes without saying that in these system configurations, there are no particular limitations on which device performs the above processing, and the invention can be realized regardless of how the processing is divided.

[0294] Furthermore, the processing order, set values, and conditions used in the information processing described above are merely examples, and it goes without saying that this embodiment can be realized with other orders, values, and conditions. Also, the example of the operation buttons used in the operation described above is merely an example, and may be realized by operations using other operation buttons. In addition, there may be multiple operation buttons with similar functions (for example, pressing any of operation buttons 33-36 (directional buttons) or operation button 53 (A button) may result in a high rating (like)).

[0295] Furthermore, the above program may be supplied not only to the game system 1 and server 102 via an external storage medium such as external memory, but also to the device via a wired or wireless communication line. The program may also be pre-recorded in a non-volatile storage device within the device. The information storage medium for storing the program may be a CD-ROM, DVD, or similar optical disc-type storage medium, a flexible disk, a hard disk, a magneto-optical disk, a magnetic tape, etc. Alternatively, the information storage medium for storing the program may be a volatile memory for storing the program. Such storage media can be described as recording media that can be read by a computer or the like. For example, by having a computer or the like read and execute the program on these recording media, the various functions described above can be provided.

[0296] Although the present invention has been described in detail above, the above description is merely illustrative in all respects and is not intended to limit its scope. Needless to say, various improvements and modifications can be made without departing from the scope of the present invention. Furthermore, those skilled in the art will understand from the description of specific embodiments of the present invention that an equivalent scope can be implemented based on the description of the present invention and common technical knowledge. In addition, it should be understood that the terms used herein are used in the sense commonly used in the art unless otherwise specified. Accordingly, unless otherwise defined, all technical terms used herein have the same meaning as commonly understood by those skilled in the art to which the present invention pertains. In case of any conflict, this specification (including definitions) shall prevail. [Industrial applicability]

[0297] As described above, this can be used as a game system, management program, server, and game processing method that makes it possible to hide content reported by users from those users. [Explanation of symbols]

[0298] 1… Information processing system 2…Main unit 3…Left controller 4…Right controller 11… Housing 12…Display 13…Touch panel 32, 52... Analog stick 42, 64… terminals 81… Processor 82…Network Communications Department 83…Controller Communication Unit 85…DRAM 101, 111... Communication Control Unit 102... Server 103... Communications Department 104... Control Unit 105...Storage section

Claims

1. A game system comprising at least one server that manages a game session, and a plurality of information processing terminals that can connect to said server, wherein an account corresponding to each of the information processing terminals is allowed to participate in the game session and the game is executed between those accounts, The aforementioned server, In response to a participation request received from the information processing terminal, the account corresponding to the information processing terminal is made to participate in the game session as at least one of the operators who operate the player object corresponding to the account in the game and at least one of the viewers who view the in-game content in the game. The following is transmitted to the information processing terminals corresponding to the accounts participating in the aforementioned game session, respectively, game information relating to the state of the game. The game information is updated based on the update information received from the information processing terminal. Of the multiple information processing terminals, the first information processing terminal is: Based on the user's first input, data including a first account corresponding to the first information processing terminal is sent to the server as a first participation request to participate as the operator in the game session. Based on a second input specifying in-game content included in one of the multiple game sessions, data including the first account is sent to the server as a second participation request to participate as a viewer in the game session containing the in-game content. If the first account is participating in the game session as the operator, Based on the aforementioned game information, a game space is generated that includes a first player object corresponding to the first account. Based on the position of the first player object, a first virtual camera control is performed to control the virtual camera in the game space. Based on the state of the game space, the update information is transmitted to the server. If the first account is participating in the game session as a viewer, Based on the aforementioned game information, a game space is generated that includes the in-game content specified by the second operation input. Based on the aforementioned game information, update the status of the in-game content. Based on the position of the in-game content specified by the second operation input, a second virtual camera control is performed to control the virtual camera in the game space. The aforementioned server further, A game system that, when the total number of accounts participating in the game session as operators and accounts participating as viewers satisfies a predetermined condition, removes at least one of the accounts participating in the game session as a viewer from the game session and stops transmitting the game information to the information processing terminal corresponding to the removed account.

2. The aforementioned server further, Upon receiving the first participation request from the second account corresponding to the second information processing terminal among the multiple information processing terminals, the second account is made to participate in the game session as the operator. The first information processing terminal is, The game system according to claim 1, wherein, based on the second operation input of a user specifying the second account or a second player object corresponding to the second account, the system sends a second participation request to the server to participate as a viewer in the game session including the second player object.

3. The server comprises means for managing a first game session and means for managing a second game session among a plurality of game sessions. The means for managing the second game session, upon receiving a second participation request from the first account participating in the first game session as the operator, to participate in the second game session as the viewer, allows the first account to participate in the second game session as the viewer. The game system according to claim 1, wherein the means for managing the first game session, upon receiving a first participation request from the first account participating in the second game session as a viewer, causes the first account to participate in the first game session as the operator.

4. The means for managing the first game session further includes: The number of accounts participating as operators and the number of accounts participating as viewers are stored in the first game session. The game system according to claim 3, wherein the number of accounts participating in the first game session as operators is not reduced in response to an account participating in the first game session as an operator participating in the second game session as a viewer.

5. The game system according to claim 4, wherein the means for managing the first game session further subtracts the number of accounts participating in the first game session as operators in accordance with the amount of time that has elapsed since the first account joined the second game session as a viewer.

6. The first information processing device further, when the first account participates in the second game session as a viewer from the first game session in which the first account is participating as an operator, places a first object with a different appearance from the first player object at a position based on the position of the first player object in the game space of the first game session, and transmits the update information, including first object position information relating to the position of the first object, to the server. The game system according to claim 3, wherein when a second account corresponding to a second information processing terminal among a plurality of information processing terminals participates in the first game session as the operator, the game space including the first object is generated at a position based on the object position information.

7. The first information processing device further, The game system according to claim 6, which generates a game space in which, when the first account joins the first game session as an operator from the second game session in which the first account is participating as a viewer, the first player object is placed in place of the first object at a position based on the first object position information.

8. The game system according to claim 6, wherein the second information processing terminal further restricts the state of the first object from being changed based on user input.

9. The game system according to claim 3, wherein if the means for managing the second game session allows the first account to participate in the second game session as a viewer and then, based on the second game session meeting the predetermined conditions, the means for managing the first game session allows the first account to participate in the first game session as an operator.

10. The game system according to claim 1, further comprising the server determining, when the predetermined conditions are met, which account to remove from the game session based on the length of time that has elapsed since participating as a viewer in the game session that met the predetermined conditions.

11. When the first account is participating in the first game session as the operator, the first information processing terminal places a second object in the game space based on the user's third operation input, and transmits the update information, including second object position information regarding the location of the second object, to the server. The aforementioned server further, Based on the receipt of the update information including the second object location information, the first account is stored as the deployer and associated with the first game session. The game system according to claim 1, wherein if the first game session satisfies the predetermined conditions when a second participation request to participate in the first game session as a viewer is received from the first information processing terminal corresponding to the first account stored as the operator, the system removes the account that is not stored as the operator but is participating in the first game session as a viewer from the first game session.

12. The first information processing terminal is, If the first account is participating as the operator in the first game session among the multiple game sessions, the second object is placed in the game space based on the user's third operation input, and the update information, including second object position information regarding the position of the second object, is sent to the server. If the first account is participating in the first game session as a viewer in response to the second operation input of the user specifying the second object, the first participation request to participate in the first game session as an operator is sent to the server in response to the fourth operation input of the user. The game system according to claim 1, wherein the server allows the first account to participate in the first game session as the operator in response to the first participation request transmitted in response to the fourth operation input.

13. When the first account is participating in the first game session as the operator, the first information processing terminal places a second object in the game space based on the user's third operation input, and transmits the update information, including second object position information regarding the location of the second object, to the server. The game system according to claim 1, wherein, among the plurality of information processing terminals, the second information processing terminal sends a second participation request to the server to participate as a viewer in the game session in which the first account is participating as an operator, based on a fifth operation input from the user to the second object, when the second account corresponding to the second information processing terminal participates in the first game session as an operator.

14. When the first account is participating in the first game session as the operator, the first information processing terminal places a second object in the game space based on the user's third operation input, and transmits the update information, including second object position information regarding the location of the second object, to the server. Of the multiple information processing terminals, the second information processing terminal is: When the second account corresponding to the second information processing terminal participates in the first game session as the operator, the user acquires an item corresponding to the second object based on the user's fifth operation input to the second object, The game system according to claim 1, wherein, based on a sixth operation input performed by the user to use the acquired item, the system sends a second participation request to the server to participate as a viewer in a game session in which the first account is participating as the operator.

15. The first information processing terminal further sends the second participation request to the server, specifying the second account corresponding to the second information processing terminal among the plurality of information processing terminals. The game system according to claim 1, wherein the server, in response to a second participation request, allows the first account to participate in the third game session as a viewer if the second account is participating as a viewer in the third game session among the multiple game sessions.

16. A game system comprising at least one server that manages a game session and a plurality of information processing terminals that can connect to said server, wherein an account corresponding to each of said information processing terminals participates in said game session and the game is executed between said accounts, the computer of said server, In response to a participation request received from the information processing terminal, the account corresponding to the information processing terminal is made to participate in the game session as at least one of the operators who operate the player object corresponding to the account in the game and at least one of the viewers who view the in-game content in the game. The information processing terminals corresponding to the accounts participating in the aforementioned game session are instructed to transmit game information regarding the state of the game. The game information is updated based on the update information received from the information processing terminal. A management program that, when the total number of accounts participating in the game session as operators and accounts participating as viewers satisfies a predetermined condition, removes at least one of the accounts participating in the game session as a viewer from the game session and stops transmitting the game information to the information processing terminal corresponding to the removed account.

17. A server equipped with a processor, which connects to multiple information processing terminals to manage game sessions, The aforementioned processor, The account corresponding to each of the aforementioned information processing terminals is allowed to participate in the game session, and the game is executed between those accounts. In response to a participation request received from the information processing terminal, the account corresponding to the information processing terminal is made to participate in the game session as at least one of the operators who operate the player object corresponding to the account in the game and at least one of the viewers who view the in-game content in the game. The following is transmitted to the information processing terminals corresponding to the accounts participating in the aforementioned game session, respectively, game information relating to the state of the game. The game information is updated based on the update information received from the information processing terminal. A server that, when the total number of accounts participating in the game session as operators and accounts participating as viewers satisfies a predetermined condition, removes at least one of the accounts participating in the game session as a viewer from the game session and stops transmitting the game information to the information processing terminal corresponding to the removed account.

18. A game system comprising at least one server that manages a game session and a plurality of information processing terminals that can connect to said server, wherein an account corresponding to each of said information processing terminals participates in said game session and the game is executed between said accounts, the server, In response to a participation request received from the information processing terminal, the account corresponding to the information processing terminal is made to participate in the game session as at least one of the operators who operate the player object corresponding to the account in the game and at least one of the viewers who view the in-game content in the game. The information processing terminals corresponding to the accounts participating in the aforementioned game session are instructed to transmit game information regarding the state of the game. The game information is updated based on the update information received from the information processing terminal. Of the multiple information processing terminals, the first information processing terminal, Based on the user's first input, the system causes the server to send data including a first account corresponding to the first information processing terminal as a first participation request to participate as the operator in the game session. Based on a second input specifying in-game content included in one of the multiple game sessions, the system causes the server to send data including the first account as a second participation request to participate as a viewer in the game session containing the in-game content. If the first account is participating in the game session as the operator, Based on the aforementioned game information, a game space is generated that includes a first player object corresponding to the first account. Based on the position of the first player object, a first virtual camera control is performed to control the virtual camera in the game space. Based on the state of the game space, the update information is sent to the server. If the first account is participating in the game session as a viewer, Based on the aforementioned game information, a game space including the in-game content specified by the second operation input is generated. Based on the aforementioned game information, update the state of the in-game content. Based on the position of the in-game content specified by the second operation input, a second virtual camera control is performed to control the virtual camera in the game space. The aforementioned server also has, A game processing method that, when the total number of accounts participating in the game session as operators and accounts participating as viewers satisfies a predetermined condition, removes at least one of the accounts participating in the game session as a viewer from the game session and stops transmitting the game information to the information processing terminal corresponding to the removed account.

Images