JP7699511B2 - Server system, program, and method of providing - Google Patents

Description

The present invention relates to a server system that provides online games for enjoying multiplayer.

A typical example of an online game is an MMO (Massively Multiplayer Online) game. One of the technologies for MMO games is known to allow computers of various categories, such as home game consoles, portable game consoles, personal computers, and smartphones, to be used as game clients.

For example, Patent Document 1 discloses a technology that acquires communication quality information for each game client and controls the progress of the game in a game mode that corresponds to the communication quality.

JP 2014-73266 A

Among multiplayer online games, there are games in which player characters are placed in a single shared game space, and the player characters become involved with each other, creating a situation that significantly affects the game progress and playing results (hereafter referred to as an "involvement situation"), and game play progresses locally through the player characters that are involved.

For example, this would include a battle royale-style action game in which player characters are spread across a large battlefield and engage in encounter combat. Other examples include action RPGs (role playing games) in which players work together to find and defeat a large beast NPC (non player character) that is somewhere, or action RPGs in which players work together to find and conquer a dungeon hidden somewhere in the game space.

One of the characteristics of online games is that the gameplay experience is strongly influenced by, for example, the communication speed of the communication line used by the game client. For example, using a high-speed communication line will result in a high-quality gameplay experience, as it will enable realistic and rich gameplay images, smooth character movements, high responsiveness, diverse operability, and high freedom of operation. If the communication speed is slow, these will not be possible, and the quality of the gameplay experience will be low.

Therefore, in the above types of games, the quality of the gameplay experience after involvement depends on which player characters are involved and the extent to which the communication speeds of the communication lines used by the game clients of those player characters differ.

If a player character of a game client using a high-speed communication line encounters a player of a game client using a low-speed communication line, the gameplay between the two players will have to be an experience that matches the speed of the player with the low-speed communication line. From the perspective of the player with the high-speed communication line, the gameplay will not be able to take full advantage of the high-speed communication speed. If a high-quality communication line is used, the player should be able to enjoy a better gameplay experience, but this is not the case.

In addition to communication speed, other performance indicators of a game client that are important for playing an online game comfortably include the communication processing capability and calculation processing capability of the game client itself. Therefore, if communication speed is the only indicator, it is not necessarily possible to provide users with a high-quality playing experience that fully utilizes the various capabilities of the game client.

The problem that this invention aims to solve is to provide a new technology for providing a high-quality playing experience in online games in which game clients with various capabilities play multiplayer games through participation situations in a shared game space.

A first invention for solving the above-mentioned problems is a server system for providing an online game in which each player uses a player terminal as a man-machine interface (hereinafter referred to as "MMIF") to operate a player character that can move around a shared game space and enjoy multiplayer, comprising:
The player terminals include terminals having different game play specifications,
a game play specification information acquiring means for acquiring information representing the game play specification of each of the player terminals (e.g., the control board 1150 in FIG. 1, the server processing unit 200s, the game management unit 210, the game play specification information acquiring unit 214 in FIG. 8, the game play specification information 605 in FIG. 12, step S12 in FIG. 17);
an involvement situation detection means (e.g., the control board 1150 in FIG. 1 , the server processing unit 200s in FIG. 8 , the game management unit 210, the involvement situation detection unit 216, the involvement situation registration data 730 in FIG. 9 , step S40 in FIG. 17 ) for detecting the occurrence of a given involvement situation in which N (N≧2) player characters are involved with each other in the shared game space;
a mutual compatibility determination means for determining whether or not the game play specifications of the player terminals (hereinafter, the player terminals that operate the participating characters are referred to as "participating terminals") that operate the N player characters that have become involved in the participation status (hereinafter, the player characters that have become involved in the participation status are referred to as "participating characters") satisfy a given mutual compatibility condition;
a MMIF information providing means for providing MMIF information for realizing the MMIF related to the multiplay in each of the player terminals (e.g., the control board 1150 in FIG. 1, the server processing unit 200s, the game management unit 210, the MMIF information providing unit 220 in FIG. 8, the game play image data 784 in FIG. 15, and step S34 in FIG. 17);
The MMIF information providing means is a server system having a change control means (e.g., change control unit 222 in FIG. 8, change control content data 540 (540a, 540b, ...) in FIG. 6, step S48 in FIG. 17, step S60, step S62 in FIG. 18) which provides MMIF information that has been subjected to a given change control for changing the MMIF information to the involved terminal when it is determined that the mutual compatibility condition is satisfied.

Specifically, as a second invention, the change control means may change the control content of the change control based on the game play specifications of the participating terminal that is determined to satisfy the mutual compatibility condition (for example, change control content data 540 prepared according to the application levels shown in FIG. 6), thereby configuring a server system according to the first invention.

More specifically, as a third invention, the change control means may configure a server system of the first or second invention, which executes a control as the change control to make the image quality of the game play image displayed on the player terminal different between the participating terminal determined to satisfy the mutually appropriate condition and the player terminal that does not satisfy the mutually appropriate condition (for example, applying the display quality setting according to the change control content data 540 in FIG. 6 in step S62 in FIG. 18).

"Image quality of gameplay images" refers to the display quality of how richly gradated and detailed the gameplay images are displayed on the player's device. It is determined by image size (the number of pixels that make up the image; the larger the image size, the higher the display resolution on the player's device), display refresh rate, number of colors, dynamic range of color space, etc.

More specifically, as a fourth invention, the change control means may configure a server system according to any of the first to third inventions, in which the change control means executes control to make the image quality and/or number of objects displayed on the player terminal different between the participating terminal determined to satisfy the mutually appropriate condition and the player terminal not satisfying the mutually appropriate condition (for example, applying an object model of a grade specified by the different expression quality in the change control content data 540 in FIG. 6 in step S48 in FIG. 17) as the change control.

Also, as a fifth invention, the change control means may configure a server system according to any of the first to fourth inventions, in which the change control means executes control to make the image quality of the moving image of the player character displayed on the player terminal different between the participating terminal determined to satisfy the mutually appropriate condition and the player terminal not satisfying the mutually appropriate condition (for example, motion data of a grade specified by the different expression quality in the change control content data 540 in FIG. 6, step S60 in FIG. 18) as the change control.

As a sixth invention, the change control means may configure a server system according to any one of the first to fifth inventions, in which the change control is to make the operation method of the player terminal that controls the player character different between the participating terminal that is determined to satisfy the mutual compatibility condition and the player terminal that does not satisfy the mutual compatibility condition (for example, step S60 in FIG. 18, permitted operation type data by terminal level 526 in FIG. 10).

As a seventh invention, the change control means may configure a server system according to any of the first to sixth inventions, in which the change control means executes control to make the viewpoint setting of the game image displayed on the player terminal different between the participating terminal determined to satisfy the mutually appropriate condition and the player terminal not satisfying the mutually appropriate condition (for example, change from a viewpoint overlooking the shared game space 8; applying viewpoint camera setting data of a grade specified by the different expression quality in the change control content data 540 in FIG. 6 as viewpoint control for the special game space 10 in step S60 in FIG. 18) as the change control.

An "involvement situation" is a situation in which a first player character and a second player character have a significant influence on each other's game progress and game results in the shared game space. For example, an encounter in a player-vs-player battle royale-style action game would fall into this category. It would also fall into this category when a common event involving multiple accompanying players occurs (for example, a cooperative play event, a conversation with a special NPC that is a highlight of the game progress, the acquisition of a special item, etc.). Playing in an involvement situation can be said to be one of the core aspects of gameplay in online games. Therefore, when playing in an involvement situation, it is desirable to provide a high-quality play experience that makes the most of the gameplay specifications of the player's device as much as possible.

"Gameplay specifications satisfy given mutual compatibility conditions" means that the game specifications are the same, that the game specifications are comparable, or that the difference in gameplay specifications does not result in a significant difference in the playing experience. Gameplay specifications can be, for example, any of the following: communication processing power, computing processing power, the type of OS (Operating System) installed, and communication speed with the server system.

According to any one of the first to seventh inventions, when player characters are in a given participation state in the shared game space and the game play specifications of the participating terminals are mutually appropriate, the server system can provide the participating terminals with MMIF information that has been subjected to change control.

In other words, for player terminals with the same or similar game play specifications to the extent that they can be considered mutually appropriate, change control appropriate to the game play specifications can be applied to execute game play according to the involvement status, providing a play experience appropriate to the game play specifications. For example, if a player character of a player terminal with a fast communication speed is involved, special change control suited to that fast communication speed can be applied, providing a high-quality play experience that makes full use of the high communication quality.

As an eighth invention, the server system of any of the first to seventh inventions may be configured to further include a change notification control means (e.g., the control board 1150 in FIG. 1, the change notification display 16 in FIG. 4, the change notification control unit 232 in FIG. 8, step S62 in FIG. 18) that notifies the participating terminal that the change control is being performed by the change control means.

According to the eighth aspect of the invention, the server system can inform the player that change control is being performed.

As a ninth aspect of the present invention, a permission/denial setting means (e.g., the control board 1150 in FIG. 1, the permission/denial setting unit 230 in FIG. 8, the permission/denial setting 609 in FIG. 12, step S16 in FIG. 17) is further provided for setting permission/denial of the change control based on the setting change operation of the player,
The change control means may constitute a server system of any of the first to eighth inventions, which executes the change control on the participating terminals that are determined to satisfy the mutual compatibility condition and whose permission/denial settings are set to permission (e.g., step S44 in Figure 17).

According to the ninth aspect of the invention, the server system allows the player to select whether or not to apply the change control to his or her own gameplay.

Also, as a tenth invention, the change control means may configure a server system according to any one of the first to ninth inventions, in which a special game space is set and the change control is to control the movement of the N participating characters within the special game space (e.g., step S48 in FIG. 17).

According to the tenth aspect of the present invention, the server system can execute change control by using a special game space. By providing a special game space, change control can be realized by limiting it to the participating characters without affecting objects outside the special game space.

Also, as an eleventh invention, the change control means may configure a server system of the tenth invention, in which the change control means sets the special game space within the shared game space and performs control to make the image quality within the special game space different from the image quality outside the special game space (for example, applying an object model of a grade specified by the different expression quality of the change control content data 540 in FIG. 6 in step S48 in FIG. 17).

"Image quality within the special game space" refers to how the appearance of the special game space is visually expressed in the gameplay images, or in other words, "expression quality."

According to the eleventh invention, by setting a special game space within the shared game space, players other than the parties involved in the involvement situation can visually see what is happening on the game play image. Specifically, the state of the special game space can be visually seen even in the game play image displayed on the player terminal of the player character who is not involved. Therefore, the shared game space and the special game space are not separated in the game world, and the players feel that they are the same game world.

By making the image quality within the special game space different from the image quality outside the special game space, the player can feel an improvement in the playing experience related to the involvement status.

Also, as a twelfth invention, the server system of any of the first to eleventh inventions may be configured such that the game play specification information acquisition means acquires information on the model of the player terminal as information representing the game play specification, and the mutual compatibility determination means determines whether the mutual compatibility condition is satisfied based on the information on the model of the player terminal acquired by the game play specification information acquisition means.

If the model of the player terminal is known, its performance can be roughly known. Therefore, according to the twelfth invention, the server system can appropriately determine the mutual compatibility conditions.

Also, as a thirteenth invention, which relates to model information, the server system of the twelfth invention may be configured to further include a model information notification control means (e.g., the control board 1150 in FIG. 1, the model information notification display 18 in FIG. 4, the model information notification control unit 234 in FIG. 8, step S62 in FIG. 18) that notifies the participating terminal of model information of the player terminal when the mutual compatibility condition is satisfied.

According to the thirteenth aspect of the invention, the server system can notify the player of information about the model of the participating terminal.

The fourteenth invention is a server system according to any one of the first to eleventh inventions, further comprising an evaluation means (e.g., control board 1150 in FIG. 1, evaluation unit 215 in FIG. 8, terminal level definition data 530 in FIG. 11, applicable terminal level 606 in FIG. 12, step S14 in FIG. 17) for evaluating the player terminal based on information representing the game play specifications acquired by the game play specification information acquisition means, and the mutual compatibility determination means determines whether the mutual compatibility condition is satisfied based on the evaluation result of the evaluation means for the participating terminal (e.g., step S42 in FIG. 17).

According to the fourteenth invention, by performing a comprehensive performance evaluation based on game play specifications, it becomes possible to determine whether mutual compatibility conditions are met even in cases where it is not always possible to collect the same type of game play specification information from all player terminals.

The game play images may be generated on the player terminal.
That is, as a fifteenth invention, the MMIF information may constitute a server system of any of the first to fourteenth inventions, including data required when generating game play images in the player terminal.

As a sixteenth aspect of the present invention, a program may be configured to generate game play images based on the MMIF information received from the server system on a player terminal that communicates with the server system of the fifteenth aspect of the present invention and enjoys game play in the online game.

The seventeenth invention relates to a server system that provides an online game in which each player uses a player terminal as a man-machine interface (hereinafter referred to as "MMIF") to operate a player character that can move in a shared game space to enjoy multiplayer play, and the player terminals in the game system are connected for communication with each other, and the player terminals include player terminals having different game play specifications, and the server system includes a game play specification information acquisition means that acquires information representing the game play specifications of each of the player terminals, an involvement situation detection means that detects the occurrence of a given involvement situation in which N (N≧2) player characters are involved with each other in the shared game space, and a game system that detects the occurrence of a given involvement situation in which N (N≧2) player characters are involved with each other in the shared game space, and a game system that detects the occurrence of a given involvement situation in which the N player characters are involved with each other in the shared game space. The player terminal includes a mutual compatibility determination means for determining whether the game play specifications of the player terminal (hereinafter, the player terminal operating the participating character is referred to as the "participating character") operating the participating character (hereinafter, the player character in the participating state is referred to as the "participating character") satisfy a given mutual compatibility condition, and an MMIF information providing means for providing each of the player terminals with MMIF information for realizing the MMIF related to the multiplay in the player terminal, and when it is determined that the mutual compatibility condition is satisfied, the MMIF information providing means provides the participating terminal with MMIF information that has been subjected to a given change control for changing the MMIF information, and generates a game play image based on the MMIF information provided by the server system.

According to the seventeenth aspect, a player terminal can be realized that provides the same effect as the first aspect.

An eighteenth aspect of the present invention is a method for providing an online game in which each player enjoys multiplay by controlling a player character movable in a shared game space using a player terminal as a man-machine interface (hereinafter referred to as "MMIF"), the method including the steps of:
a game play specification information acquisition step of acquiring information representing the game play specification of each of the player terminals; an involvement status detection step of detecting the occurrence of a given involvement status in which N (N≧2) player characters are involved with each other in the shared game space; a mutual compatibility determination step of determining whether or not the game play specifications of the player terminals (hereinafter, the player terminals operating the participating characters are referred to as "participating terminals") that operate the N player characters that have entered the involvement status (hereinafter, the player characters that have entered the involvement status are referred to as "participating characters") satisfy a given mutual compatibility condition; and an MMIF information providing step of providing each of the player terminals with MMIF information for realizing MMIF related to the multiplay in the player terminals, wherein the MMIF information providing step includes providing, to the participating terminals, MMIF information that has been subjected to a given change control that changes the MMIF information when it is determined that the mutual compatibility condition is satisfied.

According to the eighteenth invention, a method of providing can be realized that achieves the same effect as the first invention.

FIG. 1 is a diagram showing an example of the configuration of a game system. FIG. 1 is a diagram for explaining an online game provided by the game system. FIG. 1 is a diagram for explaining an example of an online game. FIG. 13 is a diagram for explaining change control of special data related to participation status play. 11A and 11B are diagrams for explaining how the state of a special game space is reflected in a shared game space. 11A and 11B are diagrams showing examples of differences in change control depending on the terminal level. 11A and 11B are diagrams showing examples of differences in control of the viewpoint camera depending on the terminal level. FIG. 2 is a functional block diagram showing an example of the functional configuration of the server system. FIG. 4 is a diagram showing examples of programs and data stored in a server storage unit. FIG. 4 is a diagram showing an example of the data structure of object initial setting data. FIG. 4 is a diagram showing an example of the data configuration of terminal level definition data. FIG. 4 is a diagram showing an example of the data configuration of participation status management data. FIG. 4 is a diagram showing an example of the data configuration of game progress management data. FIG. 4 is a diagram showing an example of the data configuration of participation status management data. FIG. 4 is a diagram showing an example of the data configuration of terminal-specific image management data. FIG. 2 is a functional block diagram showing an example of the functional configuration of a player terminal. A flowchart illustrating the flow of processing executed by the server system. 18 is a flowchart continuing from FIG. 17 . 13 is a diagram for explaining the system configuration of a game system according to a second embodiment and the parties responsible for generating game space images and game play images. FIG. FIG. 11 is a functional block diagram showing an example of the functional configuration of a server system according to a second embodiment. FIG. 11 is a diagram showing an example of programs and data stored in a server storage unit according to the second embodiment. FIG. 13 is a functional block diagram showing an example of the functional configuration of a player terminal according to a second embodiment. FIG. 11 is a diagram for explaining the operation of the game system according to the second embodiment, and is a diagram for explaining the flow of processing between the server system and the player terminals. 24 is a flowchart continuing from FIG. 23. 25 is a flowchart continuing from FIG. 24 .

The following describes examples of embodiments of the present invention, but it goes without saying that the forms to which the present invention can be applied are not limited to the following embodiments.

First Embodiment
FIG. 1 is a diagram showing an example of the configuration of a game system.
The game system 1000 comprises a server system 1100 and player terminals 1500 (1500a, 1500b, ...) for each player that can communicate with the server system 1100, and is a system for implementing an online game using the player terminals 1500 as a man-machine interface (MMIF, hereinafter referred to as "MMIF" where appropriate). Although only three player terminals 1500 are illustrated in Fig. 1, the number of player terminals 1500 is not important in actual system operation.

In the game system 1000, the server system 1100 and the player terminals 1500 can communicate data via the network 9, and the player terminals 1500 can also communicate data with each other via the network 9.

The network 9 refers to a communication path that allows data communication. In other words, the network 9 includes a LAN (Local Area Network) such as a dedicated line (dedicated cable) for direct connection or Ethernet (registered trademark), as well as a communication network such as a telephone communication network, a cable network, or the Internet, and the communication method can be either wired or wireless.

The server system 1100 is a computer system having, for example, a main unit, a keyboard, a touch panel, and storage, and a control board 1150 mounted on the main unit.
The control board 1150 is equipped with various microprocessors such as a CPU (Central Processing Unit) 1151, a GPU (Graphics Processing Unit), and a DSP (Digital Signal Processor), various IC memories 1152 such as a VRAM, a RAM, and a ROM, and a communication device 1153. Note that a part or the whole of the control board 1150 may be realized by an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), or a SoC (System on a Chip).

The server system 1100 realizes a user management function that manages information related to user registration, etc., and a game management function that allows users to play online games, by the control board 1150 performing calculations based on predetermined programs and data.

Although server system 1100 is depicted as if it were a single server device, it may be realized by a configuration of multiple devices working together. For example, server system 1100 may be configured with multiple blade servers that share each function and are connected to each other via an internal bus so that they can communicate data with each other. Furthermore, the location of the hardware that constitutes server system 1100 does not matter. It may be configured such that multiple independent servers installed in remote locations communicate data over network 9 to function as server system 1100 as a whole.

The player terminal 1500 (1500a, 1500b, ...) is a computer system that a user uses to play a game using the game system 1000, and is an electronic device that accesses the server system 1100 and other player terminals 1500 via the network 9. In other words, the player terminal 1500 performs the man-machine interface function in the game system 1000.

The player terminal 1500 includes an operation input device (e.g., a keyboard, a touch panel, a game controller, a mouse, etc.), an image display device (e.g., a video monitor, a touch panel, a head-mounted display, etc.), and a control board 1550.

The control board 1550 is equipped with a CPU 1551, various microprocessors such as a GPU and a DSP, various IC memories 1552 such as a VRAM, a RAM and a ROM, a communication module 1553 which connects to the network 9, and the like. These elements equipped on the control board 1550 are electrically connected via a bus circuit or the like, and are connected so that data can be read and written and signals can be sent and received. A part or all of the control board 1550 may be composed of an ASIC, an FPGA, or a SoC. The control board 1550 stores programs and various data for realizing the functions of a player terminal in the IC memory 1552.

In this embodiment, the player terminal 1500 is configured to download programs and various setting data from the server system 1100, but it may also be configured to read them from a storage medium such as a memory card obtained separately.

The player terminal 1500 may take any form as long as it is a computer system. For example, it may be a wearable computer such as a smartphone or a smartwatch, a portable game device, a home-use stationary game device, a tablet computer, a personal computer, an arcade game device, or the like. In the case where multiple electronic devices are communicatively connected to perform one function, such as a combination of a smartphone and a smartwatch communicatively connected to the smartphone, those multiple electronic devices can be considered as one player terminal 1500.

In actual operation, the player terminals 1500 (1500a, 1500b, ...) are a mixture of devices from various categories, such as smartphones, home game consoles, and personal computers, and there is a wide variety of models. Naturally, there is also a wide variety of hardware specifications (CPU specifications, installed memory capacity, graphics board specifications, communication module specifications, bus specifications, display specifications, communication line specifications, etc.) and software specifications (OS specifications, communication standards, etc.). The computational processing capabilities and communication processing capabilities of the player terminal 1500 as a single unit are determined by the hardware specifications and software specifications.

Furthermore, the actual conditions of the network 9 that communicatively connects each player terminal 1500 and the server system 1100, that is, the communication environment, also vary. For example, various elements related to communication quality, such as whether the connection is made via a base station of a wireless mobile phone network or a wired connection, the degree of delay (including transmission delay, propagation delay, etc.), bandwidth, the degree of packet loss, etc., vary depending on each player terminal 1500. As a result, the effective communication speed when each player terminal 1500 communicates with the server system 1100 varies.

These factors that affect game play at each player terminal 1500 (such as the communication processing capability of the player terminal 1500, the calculation processing capability of the player terminal 1500, and the communication speed between the player terminal 1500 and the server system) are collectively referred to as the "game play specifications."
In other words, "game play specs" refers to hardware specs (CPU specs, installed memory capacity, graphics board specs, communication module specs, bus specs, display specs, etc.), software specs (OS specs, communication standards, etc.), line speed and line type, etc.

The information considered to be the game play specifications of each player terminal 1500 is acquired and stored by the server system 1100 before the start of the game. Among the game play specifications, the hardware and software specifications of the player terminal 1500 can be acquired using a remote system information collection function according to the model and OS version. In addition, the communication speed can be measured by conducting a sending and receiving test of dummy data.

FIG. 2 is a diagram for explaining performance evaluation of the player terminal 1500 based on game play specifications.
The server system 1100 comprehensively evaluates each player terminal 1500 (1500a, 1500b, ...) based on the information of each game play specification, as to what level of play experience the environment can provide, and sets a "terminal level" for each player terminal 1500. If the terminal levels are the same, the player terminals 1500 are considered to be in an environment that can provide the same level of play experience, although the details of the game play specifications may differ. Having the same terminal level is referred to as being "mutually appropriate."

In the example of FIG. 2, the terminal levels are exemplified as four levels from "Lv1" to "Lv4", but the number of terminal levels is not important as long as there are multiple levels. Also, depending on the configuration of the computer system assumed as the assumed player terminal 1500 and the content of the game, it is possible to configure terminals of different levels to be considered as being of a mutually appropriate level if they are adjacent levels.

Figure 3 is a diagram for explaining an example of an online game provided by the game system 1000. The online game provided by the game system 1000 is an MMO game with a battle royale theme based on encounter battles.

A user uses a player terminal 1500 to access the server system 1100 or a specific website managed by the server system 1100, and goes through a specific user registration procedure to become eligible to become a player. Then, by going through a specific sign-in procedure using a unique user account (signature name) set during registration, the user's player terminal 1500 is incorporated into the game system 1000 and the system goes online. Also, by going through a specific sign-out procedure, the user withdraws from the system and the system goes offline. Then, in the system online state, the user can play an online game by performing a specific game login (hereinafter referred to as login). Note that it is also possible for login to occur automatically when the system goes online.

Each player terminal 1500 (1500a, 1500b, ...) is assigned a player character 4 (4a, 4b, ...). The player characters 4 are placed in a single shared game space 8 together with NPCs (non player characters) 6 and background objects that contribute to the structure of the game world. Specifically, the shared game space 8 is a virtual three-dimensional space, and data on various objects is stored in the shared game space 8. Position data and the like of various objects in the shared game space 8 are updated in accordance with the motion control of the objects.

Each player can customize his/her own player character 4 before starting the game. Specifically, the player can select one of several basic character types as a base and customize it by giving it appropriate equipment to suit the player's preferred fighting style. The player starts playing while viewing a gameplay image displayed on the player terminal 1500, which is an overhead view of the shared game space 8. The range that can be viewed from above may be the entire shared game space 8, or only a limited range based on the player character 4 may be viewed from above.

The game play images displayed on each player terminal 1500 are generated by the server system 1100. The example in Figure 3 shows the generation of a game play image 14 displayed on the player terminal 1500d by the server system 1100 as a representative example.

The server system 1100 places viewpoint cameras corresponding to each player terminal 1500 in the shared game space 8, and renders the state of the shared game space 8 as seen from the viewpoint cameras to create a game space image 12. Then, various additional displays (e.g., display of the status of the player character 4, display of playing results, etc.) are composited with the game space image 12 to generate a game play image 14. Then, data of the game play image 14 is transmitted and provided to the player terminal 1500 as "MMIF information for realizing MMIF related to multiplay in the player terminal." The player terminal 1500 receives the data and displays it.

While watching the gameplay image 14 displayed on the player's own player terminal 1500, the player operates and moves his/her own player character 4 while considering the terrain and timing appropriate for the fighting style he/she prefers. The player then brings his/her own player character 4 close to other player characters and brings them into combat, aiming to survive. Combat between player characters 4 that encounter each other in the shared game space 8 is one of the core play elements in the online game, and for the players involved, it is an important situation in which they are involved with each other and affect their playing results and game experience.

The progress of the game, such as the movement and actions of each object placed in the shared game space 8 and hit determination, is managed as an asynchronous game by the server system 1100.
When a plurality of nearby player characters 4 in the shared game space 8 satisfy a given involvement status determination condition, the server system 1100 considers the relevant player characters 4 to be in an "involved state." In other words, it detects that an involvement status has been entered, that is, the occurrence of an involvement status. In the example of FIG. 3, the player characters 4a and 4d are in an involved state.

The "involvement situation" is a situation in which a plurality of player characters 4 are involved with each other and have a significant impact on the game progress and playing results.
The "involvement status determination condition" can be set appropriately according to the game content, such as the first player character and the second player character satisfying a given encounter condition in the shared game space 8. In this embodiment, it may be "the other player's character has entered the attackable range of one of the player's characters" or "the other player's character has been locked on (set as the automatic tracking target for attack aiming)." Furthermore, it may be added that "the start of combat has been approved" by one or both players.

Hereinafter, the player character 4 that has entered the involvement situation will be referred to as the "involved character," and the player terminal 1500 associated with the involved character being used to control the involved character will be referred to as the "involved terminal." In addition, the game play from when the involvement situation is entered to when the involvement situation ends will be referred to as the "involved situation play."

The server system 1100 detects the occurrence of an involvement situation, and if the terminal levels of the involved terminals are the same, it determines that the involved terminals satisfy the mutual matching conditions, and controls changes to special data related to the involvement situation play.

4 is a diagram for explaining the change control of special data relating to the involvement status play. The player characters 4a and 4d are in the involvement state.
When the server system 1100 detects the occurrence of an involvement situation and determines that the participating terminals satisfy the mutual corresponding conditions, it creates a special game space 10 for the involvement situation play and controls the progress of the involvement situation play as a fully synchronous game in parallel with the game progress in the shared game space 8. The special game space 10 is a partial space set within the shared game space 8. The game play image of the involvement situation play displayed on the participating terminals is created based on this special game space 10.

Specifically, the special game space 10 is created as a space that copies a limited range in the shared game space 8, with a representative point related to the detected involvement situation (for example, the midpoint between the participating characters) as the reference position. Then, only the participating characters are placed as player characters in the special game space 10, and no player characters 4 other than the involvement situation characters are placed there. In other words, player characters 4 other than the N characters (N≧2) that have become participating characters are prevented from entering the special game space 10.

When a participation situation occurs, the participating terminal switches from displaying a game play image 14 created based on the shared game space 8 to displaying a game play image 14s using a game space image 12s created based on the special game space 10.

The game play image 14s includes a change notification indicator 16 and a model information notification indicator 18 as elements additionally displayed on the game space image 12s.
The change notification display 16 notifies the player that an involvement situation has occurred, an involvement situation play has started, and a special change control according to the terminal level is being executed. The change notification display 16 includes an indication of the terminal level set for the involved terminal, and also serves as an indication to notify the player of the terminal level of his/her own player terminal 1500. The model information notification display 18 indicates the model of the player terminal 1500 of the opponent player in the involvement situation play. In the example of FIG. 4, these indications are illustrated as text indications, but may be symbolic indications such as symbols and icons.

On the other hand, the state of the special game space 10 is reflected in the shared game space 8, for example, as shown in FIG. 5. Specifically, objects of a range display 20 indicating the range of the special game space 10 are arranged around the shared game space 8. In addition, an object model for the involvement situation play is reflected in the object model of the player character 4 (4a, 4d) that has become an involvement situation. This is called reflection control. The object model when the player character 4 in the special game space 10 is viewed from outside the special game space 10 is basically different from the object model when viewed from inside the special game space 10. When viewed from inside the special game space 10, reflection control is performed, so for example, a high-definition object model is obtained. The server system 1100 performs reflection control while controlling the progress of the involvement situation play. In addition, simple effects 22 such as flashes of light for attack effects in the involvement situation play and sparks and smoke for damage occurrence are also subject to reflection control.

In other words, although there are differences in details between the shared game space 8 and the special game space 10 due to differences in the grade of the object models placed therein, the essential situation is the same. Conceptually, this can be said to mean that the special game space 10 is set within the shared game space 8 so that the inside of the special game space 10 is visible from player characters that exist outside the special game space 10 (player characters that are not in the participation situation in the shared game space 8).

Therefore, the players of the outfield player characters 4 (4b, 4c, ...) other than the player character 4 (4a, 4d) in the involvement situation can see the player character 4 (4a, 4d) in the involvement situation in a battle state in a game play image based on the shared game space 8. Of course, only the player character 4 (4a, 4d) in the involvement situation can participate in the involvement situation play, so the players of the other player characters 4 (4b, 4c, ...) can only watch the battle, but the image effectively creates the "feel" of a battle royale unfolding within a single shared game space 8.

Then, when a situation ending condition that indicates that the involvement situation play has ended is met (for example, the match is decided, the time limit is reached, both players run out of ammunition, etc.), the involvement situation play ends. The data related to this in the special game space 10 is erased. Then, the player terminal 1500 (1500a, 1500d) that was the involved terminal is no longer treated as a involved terminal, and the reflection control of the player character 4 (4a, 4d) that was in the involved situation is returned to the control of the asynchronous game in the shared game space 8, which is the state before the involvement situation occurred.

When the terminal levels of the participating terminals are the same, the server system 1100 executes the following controls related to participation status play according to the terminal levels: (1) a first change control that changes the settings of the special game space 10; (2) a second change control that changes the settings of the image quality when generating the game space image 12s; (3) a third change control that changes the settings of the viewpoint camera; and (4) a fourth change control that changes the settings of the operation system. The type of change control to be performed at each terminal level is predetermined by the change control content data 540 (540a, 540b, 540c, 540d) as shown in FIG. 6, for example. Note that a configuration in which one or more of these are omitted is also possible.

The variation control will be specifically described with reference to FIG. 4 and FIG.
First, the first change control, "first change control for changing the setting of the special game space", will be described. A plurality of grades are prepared for data used for the placement and control of various objects such as the player character 4. In this embodiment, as an example, three grades are prepared, namely, LD (Low Definition), SD (Standard Definition), and HD (High Definition), but more detailed divisions may be made.

The lower the grade of an object model, the fewer the number of vertices and polygons it contains, and the smaller the data size. It is also possible to set a grade where the number of vertices and polygons is "0", meaning that essentially no objects are placed in the game space. The lower the grade, the fewer the number of colors in the skin and texture data applied to the object model, and the smaller the data size. Additionally, the lower the grade of the motion data applied to the object model, the simpler the motion and the smaller the data size.

The lower the grade, the poorer the expression of the details of the subject being represented by the object, so using a low-grade object reduces the image quality (expression quality) of the visual expression, and the quality of the play experience obtained from the visual expression decreases. However, the lower the grade, the lower the calculation load and communication load. Therefore, delays in game progress are less likely to occur and it is easier to maintain high operational responsiveness, improving the quality of the play experience in terms of comfort of play.

The grade of objects in the shared game space 8 can be set as appropriate. However, since it is preferable to uniformly control the shared game space 8 as the only game space that allows for player terminals 1500 with various game play specifications, in this embodiment it is set to LD grade. This is indicated by the drawers displaying "LD Model", "LD Motion", and "LD Effect" in Figure 4.

Now, when the involved terminal levels of the involved terminals are the same, the server system 1100 selects and applies the change control content data 540 that corresponds to that terminal level. In FIG. 6, the "application level" indicates the terminal level that corresponds to that change control content data 540.

Each change control content data 540 specifies which grade is to be used for which category of object so that the gameplay specifications corresponding to the applicable terminal level can be fully utilized (in other words, so that the highest quality and most comfortable playing experience possible can be provided for those gameplay specifications).

In the example of FIG. 4, the player terminal 1500a and player terminal 1500d, which are considered to be participating terminals, both have a terminal level of "Lv4". This level is the highest category among the game play specifications of the expected participating terminals. The grade of all types of objects placed in the special game space 10 is the highest HD grade. The types of effects displayed are also set to the greatest number. This is represented by the drawer displays of "HD Model", "HD Motion", "HD Effect", and "HD Background" in FIG. 4. In the example of FIG. 6, this is defined by the change control content data 540d of "Application Level = Lv4".

When the terminal level of the participating terminal is "Lv3", the game play specs are inferior to "Lv4", so the grade of objects in one or more categories is lowered below "Lv4" to reduce the processing load and communication load. For example, as shown in the change control content data 540c for "Application Level = Lv3" in Figure 6, the grade of the player character and effect objects may be HD grade, but the grade of NPC 6 and background objects may be SD grade. The number of types of effects displayed is also reduced compared to "Lv4".

When the terminal level of the participating terminal is "Lv2", the game play specifications are even inferior, so the grades of objects in even more categories are lowered to further reduce the processing load and communication load. For example, as shown in the change control content data 540b for "Application Level = Lv2" in Figure 6, the SD grade may be used for all types of objects. The number of types of effects displayed is reduced compared to "Lv3".

And when the terminal level is "Lv1" with even lower game play specs, the grade of all types of objects is set to LD grade, as shown in the change control content data 540a for "Application level = Lv1" in FIG. 6. The number of types of effects displayed is minimized.

Note that the example of setting the grade of an object according to the terminal level is not limited to the example shown in FIG. 6 and can be set as appropriate. For example, the grade of the object of the player character 4 may be configured to remain unchanged at any terminal level, while the grades of other background objects and effect objects may be changed.

Next, the second change control, “second change control for changing the image quality setting when generating a game space image”, will be described.
The server system 1100 changes the image quality of the game space image 12s according to the terminal level of the participating terminal. The image quality (display quality) of the game space image 12s is determined by, for example, the image size (the number of pixels constituting the image; the larger the image size, the higher the display resolution at the player terminal), the display refresh rate, the number of colors, the dynamic range of the color space, and the like. The setting parameter value that affects the image quality of the game space image 12s is changed so that the higher the terminal level, the larger the value. In this embodiment, as shown in FIG. 6, the image quality is set to one of three levels of image quality: LD image quality, SD image quality, and HD image quality. In the example of FIG. 4, since the terminal level of the participating terminal is "Lv4", the display quality of the game space image 12s is changed to HD image quality. Therefore, when the terminal level of the participating terminal is high, the high game play specs are utilized, and a game play image 14s with a richer, more realistic, and higher image quality is displayed than the game space image 12 of the asynchronous game using the shared game space 8.

FIG. 7 is a diagram for explaining the third change control, ie, the "third control for changing the setting of the viewpoint camera."
When the special game space 10 is generated, the viewpoint camera set in association with the participating terminal in the shared game space 8 is copied to the special game space 10. Then, the setting of the viewpoint camera is changed to the setting of the participation situation camera control prepared according to the terminal level.

The viewpoint camera settings can be changed as desired, but as the terminal level increases, one or more of the following characteristics are imparted: (a) the viewpoint camera's shooting range becomes wider (the number of objects that fall within the shooting range increases), (b) the viewpoint camera's maximum movement speed becomes faster, (c) the viewpoint camera's movement trajectory becomes more complex, and (d) the number of viewpoint cameras that the player can switch between increases (C1 and C2 in Figure 7).

In the example of FIG. 7, in the special game space 10ld when the terminal level is low, an LD grade model is arranged as an object model, a single viewpoint camera C1 is fixed at a predetermined position, and the shooting angle of view is set relatively narrow. In contrast, in the special game space 10hd when the terminal level is high, an HD grade model with detailed object models is arranged, the first viewpoint camera C1 is set to a wide angle of view with a movable type, and the second viewpoint camera C2 is set to a fixed standard angle of view. In FIG. 6, the differences between "narrow angle of view", "standard angle of view", "standard/wide angle switching", and "wide angle of view" in the "viewpoint camera setting" item correspond to the above examples (a) and (b). Also, "fixed position", "simple movement", and "complex movement" correspond to the above example (c).
In other words, the higher the device level, the more the viewpoint camera settings will be changed to allow for a richer gaming experience that takes advantage of the device's high gameplay specs.

Next, the fourth change control, "control for changing the settings of the operation system", will be described.
Various actions and behaviors are set for the player character 4, and among them, there are actions and behaviors that are only released when the player is in an involvement situation play. The types and number of actions and behaviors are increased as the terminal level increases, and the complexity of the actions and behaviors that are released increases as the terminal level increases. For example, in addition to the standard types of operations, operations for provoking the opponent may be added, or special techniques that are difficult to input but have a high striking effect may be released. In the example of FIG. 6, this is indicated by the entries "Standard", "Standard +2", "Standard +5", and "Standard +7" in the "Allowed Operation Types" section.

Next, the functional configuration will be described.
FIG. 8 is a functional block diagram showing an example of the functional configuration of the server system 1100.
The server system 1100 includes an operation input unit 100s, a server processing unit 200s, a sound output unit 390s, an image display unit 392s, a communication unit 394s, and a server storage unit 500s.

The operation input unit 100s is a means for inputting various operations for managing the server system 1100. Examples of this include a keyboard, a touch panel, and a mouse.

The server processing unit 200s is realized by electronic components such as processors that serve as arithmetic circuits, such as a CPU, GPU, ASIC, FPGA, etc., as well as IC memory, and controls the input and output of data between each functional unit, including the operation input unit 100s and the server storage unit 500s. It performs various types of arithmetic processing based on predetermined programs and data, operation input signals from the operation input unit 100s, data received from the player terminal 1500, etc., and performs integrated control of the operation of the server system 1100.

The server processing unit 200s includes a user management unit 202, a game management unit 210, a timing unit 280s, a sound generation unit 290s, an image generation unit 292s, and a communication control unit 294s. Of course, other functional units may also be included as appropriate.

The user management unit 202 handles processes related to user registration procedures and manages various information linked to user accounts. Specifically, the user management unit 202 assigns unique user accounts to registered users, manages personal information for each user account, manages save data related to online game play, etc.

The game management unit 210 performs various controls for playing a given online game on the player terminal 1500. Specifically, the game management unit 210 executes various processes related to game progress control of the online game. For example, it determines the initial placement of various objects such as the player character 4 and NPCs 6 in the shared game space 8, controls the movement of the player character 4 in response to the player's operation input, controls the movement of the NPCs 6, judges collisions of objects, judges hits of attacks, judges damage and reflects damage, changes the ability parameter values of the player character 4 and NPCs 6, generates events, calculates game results, judges the end of the game and the end of involvement status, etc.

The game management unit 210 has a shared game space setting unit 212, a game play specification information acquisition unit 214, an evaluation unit 215, an involvement status detection unit 216, a mutual compatibility determination unit 218, an MMIF information provision unit 220, an approval/disapproval setting unit 230, a change notification control unit 232, and a model information notification control unit 234.

The shared game space setting unit 212 sets up a shared game space 8 in a virtual three-dimensional space, arranges various objects that appear in the game, such as the player character 4, and controls the position, posture, shape, size, appearance, and disappearance of these objects according to the results of the game progress control.

The game play specification information acquisition unit 214 acquires information that represents the game play specifications of each player terminal.

The evaluation unit 215 classifies and evaluates the performance of the player terminal in accordance with a given gradual standard based on the information representing the game play specifications acquired by the game play specification information acquisition unit 214. Specifically, this corresponds to the determination and setting of the terminal level (see Figure 2).

The involvement situation detection unit 216 detects that a given involvement situation has occurred in which N (N≧2) player characters are involved with each other in the shared game space.

The mutual compatibility determination unit 218 determines whether or not the participating terminals (participating terminals) that operate the participating characters of N player characters (participating characters) that have entered an involved state satisfy given mutual compatibility conditions, based on the game play specifications of the participating terminals. Specifically, it compares the terminal levels of the participating terminals, and if they are the same, determines that the mutual compatibility conditions are satisfied.

The MMIF information provider 220 provides each player terminal with MMIF information for realizing MMIF related to multiplay on that player terminal. Specifically, the MMIF information corresponds to data for displaying game play image 14 (14s) on the player terminal 1500.

The MMIF information providing unit 220 includes a change control unit 222 .
When it is determined that the participating characters satisfy the mutual compatibility condition, the change control unit 222 provides the participating terminal with MMIF information that has been subjected to a given change control for changing the MMIF information.

As a change control to be applied to the MMIF information, the change control unit 222 sets a special game space in which player characters other than the N participating characters are prevented from entering the special game space, and executes control for the N participating characters to move within the special game space. Specifically, this corresponds to the above-mentioned first change control (control for changing the setting of the special game space 10 according to the terminal level when the terminal levels of the participating terminals are the same).

Furthermore, as a change control applied to the MMIF information, the change control unit 222 performs control to make the image quality in the special game space different from the image quality outside the special game space. Specifically, this corresponds to the second change control described above (control to change the image quality setting when generating the game space image 12s based on the special game space 10 according to the terminal level when the terminal levels of the participating terminals are the same).

When the participant terminals that are determined to satisfy the mutual matching condition by the execution of the change control by the change control unit 222 are compared with the player terminals that do not satisfy the mutual matching condition,
(a) Image quality of gameplay images displayed on the player terminal;
(b) the image quality of the objects and/or the number of objects displayed on the player terminal;
(c) Image quality of the moving image of the player character displayed on the player terminal;
(D) a method for operating a player terminal for controlling a player character;
(e) Setting the viewpoint of the game play image to be displayed on the player terminal;
At least one of the above is different.

Specifically, (a) is due to the display quality setting in the second change control. (b) is due to the object model grade setting in the first change control. (c) is due to the object motion data grade setting in the first change control. (d) is due to the permitted operation type setting in the fourth change control. (e) is due to the viewpoint camera setting in the third change control.

The permission setting unit 230 sets permission or denial of change control for each player based on the setting change operation of the player. The change control unit 222 executes change control for participating terminals that are determined to satisfy the mutual compatibility condition and for which the permission or denial setting is set to permission.

The change notification control unit 232 performs control to notify the participating terminals that change control is being performed by the change control unit 222. Specifically, this corresponds to displaying a change notification display 16 on the game play image 14s (see FIG. 4).

When the mutual matching conditions are met, the model information notification control unit 234 performs control to notify the participating terminal of information about the model of the player terminal that is the participating terminal. Specifically, this corresponds to displaying the model information notification display 18 in the game play image 14s (see Figure 4).

The timing unit 280s uses the system clock to measure various times, such as the current date and time and time limits.

The sound generation unit 290s is realized by executing an IC or software that generates or decodes audio data, and generates or decodes audio data such as operation sounds, sound effects, background music, and voice calls related to the system management of the server system 1100 and the provision of online games. Then, audio signals related to system management are output to the sound output unit 390s.

The sound output unit 390s is realized by a speaker or the like, and emits sound based on an audio signal.

The image generation unit 292s generates images of various management screens for system management of the server system 1100, and outputs the image data to the image display unit 392s. The image display unit 392s is realized by a device that displays images, such as a flat panel display, a head-mounted display, or a projector.

The image display unit 392s also cooperates with the MMIF information provider 220 to perform some of the functions related to generating MMIF information. For example, it renders game space images of the shared game space 8 and the special game space 10 that are the basis for the game play images to be displayed on each player terminal 1500 (see FIG. 4).

The communication control unit 294s executes data processing related to data communication and realizes data exchange with external devices via the communication unit 394s.

The communication unit 394s connects to the network 9 to realize communication. For example, this is realized by a wireless communication device, a modem, a TA (terminal adapter), a jack for a wired communication cable, a control circuit, etc. In the example of FIG. 1, this corresponds to the communication device 1153.

The server storage unit 500s stores programs and various data for implementing various functions for the server processing unit 200s to comprehensively control the server system 1100. It is also used as a working area for the server processing unit 200s, and temporarily stores the results of calculations executed by the server processing unit 200s according to various programs. This function is implemented, for example, by IC memory such as RAM or ROM, magnetic disks such as hard disks, optical disks such as CD-ROMs or DVDs, online storage, etc. In the example of Figure 1, this corresponds to storage media such as the IC memory 1152 and hard disks mounted on the main unit 1101. Online storage may also be included in the server storage unit 500s.

Figure 9 is a diagram showing examples of programs and data stored in the server storage unit 500s. In this embodiment, the server storage unit 500s stores a server program 501, a distribution client program 503, game initial setting data 510, user registration data 600, play data 700, and a current date and time 900. The server storage unit 500s also stores other programs and data (e.g. timers, counters, various flags, etc.) as appropriate.

The server program 501 is a program that is read and executed by the server processing unit 200s to cause the server processing unit 200s to realize the functions of the user management unit 202 and the game management unit 210.

The distribution client program 503 is an original program that is provided to and executed by the player terminal 1500.

The game initial setting data 510 stores various initial setting data related to the online game. For example, the game initial setting data 510 includes shared game space initial setting data 512, range display initial setting data 514 that defines the range display 20 (see FIG. 5), simple effect initial setting data 516 that defines the simple effect 22 (see FIG. 5), object initial setting data 520, terminal level definition data 530, and change control content data 540. Of course, data other than these may also be included as appropriate.

The shared game space initial setting data 512 stores various data that defines the state of the shared game space 8 at the start of the game. For example, this includes data defining the shape of the shared game space 8, the types and positions of background objects, the types and positions of NPCs 6, etc.

The object initial setting data 520 is prepared for each type of object that appears in the game, and stores various initial setting data that defines the object.
10, one object initial setting data 520 includes an object category 521, an object type 522, a grade-specific data set 523, an initial ability parameter value 524, and terminal level-specific permitted operation type data 526. Of course, other data may be included as appropriate depending on the game content, etc.

Object category 521 indicates which category the object belongs to: a base character for the player character, an NPC, background, effects, equipment, etc.

The grade-specific datasets 523 are prepared for each grade. In this embodiment, three grade-specific datasets 523 are prepared corresponding to the three grades of LD, SD, and HD. Each grade-specific dataset 523 includes a grade setting indicating the grade to which the dataset applies, object model data, skin data, and motion data. Of course, other setting data for arranging, controlling, and displaying objects in the game space can also be included as appropriate.

The details of the object model data differ depending on the grade. The order of detail increases from LD to SD to HD, and the number of vertices and polygons that make up the object increases. Also, the type of model, such as a polygon model or a particle model, may differ depending on the grade.

Motion data for each grade can also include a setting for whether or not to use simulation of physical phenomena. For example, in LD and SD grade motion data, the movement trajectory and movement timing of an object are pre-determined data, but in HD grade, the movement of an object may be calculated and determined on an ongoing basis by a physics calculation engine.

In addition to the grade-specific data sets 523 for LD, SD, and HD, a dedicated grade-specific data set 523 for the shared game space 8 may be prepared separately.

Initial ability parameter value 524 stores the initial value when the object is set to manifest a certain ability in the course of the game. For example, if the object is the player character 4, initial parameter values such as durability, attack power, defense power, movement power, and recovery power are stored. If the object is equipment such as a weapon or armor that can be equipped to the player character 4, initial parameter values that determine its action and effect, such as a change value for attack power or a change value for defense power, are stored.

The permitted operation type data by terminal level 526 is prepared for each terminal level, and defines the type of operation of the player character 4 permitted for the participating terminal when the participating terminal of that terminal level satisfies the mutual compatibility conditions. Specifically, one permitted operation type data by terminal level 526 includes an applicable terminal level that corresponds to the application requirements of the data, and a list of usable operation types. Of course, other information than these can also be included as appropriate.

The usable operation type list in the permitted operation type data by terminal level 526 is set so that the higher the applicable terminal level, the more operation types (operation commands) are permitted to be used, and so that the higher the applicable terminal level, the more operation types that perform special functions are added. Of course, either of these is acceptable.

In addition, in the case of a game in which the role played by the participating terminal in the game changes depending on the terminal level, the usable operation type list should be set in accordance with the role played by the object of the initial setting data in the game. For example, in a game in which a participating terminal with a low terminal level is assigned a role such as a defender, rear guard, or supporter, the contents of the usable operation type list when the applicable terminal level is low will mainly consist of operation types that are relatively simple to operate and estimated to be entered less frequently. In contrast, if a participating terminal with a high terminal level is assigned a role such as an offense, forward, or player, the contents of the usable operation type list when the applicable terminal level is high will mainly consist of operation types that are relatively complex and entered more frequently. In games in which roles in the game change in this way, it is preferable to also display the role allocation name in the change notification display 16 (see FIG. 4).

Returning to FIG. 9, the terminal level definition data 530 indicates the criteria for classifying and evaluating the performance of the player terminal in accordance with given hierarchical standards based on information representing the game play specifications. For example, as shown in FIG. 11, one terminal level definition data 530 stores a unique terminal level 531 and its judgment requirement definition data 533 in association with each other.

The judgment requirement definition data 533 is data that defines the conditions that must be met to judge that the terminal is at the terminal level 531, and is described by combining one or more sub-conditions with AND or OR. As sub-conditions, for example, model conditions, CPU type conditions, installed memory amount conditions, OS type conditions, rendering engine type conditions, display unit specifications conditions, communication function specifications conditions, etc., related to the specifications of the player terminal 1500 can be used. In other words, conditions regarding specifications that affect the computational processing capacity and communication processing capacity can be used. Also, for example, as sub-conditions related to the communication environment, line type conditions, communication speed conditions, etc. can be used. Line type conditions include whether the line is wired or wireless, the communication standard used, etc.

Returning to FIG. 9, the change control content data 540 is prepared for each terminal level, and stores various data that defines the change control content. In this embodiment, the terminal levels are set to four levels, from "Lv1" to "Lv4", so four change control content data 540 (540a, 540b, 540c, 540d) are prepared (see FIG. 6).

The user registration data 600 is created for each registered user who will become a player, and stores various data associated with that user.
12, one piece of user registration data 600 includes a unique user account 601, terminal access information 603 (e.g., IP address, etc.) for accessing the player terminal 1500 via the network 9, game play specification information 605, applicable terminal level 606, player character setting data 608, and permission setting 609. Of course, data other than these, such as save data for an online game, can also be included as appropriate.

The information contained in the game play specification information 605 corresponds to the sub-condition items that describe the judgment requirement definition data 533 (see FIG. 11) of the terminal level definition data 530.

The player character setting data 608 stores the setting data of the player character 4 customized by the user. The player character 4 is customized during the user registration procedure.

The permission setting 609 stores the user's permission/denial selection result for executing change control according to the game play specifications of the player terminal 1500 in relation to participation status play. The initial value of this setting is a value indicating "permission." If "denial" is selected in the permission/denial selection acceptance from the user before the start of the game, the setting is changed to "denial."

Returning to FIG. 9, the play data 700 stores various data related to the realization of the online game, and is updated sequentially as the game progresses. The play data 700 includes game progress management data 710, participation status registration data 730, participation status management data 750, and terminal-specific image management data 780. Of course, data other than these can also be stored as appropriate.

The game progress management data 710 stores various data describing the game progress status of the online game. Specifically, as shown in FIG. 13, the game progress management data 710 includes player character management data 711, shared game space data 720, viewpoint camera control data 722, and reflected display control data 724. Of course, data other than these can also be stored as appropriate.

The player character management data 711 is prepared for each player character 4 (see FIG. 3), and stores various data relating to the player character.
Each piece of player character management data 711 includes, as information linking a player with the player character, a user account indicating the player who uses the character, a unique terminal ID indicating the player terminal 1500, a unique character ID, and the base character type of the character. Furthermore, the player character management data 711 includes, as information indicating the latest state of the player character 4, position information 712 of the representative point of the character in the shared game space 8, motion control data 713, equipment control data 714, ability parameter values 715, and an allowed operation type list 716. Of course, data other than these can also be stored as appropriate.

Although not shown, similar management data for NPC 6 is also included in the game progress management data 710.

The shared game space data 720 is a group of vertex data and polygon data in the latest state of the object models of various objects placed in the shared game space 8.

The viewpoint camera control data 722 is prepared for each player terminal 1500, and stores various data indicating the state of the viewpoint camera of the gameplay image 14 displayed on that player terminal 1500. Specifically, one viewpoint camera control data 722 stores information such as position coordinates, angle of view, and attitude in the shared game space 8 in association with a terminal ID (or user account).

The reflected display control data 724 is prepared for each participation status, and stores various data for simply reflecting and displaying the status of the special game space 10 related to that participation status in the shared game space 8. One piece of reflected display control data 724 includes range display control data for the range display 20 and simple effect display control data for the simple effect 22 (see FIG. 5). In addition, data on objects related to the simple reflected display may also be included.

Returning to FIG. 9, when it is detected that a player character 4 in the shared game space 8 has entered an involvement state, an involvement status registration data 730 is created for each detection. One involvement status registration data 730 includes a unique involvement status ID and a participation terminal ID list (or a participating character ID). Of course, data other than these can also be stored as appropriate. For example, if a rule stipulates a time limit for the involvement status, the involvement start date and time, etc. may be stored.

The involvement status management data 750 is created each time an involvement status is detected, and stores various data describing the latest progress of play in the special game space 10 for that involvement status. Specifically, as shown in FIG. 14, one involvement status management data 750 includes a target involvement status ID 751 indicating the corresponding involvement status, space range setting data 752, participating character management data 754, special game space data 760, and terminal-specific viewpoint camera control data 762. Of course, data other than these can also be stored as appropriate. For example, a timer value for timing the time limit required to determine the end condition of the involvement status can also be included.

The spatial range setting data 752 indicates which part of the shared game space 8 the special game space 10 related to the participation status corresponds to. For example, it stores the position coordinates of the boundary of the special game space in the shared game space 8, and if the special game space 10 is set to a specified size, the position coordinate values of the representative point in the shared game space 8.

The contents of the player character management data 711 for the character at the time the involvement situation occurs are copied to the involved character management data 754 (see FIG. 13). However, the permitted operation type list 756 refers to the involved character's object initial setting data 520 (see FIG. 10) and is changed according to the settings of the terminal level-specific permitted operation type data 526 that matches the terminal level of the involved terminal.

When an NPC 6 is placed in the special game space 10 of the relevant participation situation, data similar to the participating character management data 754 is prepared for each NPC.

The special game space data 760 is a group of vertex data and polygon data in the latest state of the object models of various objects placed in the special game space 10 that is created based on the participation status.

The terminal-specific viewpoint camera control data 762 is prepared for each participating terminal, and stores information related to the control of the viewpoint camera for rendering the game space image 12s that is the basis for the game play image 14s displayed on that terminal (see Figures 4 and 7). For example, it includes the terminal ID, the position coordinates of each viewpoint camera in the special game space 10, the angle of view, the attitude, movement control data, etc.

Returning to FIG. 9, the terminal-specific image management data 780 is prepared for each player terminal 1500, and stores various information for displaying the gameplay image 14 (14s) on that terminal (see FIGS. 3 and 4). As shown in FIG. 15, for example, one terminal-specific image management data 780 includes an applicable terminal ID 781 indicating the destination to which the management data is applied, game space image data 782 of the game space image 12 (12s), notification display data 783 of the change notification display 16 and the model information notification display 18, and gameplay image data 784 of the gameplay image 14 (14s). Of course, data other than these can also be stored as appropriate.

FIG. 16 is a functional block diagram showing an example of the functional configuration of a player terminal 1500. The player terminal 1500 includes an operation input unit 100, a device processing unit 200, a sound output unit 390, an image display unit 392, a communication unit 394, and a device storage unit 500.

The operation input unit 100 outputs operation input signals corresponding to various operation inputs made by the player to the device processing unit 200. For example, this can be realized by a push switch, joystick, touchpad, trackball, acceleration sensor, gyro, etc.

The terminal processing unit 200 is realized by electronic components such as a microprocessor such as a CPU or GPU, and an IC memory, and controls the input and output of data between each functional unit including the operation input unit 100 and the terminal storage unit 500. It controls the operation of the player terminal 1500 by executing various types of calculation processing based on predetermined programs and data, operation input signals from the operation input unit 100, and various types of data received from the server system 1100.

In this embodiment, the device processing unit 200 has a client control unit 260, a timing unit 280, a sound generation unit 290, an image generation unit 292, and a communication control unit 294.

The client control unit 260 performs various controls to make the player terminal 1500 function as an MMIF, as a control for the game client in a client-server type game system. Specifically, the client control unit 260 has an operation input information providing unit 261 and a display control unit 262.

The operation input information providing unit 261 controls the transmission of operation input information to the server system 1100 in response to input from the operation input unit 100.

The display control unit 262 performs control to display the game play image 14 based on the data received from the server system 1100, but in this embodiment, since the game play image 14 (14s) is generated by the server system 1100, the display control unit 262 does not perform control related to the rendering of the game space image 12 (12s). It performs control to display the game play image 14 (14s) provided as MMIF information from the server system 1100. If the data provided is compressed data, it performs processing such as decompressing the data.

The timing unit 280 uses the system clock to measure the current date and time, time limits, etc.

The sound generation unit 290 is realized by, for example, a digital signal processor (DSP), a processor such as a voice synthesis IC, an audio codec capable of playing audio files, etc., and generates sound signals for music, sound effects, and various operation sounds, and outputs them to the sound output unit 390.

The sound output unit 390 is realized by a device that outputs (emits) sound based on the sound signal input from the sound generation unit 290, such as a speaker.

The image generation unit 292 generates and outputs an image signal that causes the image display unit 392 to display an image based on the control of the client control unit 260. In the example of FIG. 1, this corresponds to a GPU (Graphics Processing Unit), a graphics controller, a graphics board, etc., mounted on the control board 1550.

The image display unit 392 is realized by a device that displays images, such as a flat panel display, a head-mounted display, or a projector.

The communication control unit 294 executes data processing related to data communication and realizes data exchange with external devices via the communication unit 394.

The communication unit 394 connects to the network 9 to realize communication. For example, it is realized by a wireless communication device, a modem, a TA (terminal adapter), a jack for a wired communication cable, a control circuit, etc. In the example of Figure 1, this corresponds to the communication module 1553.

The device storage unit 500 stores programs for causing the device processing unit 200 to realize given functions, various data, etc. It is also used as a working area for the device processing unit 200, and temporarily stores the results of calculations executed by the device processing unit 200 according to various programs, input data entered from the operation input unit 100, etc. These functions are realized by, for example, IC memory such as RAM or ROM, magnetic disks such as hard disks, optical disks such as CD-ROM or DVD, etc. In the example of Figure 1, this corresponds to the IC memory 1552 mounted on the control board 1550.

Specifically, the device storage unit 500 stores a client program 502 (application program) for causing the device processing unit 200 to function as the client control unit 260, received MMIF information 590, and a current date and time 900. Of course, other data can also be stored as appropriate. For example, data for displaying game play images 14 (14s) received from the server system 1100 is also temporarily stored. Game initial setting data 510 (see FIG. 9) and the like may also be downloaded from the server system 1100 and stored.

Next, the operation of the game system 1000 will be described.
17 and 18 are flow charts for explaining the flow of processing executed by the server system 1100 for executing an online game.

As shown in FIG. 17, the server system 1100 processes participation acceptance for the online game (step S10). The server system 1100 acquires information related to the game play specifications (e.g., model, CPU type, line type, etc.) from the player terminals 1500 that have accepted the participation, and stores this information in the game play specification information 605 (see FIG. 12) of the user registration data 600 (step S12).

Next, the server system 1100 judges the terminal level of each player terminal 1500 (step S14). Specifically, the game play specification information 605 is compared with the judgment requirement definition data 533 of the terminal level definition data 530 (see FIG. 11), and the terminal level 531 of the definition data that satisfies the judgment requirement is set as the applicable terminal level 606 (see FIG. 12).

Then, the server system 1100 accepts the permission/denial setting for the change control for each player terminal 1500 (step S16). That is, a selection input screen for allowing or denying the change control is displayed on each player terminal 1500, and the input result is acquired. If the input result was "deny", the permission/denial setting 609 of the user of the player terminal 1500 is changed to "deny". In addition, in conjunction with this, a display may be displayed on each player terminal 1500 informing the user of the respective terminal level.

Next, the server system 1100 initializes the shared game space 8 (step S30).
Each object, such as the player character 4 of each player terminal 1500, the NPC 6, the background, etc., is initially placed in the shared game space 8. The objects of each category are set to a predetermined grade for the shared game space 8 (for example, LD grade or dedicated grade).

Next, the server system 1100 starts controlling the game progress as an asynchronous MMO game using the shared game space 8 (step S32), and starts generating and transmitting data for game play images 14 to be displayed on each player terminal 1500 (step S34).

That is, after steps S32 and S34, the server system 1100 controls the movement of the player character 4 associated with the player terminal 1500 based on the operation input information received from that terminal, and automatically controls the NPC 6. It also controls the viewpoint camera for each player terminal 1500 accordingly. Then, for each player terminal 1500, it renders an image of the shared game space 8 seen from the viewpoint camera (game space image 12), synthesizes various information displays with this to generate a game play image 14, and transmits data for displaying the game play image 14 to that player terminal 1500. That is, the server system 1100 provides MMIF information to the player terminal 1500.

The image size, number of colors, etc. of the gameplay image 14 for the shared game space 8 are set in advance for an asynchronous MMO game, and are common between the player terminals 1500. Note that the image size, number of colors, etc. of the gameplay image 14 for the shared game space 8 may be set in advance in multiple settings according to gameplay specifications, and may be selectively used as appropriate according to the gameplay specifications of the player terminal 1500.

When game progress control is started, the server system 1100 constantly monitors the occurrence of an involvement situation. When the occurrence of an involvement situation is detected (YES in step S40), the server system 1100 refers to the applicable terminal level 606 of the involved terminal and determines whether the terminal levels of the involved terminals are the same, i.e., whether the mutual compatibility condition is satisfied (step S42). Note that it is also possible to configure the determination of the mutual compatibility condition to be made based only on the model of the game play specification information 605.

If the terminal levels are the same, the server system 1100 determines that the mutual compatibility condition is met (YES in step S42) and refers to the permission settings 609 of the users of those involved terminals. If all of the permission settings 609 referred to are "allowed" (YES in step S44), the server system 1100 creates the involvement status registration data 730 (see FIG. 9) and registers the involvement status and the involved terminals (step S42).

Next, the server system 1100 sets a special game space 10 according to the terminal level (terminal level of the participating terminal) indicated by the applicable terminal level 606 (step S48).

Specifically, the server system 1100 creates new involvement status management data 750 (see FIG. 14). The player character management data 711 (see FIG. 13) of the multiple player characters 4 that have become involved is copied to the involved character management data 754. The permitted operation type list 756 is set to the terminal level-specific permitted operation type data 526 that matches the terminal level of the involved terminal of the player character 4.

The server system 1100 also copies the state of the objects within the range of the special game space 10 in the shared game space 8 to the special game space data 760. At this time, the object models of each object placed in the special game space 10 use object model data of the grade indicated by the expression quality setting of the change control content data 540 (see FIG. 6) that matches the terminal level of the participating terminal (see grade-specific data set 523 in FIG. 10).

The game play image 14s of the participation status play uses the game space image 12s based on the special game space 10, so by changing the grade of the object model in step S48, it can be said that from step S48 onwards, a participation terminal is provided that has undergone change control on the MMIF information that began to be provided in step S34.

The server system 1100 also initially sets the per-terminal viewpoint camera control data 762 to inherit the orientation and position in the shared game space 8 of the viewpoint camera of each participating terminal at the time the participation situation occurs. This initial setting reduces the unnatural feeling caused by a sudden change in viewpoint position when the gameplay image 14 on the participating terminal switches from an image related to the shared game space 8 to a gameplay image 14 related to the special game space 10.

Once the special game space 10 has been set, the server system 1100 places the objects of the range display 20 of the newly created special game space 10 in the shared game space 8 (step S50).

Moving on to FIG. 18, the server system 1100 switches the game progress of the new participating terminal/participating character to a fully synchronous game using the special game space 10 and starts the participation status play (step S60).

From step S60 onwards, until the involvement situation play ends, the permitted operation type list 756 of the involved character management data 754 is applied to the control of the operation system. In addition, the motion data of the relevant grade (see grade-specific data set 523 in Figure 10) is applied to the movements of the involved characters in accordance with the change control content data 540 (see Figure 6) that is compatible with the terminal level of the involved terminal. The viewpoint camera settings of the change control content data 540 are applied to the control of the viewpoint camera.

Then, the server system 1100 renders the game space image 12s based on the special game space 10 for each new participating terminal to generate a game play image 14s, and starts control to transmit the data of the game play image 14s (step S62).

The display quality of the game space image 12s is determined by the settings of the change control content data 540 (see FIG. 6) that are compatible with the terminal level of the participating terminal. In other words, the game space image 12s is created with a number of pixels that achieves either LD image quality, SD image quality, or HD image quality for each participating terminal.

The game play image 14s of the participation status play uses the game space image 12s based on the special game space 10, so steps S60 and S62 onwards can be said to provide to the participation terminal MMIF information that has been modified and controlled from the MMIF information that began to be provided from step S34 onwards.

Furthermore, from step S60 onwards, the operation input information from the participating terminals is used to control the game progress in the special game space 10, and is no longer used directly to control the game progress in the shared game space 8. Therefore, instead, the server system 1100 starts reflection control to reflect the progress control results for the new special game space 10 in the shared game space 8 (step S64).

Specifically, the server system 1100 refers to the participating character management data 754 for each participating character at a predetermined cycle, and modifies the participating character's object position information 712, motion control data 713, equipment control data 714, and ability parameter value 715 in the shared game space 8 to reflect the data (see FIG. 13). In other words, the player character 4 in the special game space 10 of the participating terminal is shadowed in the shared game space 8. Also, in a situation where effects such as flashes of light or smoke are displayed in the special game space 10, some or all of these are displayed in the shared game space 8 as simple effects 22 (see FIG. 5).

On the other hand, if the terminal levels of the participating terminals are not the same, i.e., if the mutual compatibility condition is not met (NO in step S44), and if any of the permission settings 609 of the participating terminals are set to "reject" (NO in step S46), the server system 1100 does not create the participation status management data 750. In other words, the participation status play is processed as an event in the shared game space 8. In other words, a play experience in the special game space 10 that makes use of the game play specifications of the participating terminals is not provided, and no special change control is performed.

The server system 1100 constantly monitors the end of each involvement situation that has already occurred. The conditions for ending an involvement situation can be set appropriately depending on the game content. In this embodiment, the game in which an involvement situation occurs is a battle royale-style fighting action game. Therefore, the involvement situation ends when the outcome of the battle between the player characters 4 in which the involvement situation occurred is decided, for example, when only one character remains. Of course, the involvement situation may also end when the time limit is reached. Also, in the case of a turn-based battle, the involvement situation may end when the number of turns reaches a specified value.

Then, when the end of the involvement status is detected (YES in step S80), the server system 1100 returns the game progress of the participating terminal of the involvement status for which the end was detected from a fully synchronous game using the special game space 10 to an asynchronous game using the shared game space 8 (step S82). In other words, after the involvement status is detected, if the involvement status satisfies the end condition, the gameplay control that was being performed on the participating terminal is returned to the gameplay control before the detection.

Next, the server system 1100 ends the control of reflecting the participation status that has been detected and terminated in the shared game space 8 (step S84).

Furthermore, the server system 1100 reverts the generation of game play images 14 and the transmission of image data to the participating terminal of the participation situation for which the end has been detected from being based on the special game space 10 back to being based on the shared game space 8 (step S86).

Then, the server system 1100 erases the involvement status registration data 730 and the involvement status management data 750 for the involvement status for which termination was detected (step S88; see Figure 9).

The server system 1100 repeats steps S40 to S88 until the end condition of the asynchronous game using the shared game space 8 is met (NO in step S100). If the end condition is met (YES in step S100), a predetermined game end process (e.g., declaring the end of the game, announcing the rankings, awarding rewards, updating the rankings, saving the save data, etc.) is performed (step S102), and the series of processes ends.

As described above, according to this embodiment, a high-quality playing experience can be provided in an online game in which game clients with various capabilities play multiplayer games in a shared game space through participation status.
That is, the server system 1100 provides each of the player terminals 1500 with MMIF information for realizing MMIF related to multiplay in the player terminals 1500. However, the server system 1100 monitors whether a participation situation involving a player character 4 occurs in the shared game space 8 and whether a case occurs in which the game play specifications of the player terminal 1500 (participant terminal) of the player character 4 (participant character) satisfy a given mutual compatibility condition. If such a case occurs, the server system 1100 provides the participant terminal with MMIF information that has been subjected to a given change control for changing the MMIF information. The change control is a control for realizing a play experience that makes use of the game play specifications, which is possible if the participating terminals have mutually compatible game play specifications when playing with each other.

Second Embodiment
Next, a second embodiment will be described. In the description of the second embodiment, differences from the first embodiment will be mainly described, and the same components as those in the first embodiment will be given the same reference numerals and overlapping descriptions will be omitted.

Figure 19 is a diagram explaining the system configuration in the second embodiment and the parties responsible for generating the game space image 12 and game play image 14.

The game system 1000B of this embodiment basically has the same configuration as the first embodiment. The server system 1100B manages the data of the shared game space 8 in the same manner as the first embodiment, and controls the progress of the asynchronous game using the shared game space 8.

That is, the server system 1100B generates a game play image for the player terminals 1500B (1500Ba, 1500Bb, ...) by rendering a game space image 12e based on each viewpoint camera based on the shared game space 8. Then, data for generating the game play image is transmitted to each player terminal 1500B.

The server system 1100B detects the occurrence of an involvement situation and controls the progress of the involvement situation play, but does not generate the game space image 12 (12a, 12b) related to the involvement situation play and its game play images. The game space image 12 (12a, 12b) related to the involvement situation play and its game play images are generated by the player terminal 1500B that has become the participating terminal (in FIG. 19, player terminal 1500Ba and player terminal 1500Bb are the participating terminals).

FIG. 20 is a functional block diagram showing an example of the functional configuration of the server system 1100B.
The server system 1100B has a game management unit 210B. The game management unit 210B corresponds to the game management unit 210 of the first embodiment (see FIG. 8 ), and controls the game progress of an asynchronous game using the shared game space 8. The server system 1100B also has a shared game space setting unit 212, a game play specification information acquisition unit 214, an evaluation unit 215, an involvement status detection unit 216, a mutual compatibility determination unit 218, an MMIF information provision unit 220B, and a permission/rejection setting unit 230.

The MMIF information provided by the MMIF information providing unit 220B to the player terminal 1500B does not include image data (which may be compressed data) of the game play image 14s as in the first embodiment, but includes data required to generate the game play image in the player terminal 1500B.

Specifically, the MMIF information provided by the MMIF information provider 220B includes data necessary for the player terminal 1500B, which has become the participating terminal, to set up a special game space 10, generate a game space image 12s, and generate a game play image 14s.

For example, data required when generating the special game space 10 includes the terminal level, information on the type, position, and status of background objects placed in the special game space 10, setting information for participating characters, information indicating the latest status in the shared game space 8, etc.

In addition, the involvement status includes information indicating the latest status of various objects in the special game space 10 during play, such as motion control data, information about the placement of new objects and the deletion of existing objects, etc.

The MMIF information providing unit 220B has a change control unit 222, and the game management unit 210B has a change notification control unit 232B and a model information notification control unit 234B.

The change notification control unit 232B includes, in the MMIF information, terminal-level information of the participating terminal to which the MMIF information is provided, as a control to notify the participating terminal that change control is being performed by the change control unit 222. In other words, the game play image 14s including the change notification display 16 is generated at the destination player terminal 1500B (see FIG. 4).

When the mutual compatibility conditions are met, the model information notification control unit 234B includes model information of the participating terminal that is the counterpart of the participating terminal to which the MMIF information is provided, in the MMIF information, as a control for notifying the participating terminal of information on the model of the participating terminal, which is the player terminal, to the participating terminal to which the MMIF information is provided. In other words, a game play image 14s including a model information notification display 18 is generated at the destination player terminal 1500B (see Figure 4).

As shown in FIG. 21, the server storage unit 500s of the server system 1100B stores a server program 501B, a distribution client program 503B, game initial setting data 510, user registration data 600, and play data 700s.

The server program 501B is a program for causing the server processing unit 200s to realize the functions of the game management unit 210B.
The delivery client program 503B is an original client program downloaded by the player terminal 1500B.

The play data 700s includes game progress management data 710, involvement status registration data 730, involvement status management data 750B, and terminal-specific image management data 780. The involvement status management data 750B corresponds to the involvement status management data 750 of the first embodiment (see FIG. 14), but the special game space data 760 and terminal-specific viewpoint camera control data 762 are omitted.

FIG. 22 is a functional block diagram showing an example of the functional configuration of the player terminal 1500B.
The player terminal 1500B has a client control unit 260B. The client control unit 260B has an operation input information providing unit 261, a display control unit 262B, and a special game space setting unit 264.

Similar to the display control unit 262 of the first embodiment, the display control unit 262B controls the display of gameplay images 14 of an asynchronous game using the shared game space 8 provided by the server system 1100.

In addition, the display control unit 262B controls rendering of a game space image 12s based on the special game space 10, and generation of a game play image 14s including the game space image 12s. The display control unit 262B also controls inclusion of a change notification display 16 and a model information notification display 18 in the game play image 14s based on the terminal level set for the player's own device included in the MMIF information and the model information of the other player's device that is the opponent in the involvement status play.

When the special game space setting unit 264 receives MMIF information (terminal level of the participating terminal) from the server system 1100B, it generates the special game space 10 by referring to the change control content data 540 (see Figure 6) that matches the terminal level of its own device.

The terminal storage unit 500 of the player terminal 1500B stores a client program 502B, game initial setting data 510, received MMIF information 590, special game space data 760B, the player's terminal-specific viewpoint camera control data 762B, and the current date and time 900.

The client program 502B is a program for causing the terminal processing unit 200 to realize the function of the client control unit 260B. The client program 502B includes a subroutine program for causing the player terminal 1500B to generate game play images based on the MMIF information received from the server system 1100.
The game initial setting data 510 is downloaded from the server system 1100B before the start of the game.

Figures 23 to 25 are diagrams for explaining the operation of the game system 1000B, and are diagrams for explaining the processing flow between the server system 1100B and the player terminal 1500B.

As shown in FIG. 23, the server system 1100B executes a participation acceptance process (step S110). The player terminal 1500B executes a participation application process (step S112).

After completing the participation application, the player terminal 1500B provides the game play specification information 605 to the server system 1100B (step S114).

The server system 1100B determines the terminal level of each player terminal 1500B based on the acquired game play specification information 605, and sets the determination result as the applicable terminal level 606 for each user (step S116). The server system 1100 then transmits a change control permission/denial setting request to each player terminal 1500B together with the information on each terminal level (step S118).

When the player terminal 1500B receives the request, it displays a screen showing the terminal level of its own device and options for permission/denial settings, and transmits information on the selection result to the server system 1100B (step S120).
The server system 1100B receives this and sets the permission/denial setting 609 of the player terminal 1500B that sent the request (step S122).

Next, the server system 1100B initializes the player character management data 711 and the viewpoint camera control data 722, and initially places various objects such as the player character 4 in the shared game space 8 (step S124). As a result, the vertex data of various objects and position information of polygons, etc. are initially set in the shared game space data 720.

Then, the server system 1100B starts controlling the game progress of the asynchronous game using the shared game space 8 (step S140), and starts generating and transmitting data of the gameplay image 14 for each player terminal 1500B (step S142). That is, the server system 1100B renders a game space image 12 of the shared game space 8 for each player terminal 1500, and generates a gameplay image 14 including the gameplay image 12. The gameplay image 14 at this stage does not include a change notification display 16 because it is not based on the special game space 10.

In response to the start of game progress, the player terminal 1500B transmits operation input information (or operation command information reflected from the operation input) one by one to the server system 1100B, and displays the game play image 14 on the display of the player terminal 1500B based on the received data (step S144).

When game progress control is started, the server system 1100 constantly monitors the occurrence of an involvement situation. When the occurrence of an involvement situation is detected (YES in step S150), the server system 1100 refers to the applicable terminal level 606 of the participating terminal and determines whether the terminal levels of the participating terminals are the same, i.e., whether the mutual compatibility condition is satisfied (step S152).

If the terminal levels are the same, it is determined that the mutual compatibility condition is met (YES in step S152), and the server system 1100 refers to the permission settings 609 of the user of the involved terminal. If all of the permission settings 609 referred to are "allowed" (YES in step S154), the involvement status registration data 730 is created, the involvement status and involved terminal are registered (step S156), and the involvement status management data 750B is created (step S158).

Moving on to FIG. 24, next, server system 1100B sends a situation start signal to the participating terminal of the newly registered participation situation (step S160).

The "status start signal" is a piece of MMIF information, and includes data for setting up the special game space 10 at the player terminal 1500B that has become the participating terminal. For example, it includes the terminal level of the participating terminal, information on the type, position, and status of background objects placed in the special game space 10, setting information for the participating characters and information indicating the latest status in the shared game space 8, information on the model of the participating terminal, etc.

Then, the server system 1100B temporarily suspends the generation of gameplay images 14 of the asynchronous game using the shared game space 8 to the participating terminals of the newly registered participation status, and the transmission of data to display the gameplay images 14 to the participating terminals (step S162).

When the player terminal 1500B receives a situation start signal from the server system 1100B (YES in step S170), it creates special game space data 760B (step S172).

Specifically, the participating characters and background objects are placed in the special game space 10 according to the information on the type, position, and status of the background objects contained in the previously received situation start signal, the setting information of the participating characters, and information indicating the latest status in the shared game space 8. At this time, the object model to be placed uses the object model data of the grade-specific data set 523 that is compatible with the terminal level contained in the situation start signal.

Furthermore, when the player terminal 1500B creates the special game space data 760B, it starts generating and displaying a gameplay image 14 based on the special game space 10. It switches from displaying the gameplay image 14 using the shared game space 8 to displaying the gameplay image 14 based on the special game space 10 (step S174).

Specifically, the player terminal 1500B renders a game space image 12s of the special game space 10 based on the viewpoint camera indicated by the terminal-specific viewpoint camera control data 762B according to the display quality settings of the change control content data 540 (see FIG. 6) that is compatible with the terminal level. Then, a game play image 14s including the game space image 12s, the change notification display 16, and the model information notification display 18 is generated and displayed on the display of the player's machine.

Furthermore, the player terminal 1500B starts restricting the type of operation according to the terminal level (step S176).

Specifically, the object initial setting data 520 (see FIG. 10) of the participating character is referenced, and operation input other than the operation types permitted in the terminal level-specific permitted operation type data 526 that matches the terminal level is invalidated, and the operation input information is not transmitted to the server system 1100B.

When the server system 1100B detects the occurrence of an involvement situation, it starts involvement situation play progress control as a fully synchronous game (step S190). In the involvement situation play progress control, each time the involved character management data 754 of the involvement situation management data 750B is updated, the server system 1100B performs control to send "situation progress information" to the involved terminal of that involvement situation. Then, together with starting the involvement situation play progress control, the server system 1100B starts control to reflect the progress results of that involvement situation in the shared game space 8 (step S192).

"Situation progress information" is a type of MMIF information, and includes information on updates to the participating character management data 754, and information on the background and effect objects of the special game space 10. For example, information on the movement, actions, and changes to ability parameter values of the player character 4, information on newly placed objects (e.g., NPCs 6 and flash and smoke effect objects), information on objects to be erased, etc.

On the other hand, after creating the special game space 10, the player terminal 1500B starts control for updating the special game space data 760B based on the situation progress information (step S194).
Therefore, each time the player terminal 1500B receives situation progress information from the server system 1100B, the player terminal 1500B updates the special game space data 760B based on the situation progress information. The contents of the special game space 10 of the participating terminal are maintained in a state consistent with the latest play progress status of the participation status.

The server system 1100B concurrently executes game progress control of an asynchronous game using the shared game space 8, while monitoring the end of an already occurring participation situation.
When the end of the involvement situation is detected (YES in step S200), the server system 1100B stops the play progress control of the involvement situation whose end has been detected, and stops transmitting situation progress information to the participation terminal of the involvement situation whose end has been detected (step S202).

Next, the server system 1100B returns the participating terminal whose participation status has been detected as having ended to the control target of the asynchronous game using the shared game space 8 (step S204), and ends the reflection control in the shared game space 8 (step S206).

Moving on to FIG. 25, the server system 1100B transmits a predetermined situation end signal to the participation terminal of the participation situation for which the end was detected (step S208), and deletes the participation situation registration data 730 and the participation situation management data 750B (step S210).

In addition, when the play control of the fully synchronous game is stopped and the asynchronous game is restored to the control target, the server system 1100B reflects the contents of the involved character management data 754 (the final state of the involvement situation play whose end has been detected) in the player character management data 711 of the game progress management data 710 (management data of the involved characters in the asynchronous game using the shared game space 8).

On the other hand, when the player terminal 1500B receives the situation end signal (YES in step S220), it releases the operation type restriction according to the terminal level (step S222). The player terminal 1500B then ends the generation and display of the game play image 14 based on the special game space 10 (step S224), and erases the participation situation management data 750 (step S226).

Meanwhile, the server system 1100B monitors whether or not the end condition of the game is satisfied from the start of the asynchronous game using the shared game space 8. If the end condition is satisfied (YES in step S250), the server system 1100B executes a game end process, transmits a game end signal to the player terminal 1500B (step S252), and ends the series of processes.
When the player terminal 1500B receives the game end signal (YES in step S254), the series of processes ends.

As described above, according to this embodiment, the same effects as those of the first embodiment can be obtained, and the load on the server system 1100B can be distributed to the player terminal 1500B. In addition, because high-quality image data has a large data volume, this has the effect of reducing the amount of communication data between the server system 1100B and the player terminal 1500B, and has the effect of reducing the possibility of communication delays.

[Modifications]
An example of an embodiment to which the present invention is applied has been described above, but the forms to which the present invention can be applied are not limited to the above-described forms, and components can be added, omitted, or modified as appropriate.

(Variation 1)
In the above embodiment, an MMO game is exemplified, but the present embodiment can also be applied to online games other than MMO games, that is, multiplayer online games that do not have enough players to be called MMO games.

The content of the game is not limited to a battle royale-style competitive action game, and can be set as appropriate. Depending on the game content, the definition of the involvement situation and the content of the involvement situation play can also be set as appropriate. For example, the involvement situation in the above embodiment is defined as an event in which two player characters 4 encounter each other, but is not limited to this.

For example, in a game in which multiple player characters 4 play in teams, an involvement situation can be defined as an event involving two or more player characters 4. Specifically, for example, an involvement situation may occur not only when an encounter occurs, but also when an event occurs in which the team encounters an NPC that is important to the progress of the game (e.g., defeating an NPC, obtaining an item requested by an NPC, etc.), or when the team solves a mystery that is important to the progress of the game.

(Variation 2)
In the above embodiment, the game system 1000 (1000B) is exemplified as a C/S type system, but is not limited to this. For example, it is possible to omit the server system 1100 and configure a P2P system using peer-to-peer connections of the player terminals 1500B, in which one or more of the player terminals 1500 perform the functions of the server system 1100.

(Variation 3)
In the above embodiment, the game progress control (progress control of an asynchronous game using the shared game space 8 and a completely synchronous game using the special game space 10) handled by the server systems 1100, 1100B can be handled by one or more of the player terminals 1500. That is, the server system 1100 handles participation reception, centralized management of the user registration data 600, and data relay processing between the player terminals 1500, but does not handle functions equivalent to the game management unit 210 of the first embodiment. The game management unit 210 of the first embodiment is handled by one or more of the player terminals 1500.

(Variation 4)
Based on the game system 1000B of the second embodiment, a server system 1100B:
It is also possible to configure the generation of game play images 14 of a game using the shared game space 8 and the generation of game play images 14 relating to participation situation play using the special game space 10 to be executed on the player terminal 1500B without performing both.

In this case, the server system 1100B stores the game progress management data 710, but the shared game space data 720, the player's viewpoint camera control data 722, and the reflected display control data 724 are omitted from the game progress management data 710. Instead, each player terminal 1500B stores the shared game space data 720, the player's viewpoint camera control data 722, and the reflected display control data 724 of the game progress management data 710 (see FIG. 13).

The server system 1100B then distributes progress information indicating the results of progress control of the asynchronous game using the shared game space 8 to each player terminal 1500B. Based on the progress information, each player terminal 1500B updates the shared game space data 720, the player's viewpoint camera control data 722, and the reflected display control data 724 stored therein. Then, based on the respective shared game space data 720, each generates and displays a game play image 14 of the shared game space 8.

(Variation 5)
The information describing the game play specifications can be set as appropriate.
For example, the model information may be the product name of the player terminal 1500, and the information describing the game play specifications may be only the model information. In that case, step S42 (see FIG. 17) may be interpreted as determining whether the models of the player terminals 1500 that are participating terminals are the same when the occurrence of a participation situation is detected. Then, if the number of model types of all participating terminals is one (in other words, if the models are the same), it may be interpreted as determining that the mutual compatibility condition is satisfied.

(Variation 6)
The detection of the participation status in the above embodiment may be configured to be performed for a limited period of time, for example, a specified period on a calendar.

(Variation 7)
In addition, the contents of the change control are not limited to the above embodiment, and can be added or omitted. For example, the contents of the change control may be to trigger a given corresponding event according to the terminal level. The contents of the corresponding event can be set appropriately according to the game contents. For example, in a battle royale-style fighting action game, a mini-game may be executed in which players compete to decide whether to go first or second in the involvement situation play, or a cut-in effect such as a special movie may be executed.

4...Player character 8...Shared game space 10...Special game space 12...Game space image 14...Game play image 16...Change notification display 18...Model information notification display 210...Game management unit 212...Shared game space setting unit 214...Game play specification information acquisition unit 215...Evaluation unit 216...Involvement status detection unit 218...Mutual compatibility judgment unit 220...MMIF information provision unit 222...Change control unit 230...Permission/rejection setting unit 232...Change notification control unit 234...Model information notification control unit 260...Client control unit 500s...Server memory unit 501...Server program 502...Client program 510...Game initial setting data 512...Shared game space initial setting data 520...Object initial setting data 523...Grade-specific data set 530...Terminal level definition data 540...Change control content data 590...Received MMIF information 600...User registration data 605...Game play specification information 606...Applicable terminal level 608...Player character setting data 609...Permission setting 700...Play data 710...Game progress management data 711...Player character management data 720...Shared game space data 724...Reflection display control data 730...Involvement status registration data 750...Involvement status management data 754...Involved character management data 760...Special game space data 762...Terminal-specific viewpoint camera control data 1000...Game system 1100...Server system 1150...Control board 1500...Player terminal

Claims (17)

A server system that provides an online game in which each player uses a player terminal as a man-machine interface (hereinafter referred to as "MMIF") to operate a player character that can move around a shared game space and enjoy multiplayer, comprising:
The player terminals include player terminals having different game play specifications,
a game play specification information acquiring means for acquiring information representing the game play specification of each of the player terminals;
an involvement situation detection means for detecting the occurrence of a given involvement situation in which N (N≧2) player characters are involved with each other in the shared game space;
a mutual compatibility determination means for determining whether or not the game play specifications of the player terminals (hereinafter, the player terminals that operate the participating characters are referred to as "participating terminals") that operate the N player characters that have become involved in the participation status (hereinafter, the player characters that have become involved in the participation status are referred to as "participating characters") satisfy a given mutual compatibility condition;
an MMIF information providing means for providing each of the player terminals with MMIF information for implementing the MMIF related to the multiplay in the player terminal;
Equipped with
The MMIF information providing means includes a change control means for providing the MMIF information, which has been subjected to a given change control for changing the MMIF information, to the participating terminal when it is determined that the mutual compatibility condition is satisfied.
Server system. The change control means changes the control content of the change control based on the game play specifications of the participating terminals that are determined to satisfy the mutual compatibility condition.
The server system according to claim 1 . The change control means executes, as the change control, a control for making the image quality of the game play image displayed on the player terminal different between the participating terminal determined to satisfy the mutually appropriate condition and the player terminal not satisfying the mutually appropriate condition.
3. The server system according to claim 1 or 2. The change control means executes, as the change control, a control for making the image quality and/or the number of objects displayed on the player terminals different between the participating terminals determined to satisfy the mutually appropriate condition and the player terminals not satisfying the mutually appropriate condition.
The server system according to any one of claims 1 to 3. The change control means executes, as the change control, a control for making the image quality of the moving image of the player character displayed on the player terminal different between the participating terminal determined to satisfy the mutual matching condition and the player terminal not satisfying the mutual matching condition.
5. The server system according to claim 1. The change control means executes, as the change control, a control for making the operation method of the player terminal for operating the player character different between the participating terminal determined to satisfy the mutually appropriate condition and the player terminal not satisfying the mutually appropriate condition.
6. The server system according to claim 1. The change control means executes, as the change control, a control for making a viewpoint setting of a game play image to be displayed on the player terminal different between the participating terminal determined to satisfy the mutually appropriate condition and the player terminal not satisfying the mutually appropriate condition.
The server system according to any one of claims 1 to 6. a change notification control means for notifying the participant terminal that the change control is being performed by the change control means;
The server system according to claim 1 , further comprising: a permission/prohibition setting means for setting permission/prohibition of the change control for each of the players based on a setting change operation of the player;
Further comprising:
The change control means executes the change control on the participating terminals that are determined to satisfy the mutual compatibility condition and for which the permission/denial setting is set to permission.
A server system according to any one of claims 1 to 8. the change control means sets a special game space, and executes, as the change control, control for moving the N participating characters within the special game space;
A server system according to any one of claims 1 to 9. the change control means sets the special game space within the shared game space, and performs control to make image quality within the special game space different from image quality outside the special game space.
The server system according to claim 10. the game play specification information acquiring means acquires information on a model of the player terminal as information representing the game play specification;
the mutual compatibility determination means determines whether the mutual compatibility condition is satisfied based on the information on the model of the player terminal acquired by the game play specification information acquisition means;
A server system according to any one of claims 1 to 11. a model information notification control means for notifying the participant terminal of model information of the player terminal when the mutual matching condition is satisfied;
The server system of claim 12 further comprising: an evaluation means for evaluating the player terminal based on the information representing the game play specifications acquired by the game play specification information acquisition means;
Further comprising:
The mutual compatibility determination means determines whether the mutual compatibility condition is satisfied based on the evaluation result of the evaluation means for the participating terminal.
A server system according to any one of claims 1 to 11. The MMIF information includes data required for generating game play images in the player terminal.
A server system according to any one of claims 1 to 14. A player terminal for enjoying game play in the online game by communicating with the server system according to claim 15,
A program for generating game play images based on the MMIF information received from the server system. A method for providing an online game in which each player enjoys multiplayer by controlling a player character that can move around a shared game space using a player terminal as a man-machine interface (hereinafter referred to as "MMIF"), comprising the steps of:
The player terminals include player terminals having different game play specifications,
a game play specification information acquisition step of acquiring information representing the game play specification of each of the player terminals;
an involvement situation detection step of detecting the occurrence of a given involvement situation in which N (N≧2) player characters are involved with each other in the shared game space;
a mutual compatibility determination step of determining whether or not the game play specifications of the player terminals (hereinafter, the player terminals that operate the participating characters are referred to as "participating terminals") that operate the N player characters that have become involved in the participation status (hereinafter, the player characters that have become involved in the participation status are referred to as "participating characters") satisfy a given mutual compatibility condition;
a MMIF information providing step of providing each of the player terminals with MMIF information for realizing the MMIF related to the multiplay in the player terminal;
Including,
The MMIF information providing step includes, when it is determined that the mutually appropriate condition is satisfied, providing the MMIF information subjected to a given change control for changing the MMIF information to the participating terminal.
How it is provided.

Images