JP2011005306A - Game system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a game to improve communication between players by providing various game modes, to increase an interest of the communication game.SOLUTION: The communication game system includes a client system 1 and a game server system 2 to communicate with the client system 1. The game server system 2 includes a database 21 in which a database to store group information relating a plurality of client groups as opposing groups. The game server system 2 decides a match among the client systems 1 belonging to one opposing group, and manages data transmission/reception between the client systems 1 decided by the match to oppose the systems, and decides the next match corresponding to the match result. Each client system 1 has a unique character selection function and a chatting function in observing a match.

Description

  The present invention relates to a communication game system for performing a game battle between remote game devices connected to a server. In particular, the communication game system according to the present invention is capable of performing complex battle management within a group formed by a player's request, being able to select characters used in the game without a sense of incongruity, and communication between game spectators A new communication game management method equipped with functions such as enhancing the network is provided.

  Conventionally, there has been a communication game system in which game devices operated by different players are connected to a common game server, and a battle game can be executed between remote players.

  In this system, the server is configured to list and display game devices connected at that time. If there is a match application from any game device to another game device, the server manages the transaction acceptance transaction between the applied game device and the other applied game device, and the match is accepted. Then, it is programmed to mediate while monitoring the transmission and reception of commands between both game devices.

  In the conventional system, when an opponent is determined, a screen for selecting one's own character used for the battle game is displayed in common between the game devices to be battled. For this reason, the player selects a favorite character from a common screen in each of the game apparatuses to be played. This selection information is transmitted and received between the opponents in real time via the server, like other game data. For this reason, both character selection information is displayed on a character selection screen common to both.

  Further, in the case of a conventional system, opponents can transmit messages to each other during execution of a battle game.

  With the advent of such a communication game system, a player can enjoy a game battle with other players.

  However, until now, the battle method in the communication game system has only repeated application of game battle, acceptance, and battle. Despite being able to play against a large number of game devices, I couldn't communicate as if I was enjoying a game with multiple friends at a game center. Also, it was easy for players to get bored because there was no development in the way of playing.

  In addition, since the character selection information is also displayed in real time between the opponent game devices, it is possible to know in advance what character the opponent is selecting, so the game starts. The previous expectation and freshness are halved.

  On the other hand, in a situation where the character selection screen provides a mode in which a customized character can be selected, a customized screen for selecting a character is displayed on the game device that specifies the customized character selection. That is, at this time, different character selection screens are displayed for the opponents. In this state, when a manual operation for selecting a customized character is performed on one game device, the movement of the cursor related to the operation is transmitted to the other game device, and the opponent is displayed on a screen different from the customized character selection screen. The cursor moves mysteriously and gives the other party a sense of incongruity. On the other hand, in the case of opponents who know each other's hands, the movement of the opponent's cursor is a hint as to what kind of customized character to select, and as before, killing the expectation before the game .

  Furthermore, in the conventional communication game system, the opponents can exchange messages and the like and can enjoy the game, but the spectators simply watch the game (including messages) that are currently in progress. It is. For this reason, as described above, there is a problem that the game cannot be enjoyed with a plurality of friends at a game center or the like and is easily bored.

  In view of this point, the present invention provides a communication game system and a method for processing the same, which provide a variety of ways of playing that have not been provided by conventional communication game systems, thereby making it possible for players to communicate with each other and make the communication game more interesting. The purpose is to provide.

  Another object of the present invention is to provide a communication game system and a method for processing the communication game that make communication games more interesting by aiming at communication between spectators that were not provided by conventional communication game systems.

  In addition, the present invention provides a communication game system and a processing method thereof in which when selecting a character to be used in a battle game, an operation related to the selection does not give a sense of incongruity and prevents a feeling of expectation and excitement before the game from being lowered. It is yet another object to provide

  In order to realize this purpose, in a communication game environment where a large number of unspecified people participate, it is necessary to satisfy a request to play with those who can be friends on the network, such as those of interest.

  In addition, it is necessary to satisfy the requirement to be able to evaluate one's skill by various combinations of battles such as team battles, round-robin battles, tournament battles, etc. that are usually performed in games and competitions where many people participate.

  Furthermore, even when the player himself is not playing a battle, it is necessary to satisfy the demand for watching and enjoying it when another player is playing a battle.

  Furthermore, it is necessary to satisfy the demand for enjoying the game so that there is no sense of incongruity and the exhilaration before the game is not killed in the selection of the battle character from the screen.

  The present invention relates to a communication game system including a client system and a game server system that communicates with the client system. The game server system has a plurality of types of group information for associating a plurality of client systems as a single battle group. If any one battle group is specified, the group information related to the specified battle group is referred to and the same battle group is assigned to the same battle group. The combination of battles is determined from the client systems to which the system belongs, the transmission and reception of data between the client systems determined by the combination is managed, the battle is executed, and the next combination is determined according to the result of the battle It is characterized by being configured It is a communication game system.

  For example, at least one of the group information stored in the database is that the winning client, the losing player, the fixed client system, or any one of the fixed client systems continues when the battle ends. The match rule information for setting the match mode determined to play against the client system of the game system is included, and when the match is over, the game server system refers to the match rule information and the next match combination To decide. When a command indicating acceptance is transmitted from both of the client systems corresponding to the next battle combination, the game server system executes the battle.

  For example, at least one of the group information stored in the database stores schedule information for setting a team battle mode in which the same battle group is divided into two subgroups. When the battle is over, referring to the schedule information, as a result of the battle, the winning client system and the other client systems in the subgroup to which the losing client system belongs are not Determined as the next match combination. Preferably, in the schedule information, a battle order within a subgroup is set in advance, and the game server system is configured to perform the team battle when the last remaining client system in any one subgroup loses the battle. Is notified to each client system.

  For example, at least one of the group information stored in the database may be ordered so that one client system will play against all other client systems in the same battle group when the battle ends. The registration information for setting the brute force battle mode is stored, and the game server system refers to the registration information when the battle by one combination is finished, and each client system has not yet competed. Another client system that is a client system and is not in a battle is determined as a combination of the next battle for each client system. Preferably, the game server system notifies each client system of the result of the round-robin battle as a star chart when the battle by all combinations is completed.

  For example, at least one of the group information stored in the database stores registration information for setting a tournament battle mode in which a battle is won in the same battle group when the battle ends. The game server system refers to the registration information when the match by one combination is completed, determines the next match, and determines the next client system that has won the match by the determined combination. It is determined as a combination of battles. Preferably, the game server system notifies each client of the result of the tournament game as a tournament table when one client system has won the game through the final game.

  In the present invention, the game server system selects either one of the other arbitrary client systems when a battle is requested from any of the client systems, or a simple battle mode, or any one of them. It is characterized in that any one of the expert battle modes belonging to each battle group and battled in each battle group is selected and executed.

  For example, the game server system provides each client with a battle mode list display that allows each client system to browse the battle group with reference to the group information. When any battle group is selected in the battle mode list display from the client system, this game server system reads group information corresponding to the selected battle group from the database and displays the contents.

  Preferably, the database stores battle history information of client systems belonging to any of the battle groups, and the game server system is configured when any of the client systems is selected in the battle mode list display from the client system. The battle history information corresponding to the selected client system is read from the database and the content is displayed.

  Preferably, when the game server system determines a combination of battles in the battle group, the game server system determines whether or not a combination is possible according to the degree of strength determined from the battle history information of each client system.

  Preferably, when the game server system determines a battle combination in a battle group, the game server system sets a handicap based on the battle history information in each client system, and a battle in a combination in which the handicap is set The update of the battle history information based on the battle result is prohibited.

  More preferably, the game server system includes a WWW server system connected to a wide area network, and the game server system creates a file for displaying a battle history based on the battle history information and can be viewed on a computer in a storage area of the WWW server system Store in the correct state.

  In the present invention, when there is a request for creating a new battle group from any client system, the game server system newly registers new group information in the database based on the setting contents of the client system.

  In addition, when there is a request for participation in any battle group from any client system, the game server system of the present invention associates the client system with the group information of the battle group that has requested participation.

  The game server system of the present invention transmits / receives battle data to / from client systems that are fighting in the battle group, and between client systems that are fighting to client systems that are not fighting in the battle group. Send / receive watching data for watching a match.

  Preferably, in the database, correspondence information for associating a message desired to be provided to a client system being watched by each client system during a battle with a player's operation content is registered. When the client system is competing, the operation content from the client system is referred to, and the correspondence information associated with the operation content is read and notified to the observing client system.

  Similarly, when one of the client systems is playing a battle, this game server system notifies the other client systems of the message when a message is transmitted from the client system watching the battle.

  The client system further includes vibration generating means for transmitting vibration to the player in response to a command from the game server system, and the game server system includes vibration generating means according to the operation content from any of the client systems. Send the command to drive to other client systems. The “vibration generating means” is not limited and can be arbitrarily applied, such as one using a piezo element or one using an eccentric motor.

  Specifically, the game server system of the present invention includes a database that associates a plurality of client systems as a battle group, a communication device that transmits / receives data to / from each client system, and a plurality of clients in the same battle group with reference to the database. And a processing device for managing game battles between client systems.

  The communication game processing method of the present invention is a communication game processing method executed between a client system and a game server system communicating with the client system. The game server system relates a plurality of client systems as one battle group. When a plurality of group information to be attached is referred to a database in which a plurality of types of battle modes are stored and any one battle group is specified, it is related to the specified battle group. Determining a combination of battles from among client systems belonging to the same battle group, managing data transmission / reception between the client systems determined by the combination, and executing a battle And in the result of the match And response is a communication game processing method characterized by comprising the steps of: determining a next combination.

  At least one of the group information stored in this database is that when the match is over, the winning client system, the losing player, the fixed client system, or one of the fixed client systems continues to other clients. The game rule information for setting the battle mode determined to play against the system is included, and the step of determining the next combination is as follows by referring to the game rule information when the battle ends. Determine the match combination.

  In addition, at least one of the group information stored in this database stores schedule information for setting a team battle mode in which the same battle group is divided into two subgroups, and the next combination is determined. When the battle ends, referring to the schedule information, as a result of the battle, as a result of the battle, the winning client system and the other client system that is not in the battle among the subgroups to which the losing client system belongs And are determined as the next battle combination.

  Furthermore, at least one of the group information stored in this database was ordered so that one client system would play against all other client systems in the same battle group when the battle ended. The registration information for setting the brute force battle mode is stored, and the step of determining the next combination is a client system in which each client system has not yet competed when the battle of one combination is completed. Another client system that is not in a battle is determined as the next battle combination for each client system.

  At least one of the group information stored in this database stores registration information for setting a tournament battle mode in which a battle is won in the same battle group when the battle is over. In the step of determining the next combination, when a match by one combination is completed, a combination to be battled is determined with reference to the registration information, and the client systems that are winners of the battle by the determined combination are determined as follows. It is determined as a combination of battles.

  Preferably, in the communication game processing method, when there is a battle request from any of the client systems, a simple battle mode in which any one of the other client systems is selected and played, or A step of selecting and executing any one of the proficient battle modes belonging to the battle group and fighting in each battle group.

  More preferably, the method includes a step of providing each client with a battle mode list display for causing each client system to browse the battle group with reference to the group information.

  These communication game processing methods may be provided in a program format executable by a computer on a recording medium (CD-ROM, DVD, communication line, etc.).

  Moreover, as another aspect of the present invention, a communication game system capable of transmitting and receiving data relating to a game in real time through the game server system between client systems in which a partner is determined among the plurality of client systems, Each of a plurality of client systems, when one client system transmits data including data to be invalidated when the data is transmitted / received between the client systems, the other client system invalidates the data. I have tried to invalidate the data that should be.

  Preferably, each of the plurality of client systems transmits transmission means for transmitting the game including data to be invalidated to the game server system, and data to be invalidated is transmitted from the game system. And invalidation processing means for invalidating data to be invalidated. For example, the transmission means is means for transmitting data to be invalidated together with information representing the invalidation.

  The information indicating invalidation is, for example, position information indicating which display position on the screen corresponds to data to be invalidated. The information representing the invalidation may be a flag representing the invalidation or dummy data.

  The data to be invalidated is, for example, data related to an operation when a player selects a customized character on a screen for selecting a game character. At this time, the data related to the operation is data related to the operation of the controller or the pad, for example.

  Preferably, each of the plurality of client systems includes, as a game character selection screen, a first button for selecting a common character stored in advance in the plurality of client systems, and a desired client system Means for presenting a screen including a second button for transitioning to a mode for selecting a customized non-common character that can be stored via a removable memory device, and the data to be invalidated is , Data representing an operation state when the second button is selected.

  Preferably, the invalidation processing means is a process of discarding data to be invalidated and putting it in a non-display state.

  Further, according to the present invention, a system provided as another aspect is a communication capable of transmitting and receiving data relating to a game in real time via the game server system between client systems in which an opponent is determined among the plurality of client systems. A game system, wherein each of the plurality of client systems is capable of chatting with another client system in the watching state when watching the game via the game server system. And

  Preferably, each of the plurality of client systems receives a content of the chat from a player when watching the game, and transmits character information corresponding to the content to the game server system. And display means for superimposing and displaying the character information on the game screen of the monitor when the character information is transmitted from the game server system. At this time, the display means is means for displaying the character information in a semi-transparent window set with the game screen as a background on the screen of the monitor, for example.

  According to the present invention, as yet another aspect, among the plurality of client systems, a communication game system capable of transmitting and receiving data relating to a game in real time through the game server system between client systems in which an opponent is determined, Each of the plurality of client systems displays an image in which the space is projected from a changeable virtual viewpoint in the game space in which the game is executed when watching the game. Provided.

  According to the present invention, since it is possible to form a group among an unspecified number of client systems, it is possible to provide a variety of ways of playing that were not provided by conventional communication game systems. The communication game can be made even more interesting.

  In particular, according to the configuration of the present invention, in a communication game environment in which a large number of unspecified persons participate, it is possible to satisfy a demand for mainly playing with friends who can be friends on the network, such as those of interest.

  In addition, the configuration of the present invention satisfies the requirement to be able to evaluate one's skill with various combinations of battles such as team battles, round-robin battles, tournament battles that are usually performed in games and competitions in which many people participate. it can.

  Further, according to the present invention, even when the player himself is not in a battle, it is possible to satisfy the request that he / she wants to enjoy watching it when another player is in a battle. For example, since communication between spectators, which was not provided in the conventional communication game system, can be actively promoted, it is possible to have a sense of unity with the game even while watching the game, making the communication game more interesting. can do.

  Furthermore, according to the present invention, it is possible to provide a communication game in which when selecting a character to be used in a battle game, an operation related to the selection does not give a sense of incongruity and can maintain a feeling of expectation and excitement before the game. Can do.

The system block diagram of the communication game system of this invention. The hardware block diagram of the communication game system of this invention. The state transition diagram of the communication game system of this invention. The flowchart of the communication game processing method (normal battle mode) in Embodiment 1. The flowchart of the communication game processing method (team battle | competition battle mode) in Embodiment 2. FIG. The flowchart of the communication game processing method (round-robin battle mode) in Embodiment 3. The flowchart of the communication game processing method (tournament battle | competition battle mode) in Embodiment 4. The processing flowchart of the client system in this invention. Display example of the easy lobby strategy window (S01). A display example of the expert lobby operation window (S10). A display example of the start menu (S11). The example of a display of a meeting room selection menu (S12). Display example of comment registration (S14). A display example of a battle status report window (S20). The example of a display of a connection person list (S21). A display example of the normal operation conference room (S30). A display example of the player data window (S33). The example of a display of a game rule change window (S32). A display example of the team warfare conference room (S40). A display example of the player data window (S43). The example of a battle schedule change window (S43). A display example of the brute force operation conference room (S50). The example of a participating member registration window (S52). Display example of a star chart (S55). Display example of tournament war strategy conference room (S60). The example of a participating member registration window (S62). FIG. 9 is a schematic configuration diagram of a game machine main body according to a fifth embodiment. The schematic diagram which shows the structure of a data format. The flowchart which shows the outline | summary of character selection with FIG. The flowchart which shows the outline | summary of character selection with FIG. The flowchart which shows the outline | summary of the process routine of character selection. The figure which shows the initial screen at the time of character selection. The figure which shows the selection screen in custom mode at the time of character selection. The figure which illustrates the game screen for opponents. The figure which illustrates the game screen for spectators.

Next, preferred embodiments of the present invention will be described with reference to the drawings.
(Embodiment 1)
In the first embodiment of the present invention, the same battle group is formed between the client systems, the battle combination is determined from the client systems belonging to the client system, and the winning one, the losing one, the fixed both or the fixed one The present invention relates to a communication game system configured such that the established client system continues to play against other client systems.

  FIG. 1 shows a system diagram of the communication game system of the present invention.

  As shown in FIG. 1, the communication game system is configured by connecting a plurality of client systems 1 to a game server system 2 and a WWW server system 3 via a network 4.

  Each client system 1 has a configuration as a game device having a so-called communication function, and is configured by mutually connecting a game machine main body 10, a control pad 11, and a monitor 12.

  The control pad 11 supplies an operation signal output with each player's operation to the game machine body 10. The game machine body 10 has a configuration (CPU, memory, CD-ROM drive, modem, image generation circuit, sound generation circuit, etc.) as a communicable computer device. The game machine body 10 can read data from a recording medium such as a CD-ROM, and operates as a client system of the communication game system by executing a game program read from the recording medium. Yes. The game machine body 10 advances the game process based on the operation signal from the control pad 11, and when the communication game is designated by the player, the game machine body 10 is connected to the game server system 2 via the line network 4 via the built-in modem. It comes to connect. As long as the game program recorded on the recording medium can execute the communication game function, the content of the game is not limited. However, it is preferable that the game is programmed as a battle-type game in which the player wins or loses against other players. In addition, the game machine body 10 is configured to output an image signal and a sound signal accompanying the game processing. The monitor 12 is configured to provide the player with images and sounds corresponding to the image signals and audio signals from the game machine body 10.

  The game server system 2 includes a game server 20 and a storage area 21.

  The game server 20 has a configuration (CPU, memory, HD, communication device, etc.) as a general-purpose high-performance computer device. The game server 20 operates as a game server system that manages the communication game system by executing a program corresponding to the game processing method of the present invention. That is, the client system 1 connected to the access point of the game network 40 is managed. The storage area 21 is an area that can be accessed from the game server 20 itself or from the server, and is an area in which a database necessary for executing the communication game system can be stored in the form of a file or the like.

  The line network 4 is a normal public line or dedicated line, and forms a WAN such as the game network 40 and the Internet 41.

  The game network 40 is a network provided for executing the communication game system. For example, a dedicated network configured by the game server system 2 and each client system 1 by connecting from the client system 1 to a specific access point managed by the game server system 2. However, instead of such PPP connection, a connection configuration via the Internet may be provided such that the client system accesses the game server from an arbitrary connection window. The protocol is not limited, but the client system 1 may use a general-purpose standard such as TCP / IP in consideration of the use of the WWW function on the Internet or the general purpose.

  The Internet 41 is a WAN to which an unspecified number of computer devices can be connected. By using various commands defined by the TCP / IP protocol, file browsing, e-mail, file transfer, and the like can be realized. It is possible. In particular, this embodiment uses the WWW function of the Internet.

  The WWW server system 3 includes a WWW server 30 and an HTML (hypertext format) storage area 31.

  The WWW server 30 has a configuration as a general-purpose high-performance computer device, is given a single network address on the Internet 41, and designates a specific network address from a computer connected to the Internet 41, thereby storing HTML. An HTML format file stored in the area 31 can be browsed. The HTML storage area 31 is a storage area managed by the WWW server 30, and a hypertext format file for displaying a result of a communication game created by the WWW server 30 or transferred from the game server system 2 is specified. It is supposed to be stored in the directory. This WWW server is for notifying the battle history, but a dedicated server is provided instead of the Internet server, and a file in which the battle history is recorded is uploaded to the client system so that the client system can connect to it and browse it. You may comprise.

  FIG. 2 shows a detailed functional block diagram of the communication game system. In the client system 1 (A, B), the processing device 100 and the communication device 101 belong to the game machine main body 10. The output data generation device 102 and the control pad 11 belong to the control pad 11.

  The processing device 100 is a computer portion that executes a game program with a CPU at the center. The processing device 100 performs recognition of an operation signal from the operation device 110, output of a vibration signal to the vibration generation unit 111, communication control of the communication device 101, control of the output data generation device 102, and the like. The communication device 101 is a modem or a terminal adapter, for example, and mediates data transmission / reception between the game network 40 or the Internet 41 and the processing device 100. The operation device 110 has operation functions necessary for game operations such as operation buttons and a cross key. The vibration generating means 111 can cause a player operating the control pad 11 to recognize the vibration in response to a vibration signal having a predetermined frequency by an inverse piezoelectric effect such as a piezo element.

  In the game server system 2, the processing device 200 and the communication device 201 belong to the game server 20. The storage area 21 stores a user database (hereinafter abbreviated as DB) 210, an easy lobby DB 211, an expert lobby DB 212, a normal DB 213, a team battle DB 214, a round-robin battle DB 215, a tournament battle DB 216, and the like.

  In the user DB 210, personal information of a player who is permitted to use the communication game system, for example, a management number unique to each game machine body 10, an individual address, contact information, etc. The winning percentage, consecutive winning record, registration comment, class, character information, and the like are stored.

  The easy lobby DB 211 stores index information in the easy lobby, that is, the simple battle mode. For example, a battle combination in Easy Lobby, its date and time, chat information, and the like are recorded.

  In the expert lobby DB 212, index information in the expert lobby, that is, the expert battle mode is recorded. For example, the name (operation name) of each battle group, the number of participants, the battle type, link information to the DBs 213 to 216, chat information in the lobby, and the like are recorded.

  In the normal DB 213, the team battle DB 214, the round-robin battle DB 215, and the tournament battle DB 216, battle group information for each battle type is recorded. For example, the name of the battle group (operation name), the number of participants, the number of battles, the start time and end time of each operation, the member name (including ID), the rank of each member, the game rules, the determined combination information, the battle history, Chat information and the like in the battle group are recorded.

  These databases can be cross-referenced, and relationships are set so that all information can be read by key data.

The processing device 200 is a computer part that manages the communication game system. The processing device 200 refers to each of the databases 210 to 216 and controls the communication device 201 to execute the battle management of the client system defined by the program. In particular, in this embodiment, the databases 210 to 212 and the normal database 213 common to the embodiments are used. The communication device 201 manages access points on the game network 40 and mediates data transmission / reception between each client system 1 and the communication device 200.
(Client system operation)
Next, the operation of this embodiment will be described. First, the basic operation of each client system 1 will be described with reference to FIG.

  Each client system 1 uses an independent mode for proceeding with game processing based on a program and an operation signal from a player, and a communication mode for proceeding with game processing based on commands provided by communication.

  In any of the operation modes, the game machine body 10 interprets an operation signal from the control pad 11 and moves a character (operable segment or model) on the game screen. However, the movement of the enemy character in the game is defined by a program in the independent mode, whereas in the communication mode, it is defined by a command transmitted from the client system 1 that is the opponent via the game network 40. It is different in point. In the communication mode, the game machine body 10 converts the operation signal into a command and sends it to the game network 40.

  Specifically, as shown in FIG. 8, the game machine body 10 reads the operation signal (S501), and checks whether the operation content indicates the start of communication (S502). When the communication is not started (S502: NO), the mode is the independent mode, and the process as a normal game device is continued (S503).

  On the other hand, when the start of communication is indicated (S502: YES), the game machine main body 10 executes a general procedure for establishing a connection because of the communication mode. That is, the game machine body 10 selects and calls a pre-registered server, and transmits necessary information such as a handle name, ID, and password after connection (S504). If the connection cannot be established, the processing apparatus displays that fact and returns.

  After establishing the connection, the game machine body 10 displays a main menu (S505). When the game start is instructed by the player, the game machine body 10 thereafter performs a permanent loop process that does not return unless a special operation such as escape is performed. That is, when an operation signal is supplied (S506: YES), the game machine body 10 reads the operation signal (S508), converts it into a command according to a predetermined command rule, and sends it to the game network 40 (S509). When a command is transmitted from the game network 40 (S510: YES), the game machine body 10 reads this (S511), and proceeds to an interpretation routine.

  That is, when the command indicates the easy lobby strategy window display (S512: YES), the game machine body 10 displays a basic screen (see FIG. 9) called an easy lobby strategy window (S513). Similarly, if the command indicates expert lobby strategy window display (S514: YES), the game machine body 10 displays a basic screen called expert lobby strategy window (S513). The expert lobby strategy window here includes various window displays (FIGS. 11 to 26) in addition to the basic screen (see FIG. 10 and the like). These basic screens are displayed based on image data stored in the client system. However, the hypertext format file for displaying these operation windows is stored in the game server system 2, and this file is provided to the client system in a timely manner and displayed based on the function of the browser for browsing hypertext. It may be configured.

  If the command indicates a shift to the battle mode (S516: YES), the game machine body 10 executes a battle process using image data in the client system instead of the screen display. (S518).

  When the client system 1 is assigned to the battle mode, the game machine body 10 moves its character based on the operation signal, and the position of the enemy character based on the operation command provided from the game network 40. And change the aspect. The assignment of operation commands can be arbitrarily determined for each game. With these processes, the player can perform a game battle as if he were playing a game against another person by connecting the two control pads 11 to one game machine.

  When the client system 1 is assigned to the watching mode, the game machine body 10 moves both characters based on an operation command provided from the game network 40 and changes its display mode. By this process, the player can perform a game watching as if he or she supports a friend playing a game at the amusement center.

  When chat information is sent as a command, the game machine body 10 displays characters on the screen of the monitor 12 based on the chat information (S519). When a command to vibrate is sent as a command, the game machine body vibrates the vibration generating means 111 of the control pad 11.

  Here, a procedure in which any player applies for a match with another player in the simple battle mode (easy lobby) will be described with reference to FIG. These procedures are almost the same in both the simple battle mode and the expert battle mode (expert lobby) described later.

  As shown in FIG. 2, in a state where the client systems 1A and 1B are connected together, the game server 20 monitors the client system 1 connected at that time, and the IDs of these client systems and the number of connected users. Are stored in the easy lobby DB 211. The game server displays an easy lobby operation window as shown in FIG. 9 on the client system in the simple battle mode. In this window, the name, state, and total number of connected users are displayed in the opponent list based on the connected user data that the game server 20 has searched for and transmitted from the easy lobby DB 212.

  When the cursor is on the opponent list based on the operation signal, the client system 1A transmits selection information of the cursor to the game server 20 (path 1). The game server 20 reads the battle history of this person from the user DB 211 (route 5) and returns it to the client system 1A (route 2). In the client system 1A, the list is displayed as opponent information. When the player of the client system 1A operates the control pad 11 to designate a battle application (1), the game server 20 transmits that fact to the client system 1B related to the application (path 3). In response to this, the player of the client system 1B returns whether or not to accept the battle (path 4).

  If this reply indicates application rejection, the game server 20 transmits a message to that effect to the client system 1A (1). The player of the client system 1A searches for another client system and applies for a battle again.

On the other hand, if the reply from the client system 1B indicates acceptance of the application, the game server 20 sends a message to that effect to the client system 1A (1), and sends a command for shifting to the battle mode to both client systems. Transmit (1, 3). Both client systems 1AB shift to the battle mode, and thereafter send their own commands to the other (path 6). Although the game server system 2 mediates transmission / reception of commands in the battle mode, it may be configured to directly transmit / receive commands by specifying the network address of the opponent. Such a communication procedure is the same in the expert battle mode (expert lobby).
(Overall operation)
The sequence between the individual client system and the game server system is as described above, but the present invention is characterized by the overall battle management positioned above the individual sequence. This will be described focusing on the state transition diagram of FIG. This figure shows the state of each client system 1 that varies under the management of the game server system 2. This figure is common to the embodiments described later.

  In the present invention, the game server system 2 selects a simple battle mode (easy lobby) in which any one of the client systems 1 plays a battle when there is a battle request from any of the client systems 1 or One of the battle modes (expert lobby) that belongs to any battle group and battles in each battle group is selected and executed.

  In the simple battle mode, as described above, the game server 20 displays the main menu on the client system 1 with which communication has been established (S00). A menu is displayed (S01: FIG. 9). When the battle is accepted, the game server 20 shifts the client system 1 involved in the battle to the battle mode (S02).

  The client system 1 displays a start menu when a start button is pressed on the control pad 11 (S03). When the expert lobby is selected from the start menu or the main menu, the game server 20 displays an expert lobby strategy window which is a basic screen for expert battle (S10).

  Since the expert lobby requires familiarity with how to play, it is preferable that the client system 1 connected for the first time is configured to be implemented from the easy lobby. After that, any battle mode can be freely selected by the player's selection.

  As the expert lobby strategy menu, as shown in FIG. 10, a title window W1, a chat window W2, and a strategy name list W3 are displayed. The title window W1 is a display field for the battle mode. In the chat window W2, a character string W21 based on the chat information transmitted from the client system 1 in the expert battle mode is displayed in time series. When the chat information is sent, the game server 20 stores the chat information in the expert lobby DB 212 together with the name of the transmission source, and displays the chat window W2 based on the chat information. In the chat window W2, a pseudo keyboard W22 for inputting characters is displayed. The strategy name list W3 is a battle group list that the game server 20 refers to and displays the group information stored in the expert lobby DB 212. This strategy name list W3 is a list for each battle group, unlike the connection list for each client system in the easy lobby strategy window (FIG. 9). That is, a plurality of battle groups including a strategy name, the number of participants, and a battle mode are displayed. At this time, it is preferable to be able to list whether the battle is in progress or not in a battle state by a lamp display or the like.

  In the client system 1, when the player operates the start button of the control pad 11, a start menu M1 corresponding to the mode at that time is displayed (S11: FIG. 11).

  When “Create meeting room” is selected in the start menu M1, the game server 20 further displays a menu M2 for selecting the battle mode (S12: FIG. 12). When any battle mode is selected from this menu, a battle group corresponding to the battle mode is newly created, and the “strategy conference room” is displayed (S13).

  When one or more client systems 1 participate in the “strategy conference room” created in the selected battle mode after new registration (S30, S40, S50, S60), one battle group is formed. In the menu M2, when “normal” is selected, the battle mode of the present embodiment is selected. When “team battle” is selected, the second embodiment is selected. When “brute force” is selected, the third embodiment is selected, and “tournament” is selected. Then, it becomes possible to create a strategy meeting room, that is, a battle group, described in each embodiment of the fourth embodiment.

  In the conference room creation process (S13), the client system 1 that has requested new registration can define any game rule. Only the newly registered client system can change the game rules of the strategy meeting room or start a battle of the battle group. Hereinafter, the client system in which this new registration is performed and the “strategy conference room” is established is referred to as “host”. Group information for recording necessary information such as game rules and participating members regarding the battle mode is registered in the corresponding databases 212 to 216 by the game server 20. Each time a new member is registered or the game rules are changed, the game server 20 changes and updates the group information.

  When “comment registration” is selected in the start menu M1, the game server 20 displays a comment registration window W4 (S14: FIG. 13). In this window W4, a comment field W41 for inputting a self-introduction document to be displayed when personal information is referred from another client system 1, and the same game watching the battle when entering the battle mode. A quick message field W42 for registering characters to be provided to other client systems of the battle group in correspondence with the operation buttons of the control pad 11, and a software keyboard W43 for character input are displayed. When the player inputs arbitrary characters in these fields, the game server 20 stores them in the user DB 210 in correspondence with the operation buttons. The character information for displaying these comments is transferred in advance by the game server 20 to each client system 1. The database stores correspondence information indicating correspondence between each comment and an operation command. The game server 20 monitors the presence or absence of an operation command on the game network 40, and when an operation command is transmitted, reads the correspondence information from the database and transmits it to each client system 1. Each client system 1 displays character information corresponding to the correspondence information on the screen.

  When “change chat channel” is selected in the start menu M1, the game server 20 changes the chat channel from the common chat channel in the expert battle mode to the chat channel unique to each battle group. Specifically, the server 20 switches the database from which chat information is read between the chat DB 211 and the other databases 213 to 216.

  When “send message” is selected in the start menu M1, the game server 20 stores the chat information supplied from the client system in the selected chat channel in the database, and other connected client systems 1 To provide.

  When “search for another member” is selected in the start menu M1, the game server 20 displays other battle groups that have not been displayed in the strategy name list W3. When “main-use virtualoid registration change” is selected, the game server 20 enables the character adapted to each client system 1 to be changed, and updates the user DB 210 with the changed content. When “move to easy lobby” is selected, the game server 20 moves the client system 1 to the state S01. When “Exit from network” is selected, the game server 20 transmits a command for shifting from the communication mode to the independent mode to the client system 1, and the client system 1 is removed from the game network.

  In the expert lobby strategy window (S20, FIG. 10), when the player brings the cursor onto the strategy name list W3, the strategy name information selected by the cursor is provided to the game server 20 as a command. The game server 20 searches the expert lobby DB 212 based on the strategy name information, identifies the databases 213 to 216 in which the corresponding battle group is stored, reads the detailed information, and returns it to the client system 1. As a result, a battle status window W5 is displayed (S20: FIG. 14).

  In this window W5, the battle mode W51, the number of participants W52 of the battle group, the type display W53 of actual battle or simulated battle, the operation start time W54 that is the time when this battle group was created, and the status W55 that specifies the rules of the game And the participating member W56 is displayed.

  Each player has a class determined and registered in accordance with the battle history stored in the user DB 210. The class is attached to the member. The display of participating members should be ordered according to the top and bottom of the class. This is because it is possible to enthusiasm for the player who wants to move up and raise the rank. On the other hand, some players receive a sense of killing if this class always affects the battle. For such a person, by selecting a person who newly sets a battle group, it is possible to select “actual battle” in which the class is applied and “simulated battle” in which the class is not considered.

  The game server 20 monitors the connection status of each participating member and displays the status next to each member name. For example, a status such as “combat” is displayed for a player who is playing a battle, “watching” is displayed for a player who is watching a game, and “waiting” is displayed for a player who is browsing the expert lobby strategy window.

  When a predetermined operation is performed by the player while the battle status report window W5 is displayed, the game server 20 reads personal information about all the client systems 1 that are currently connected regardless of the battle group from the user DB 210 and connects to it. Person list W6 is displayed. The total number of connected users is also displayed (S21: FIG. 15). When any one of the connected persons is selected with the cursor in the connected person list, the game server 20 further reads out the personal information of the client system 1 related to the connected person from the user DB and displays it in the player data window W7. In this window W7, the name W71 of the connected person, the result W72 of the day, the class chapter display W73 corresponding to the class, and the character displays W74 and S14 employed in the client system 1 for use in the battle game are registered. The comment W75 and the current status display W76 of the client system 1 are displayed. When a predetermined operation (for example, “L” button or “R” button operation) is performed from this state, the total score of the client system 1 is displayed based on the user DB 210. When another operation (for example, “A” button operation) is performed, a message is transmitted to the selected client system 1 (S23).

  When the player performs a predetermined operation (for example, pressing the “A” button) in the battle status report window W5 (S20: FIG. 14), the client system 1 that has performed the operation newly joins the battle group. Registered as a thing. That is, the game server 20 determines that there is a request for participation in the selected battle group from the client system 1, and registers the client system 1 as a new participant in the battle group (S30). The game server 20 newly associates the personal information of the client system 1 that wishes to participate in the group information of the battle group.

When newly participating (S30), a password may be set for each battle group, and authentication processing may be performed so that participation is not possible unless the password is input. That is, when there is a request for participation in a new battle group, the client system 1 that wishes to participate is requested to enter a password, and only when this password is correctly entered, the game server 20 will participate in the battle group. Allow it.
(Normal Operation Conference Room)
In the following, battle management for a battle group in which “normal” is set as the battle mode will be described. “Normal” battle mode means that when one battle ends, the winning, losing, fixed or both fixed client systems will continue to play against other client systems. It means a match based on various game rules.

  FIG. 16 shows a screen display example provided to the client system 1 participating in the “normal” battle mode. Such a “strategy conference room”, that is, a lobby operation window dedicated to a specific battle group, is provided only to the person who started the battle group (host) or to those who participated later. The game server 20 performs each display by reading the corresponding record from the normal DB 213.

  The title window W1 indicates “normal” which is the battle mode. Below that, a status display W11 indicating whether or not the battle is in progress, an operation name W12 that is the name of this battle group, a number of participants W13, the number of battles W14 that have been performed in this battle group in the past, and this battle group was established. The operation start time as time and the operation duration W15 as elapsed time are displayed. In the chat window W2, a character string W21 based on chat information and a software keyboard W22 are displayed. In this window, only members who are participating in this battle group can read and write chat information.

  The member list W8 displays a list of members with classes. Whether each client system 1 is fighting, watching a game, or referring to a lobby is indicated by color coding or the like. At the beginning of the player who created this battle group, an icon indicating that it is a host is attached.

  In the game rule window W9, the game rules determined by the host in S13 are displayed. In “First Battle”, the name of the player who is scheduled to fight first is displayed. In the “battle format”, the actual battle mode considering the class or the simulated battle mode not considering the class is displayed. When the actual battle mode is set, the number of seconds, the number of sets, and the stage are set to fixed values, and the battle result is reflected in the class change. In “seconds”, a time length allocated to one battle is displayed. In “Number of sets”, the number of set matches of one battle is displayed. In “Stage”, a game stage used for the battle is displayed. “Change at end” displays a rule on how to determine the next combination when the battle ends.

  Depending on the setting of “change at end”, the order of the battle will change greatly, and the characteristics of this battle group can be obtained. When this is “fixed”, the battle is repeated between the client systems as in the first combination. When “DNA fixation” is selected, the client system on the RNA side will change regardless of the result of the match. When “RNA fixation” is selected, the client system on the DNA side will change regardless of the result of the match. If it is “winning”, the client system that won the battle will be replaced with other client systems. If it is “defeated”, the client system that lost the match will be replaced by another client system. By default, this “defeat” is set.

  In the state S30, when the player moves the cursor to any member displayed in the member list W8, the game server 20 reads personal information corresponding to the member from the user DB and displays it in the player data window W7. (S33: FIG. 17). This window is the same as the player data window in FIG.

  In the state S30, a start menu similar to that shown in FIG. 11 is displayed only when the player of the client system 1 as a host presses the start button of the control pad 11. However, the difference is that items “start game” and “change game rule” are added to the start menu M1.

  Only the client system 1 as a host is authorized to change the game rules. When the host player selects “change game rule”, the game server 20 moves to the game rule change state (S32) and causes the client system 1 of the host to display a game rule change window W10 as shown in FIG. . Here, a window for changing “first battle DNA” is illustrated. When the player operates according to the message from the control pad 11, the game server 20 changes the combination of “first battle” corresponding to the operation, and updates the normal DB 213. The opponent member is changed to the one selected by the player from the member list W8 with the cursor. The battle type, number of seconds, number of sets, stage, change values at the end and rules are also determined by selection.

  When the player of the host client system 1 selects “start of game” in the start menu, the game server 20 moves each client system 1 to the battle mode (S34).

  Detailed operations in the normal battle mode will be described with reference to FIG.

  The game server 20 transmits a command for shifting to the battle mode to the client system 1 set to the combination of “first battle”, and transmits a command for shifting to the watching mode to the other client systems 1 (S100).

  Next, the game server 20 causes the client system 1 entering the battle mode to designate a character to be displayed in the battle (S101). For example, the character is selected from a plurality of candidates. If the player designates a specific key operation such as an escape key when setting the communication character (S102: YES), it is possible to escape from the permanent loop and return to the expert lobby.

  When the setting of the communication character is completed (S103: YES), the game server transmits a command for starting a battle to the client system 1 set to the first combination (S104).

  In the client system 1 that enters the battle mode by this command, the game machine body 10 displays a game battle image, moves its character in response to an operation signal from the control pad 11, and uses the battle data (operation command). ) Is transmitted to the game network 40. When an enemy character operation command is transmitted from the game network 40, processing is performed to move the enemy character in response to the operation command. The game server 20 mediates transmission / reception of this operation command.

  In the client system 1 that enters the watching mode, the same game screen as the client system 1 that enters the fighting mode is displayed based on the operation command transmitted from the client system 1 that enters the fighting mode. However, although the fighting character is displayed on the game screen in the client system 1 in the watching mode, even if the player operates the control pad 11, it is not reflected in the movement of the character. The battle process is continued until the battle in the combination is completed (S105: NO).

  During the battle, the game server 20 refers to the user DB 210, reads out message information assigned to the operation indicated by the operation command registered in the state S14, and transmits it to each client system 1. Further, when chat information input by operating a software keyboard is transmitted from any of the client systems 1 in the watching mode during the match, the game server 20 transmits the chat information to each client system 1. To do. Each client system 1 displays a quick message or a chat character string registered at a predetermined position on the battle game screen displayed in each client system (FIG. 8: S519).

  When the operation command transmitted from any one of the client systems 1 is a specific command that beats an enemy character, the game server 20 transmits a command for generating a vibration to each client system 1. When each client system 1 receives this vibration generating command, it causes the vibration generating means 111 to generate the vibration (FIG. 8: S520). Thereby, the player who is operating and the member who is watching the game can get a sense of reality like a real battle.

  When the battle is over (S105: YES), the game server 20 reads information defining the game rules from the normal DB 213 (S107) unless all the battles are over (S106: NO).

  When the game rule (change at the end) is set to “fixed” (S108: YES), the battle with the same member is repeated. The game server 20 inquires of the client system 1 in the battle mode, such as “Do you fight with the same setting?”. Only when both client systems 1 accept this inquiry (S109: YES), the battle is repeated again with the same combination (S104 to S108). When at least one of them does not accept (S109: NO), the process proceeds to communication character setting (S101). Here, when the player performs a specific key operation, the game server 20 returns the client system 1 to the operation conference room (state S30).

  When the game rule is set to other than “fixed” (S107: NO), as long as the client system 1 that remains in the game rule accepts the game continuation inquiry from the game server 20 (S110). : YES), the battle process by the new combination is repeated (S104 to S110). The game server 20 shifts the client system 1 that will miss the game to the watching mode, and shifts the next client system 1 to the battle mode (S111).

  For example, if the game rule is “DNA fixation”, the game server 20 shifts the client system that was on the RNA side to the watching mode, and shifts any client system that was in the watching mode to the battle mode. When the game rule is “RNA fixed”, the game server 20 shifts the client system that was on the DNA side to the watching mode, and shifts any client system that was in the watching mode to the battle mode. When the game rule is “winning”, the game server 20 shifts the winning client system to the watching mode, and shifts any client system that was in the watching mode to the battle mode. If the game rule is “defeated”, the game server 20 shifts the losing client system to the watching mode, and shifts any client system that was in the watching mode to the battle mode. By default, this “defeat” is set.

  If the client system 1 that is to remain is refused to continue the battle (S110: NO), the game server 20 moves each client system 1 to the operation conference room (S30). Further, when the client system 1 as the next opponent returns to the strategy meeting room with the communication character setting, the game server 20 further shifts the next client system 1 to the battle mode.

  When the battle by the last combination is completed (S105: YES), since all the battles are completed (S106: YES), the game server 20 returns all the client systems 1 to the operation conference room (state S30).

  At that time, the game server 20 performs class determination. That is, when the battle type of the game is set to “actual battle”, the game server 20 determines the rank of the member of the battle group based on the battle result. For example, it is determined such that one rank of the client system 1 that has reached a predetermined number of wins is increased, and one rank of the client system 1 that has reached a predetermined losing number is decreased. Also, if there is a client system that has not been connected to the game network for a certain period, the rank is lowered by one. The game server 20 updates the battle history information in the personal information of the client system 1 whose class has been changed.

  When the class is changed, the game server 20 displays a window informing that the class has been changed in a display format such as “decision” in the operation conference room. Further, when there is a class change, the game server 20 creates a file for displaying this battle history based on the battle history information of the user DB 210 and transfers it to the storage area of the WWW server system. That is, the game server 20 creates a hypertext format file for displaying the battle history, connects to the Internet, and transfers the file to the HTML storage area 31 of the WWW server 30 using an ftp command or the like. As a result, the battle history is stored in a state that can be viewed on the computer. The file for displaying the battle history is preferably set so that the game server 20 periodically searches the user DB 210 to create and transfer the file.

  As described above, the first embodiment has the following advantages.

  1) According to the present embodiment, a simple easy lobby and an expert lobby for experts are provided to be arbitrarily selectable, so that an appropriate game environment can be provided for both beginners and experts.

  2) According to this embodiment, since it is set to start from a simple easy lobby, it is possible to prevent a person without knowledge from suddenly entering the expert lobby and being confused or annoying others. is there.

  3) According to the present embodiment, since the necessary menu is selected from the start menu, the operation is simple and easy to get familiar with.

  4) According to the present embodiment, since the comment of self-introduction is set for each player and displayed on the opponent's system, other players can easily know the personality of the player. it can.

  5) According to the present embodiment, since a quick message such as a shout to be displayed during operation is displayed on another system corresponding to the operation button, there is no need to put a burden on the player being operated. You can communicate with other sensual people.

  6) According to the present embodiment, since the battle group can be set according to an arbitrary rule in the form of a conference room, it is possible to provide the player with various ways of playing mainly by the player and many options. .

  7) According to this embodiment, since the situation of the battle group is displayed in a list, others can easily grasp the current situation of the battle group.

  8) According to the present embodiment, since the battle history of each player is displayed together with the number of wins, winning percentage, etc., the strength of each member can be grasped easily.

  9) According to this embodiment, since chatting between players can be performed freely, communication between players can be deepened.

  10) According to the present embodiment, since chat channels are provided in a plurality of layers, it is possible to enjoy various chats from general chats to chats between specific persons.

  11) According to the present embodiment, since it is possible for other people who compete in the battle group to watch both games, they can play or watch a battle game with friends at the amusement center. Like, it can provide a fun game environment.

  12) According to the present embodiment, a chat can be sent to a person who is watching a game, so that it is possible to provide a fun game environment as if watching a battle game between friends at an amusement center. .

  13) According to the present embodiment, since a new battle combination can be executed in various forms, it is possible to set a way of proceeding a fun game suitable for the user.

14) According to the present embodiment, since a message can be transmitted to any of the connected persons without being limited to the battle group to which the player belongs, an enjoyable communication environment can be provided.
(Embodiment 2)
Embodiment 2 of the present invention relates to a communication game system for conducting a team battle in a battle group.

  The system configuration, hardware configuration, overall processing procedure, and operation in each client system in the second embodiment are the same as those in FIGS. 1 to 3 and FIG. To do.

  The “team battle” in the present embodiment refers to a battle mode in which the same group is divided into two subgroups to compete for victory or defeat. Client systems selected from both of the subgroups compete against each other, and as a result of the competition, the losing client system replaces the other client systems in the same subgroup and fights with the winning client system.

  The “team battle strategy conference room” (team battle group) is created when the host client system 1 selects “team battle” in the menu M2 in the state S12 (FIG. 12) in FIG. The client system 1 creating the “team war strategy conference room” determines the battle type, the number of seconds, the number of sets, and the number of stages in the same manner as in the first embodiment in creating the conference room in the state S13. In particular, the client system 1 that creates this conference room divides the battle group into two subgroups, the DNA side and the RNA side, as shown in FIG. 19, and creates a battle schedule in which the order of battle is determined. There is a need.

  Now, in the expert lobby strategy menu (FIG. 10), the player of the client system 1 who wants to participate in the “team fight” moves the cursor over the strategy meeting room icon of the strategy name list W3 in which the battle mode is “team fight”. Take. The game server 20 searches the expert lobby DB 212 based on the strategy name information, identifies the team battle DB 214 in which the corresponding “team battle” battle group is stored, reads the detailed information, and reads the client system 1. Return to

  When a predetermined operation (for example, pressing the “A” button) is performed by the player in the battle status report window W5 (state S20), the game server 20 receives a request to participate in the selected battle group from the client system 1. The client system 1 is registered as a new participant in this battle group (S40). That is, the team battle DB 214 is updated by newly associating the personal information of the client system 1 that wishes to participate in the group information of the battle group.

  FIG. 19 shows a screen display example provided to the client system 1 participating in the “team battle” battle mode. This “strategy conference room” is provided only to the person (host) who started the battle group or to those who participated in it. The game server 20 performs each display by reading the corresponding record from the team battle DB 214.

  The title window W1 shows the “team battle” which is the battle mode. Below that, a status display indicating whether or not a battle is in progress, a strategy name that is the name of this battle group, and the number of participants are displayed. The chat window W2, member list W8, and game rule window W9 are the same as in FIG. However, in the game rule window W9, since the game rule is that the members of the subgroup to which the losing client system 1 belongs change, there is no setting for “change at end”. In the battle schedule window W11, members of two subgroups are displayed in order of battle in the name column W111, divided into the DNA side and the RNA side. In the win number display column W112, the number of wins for each member of the team battle is indicated by a marker. The combination display W113 displays what kind of combination the match has been played. In the results display W114, the number of wins, the number of losses and the number of draws for each sub-team are displayed.

  In the state S40, when the player moves the cursor over any member displayed in the member list W8, the game server 20 reads the personal information corresponding to the member from the user DB and displays it in the player data window W7. (S43: FIG. 20). This window is the same as the player data window in FIG. In the state S40, a start menu similar to that shown in FIG. 11 is displayed only when the player of the client system 1 as a host presses the start button of the control pad 11 (S41). However, the difference is that items “start game” and “change team battle schedule” are added to the start menu M1.

  Only the client system 1 as a host is authorized to change the game rules. When the host player selects “change team battle schedule”, the game server 20 moves to a schedule change state (S42), and the team battle battle schedule change window W12 as shown in FIG. Is displayed. In this window, the member selected by the host client system 1 from the member list W8 can be registered and changed in any order in any subgroup. The battle type, number of seconds, number of sets, stage values and rules are also determined by selection.

  When the player of the host client system 1 selects “start of game” in the start menu, the game server 20 moves each client system 1 to the battle mode (S44).

  Detailed operations in the team battle mode will be described with reference to FIG.

  The game server 20 transmits a command to shift to the battle mode to the client system 1 set to the first combination in the battle schedule, and transmits a command to shift to the watching mode to the other client systems 1 (S200). If there is a client system 1 that has joined the conference room later, the game server 20 causes the system to participate in the team battle in the watching mode.

  The game server 20 causes the client system 1 entering the battle mode to designate a character to be displayed in the battle (S201). For example, the character is selected from a plurality of candidates. If the player designates a specific key operation such as an escape key when setting a communication character (S202: YES), it is possible to escape from the permanent loop and return to the expert lobby.

  When the setting of the communication character is completed (S203: YES), the game server transmits a command for starting a battle to the client system 1 set to the first combination (S204). The operations of the client systems 1 and the game server 20 in the battle mode and the watching mode are the same as those in the first embodiment.

  The battle process is continued until the battle in the first combination is completed (S205: NO). When the battle is over (S205: YES), the team battle is continued unless the person whose rank is set to “General” is defeated in any subgroup (S206: NO). That is, the game server 20 shifts the losing client system to the watching mode, and instead shifts the client systems set in the next order in the subgroup to which this client system belongs to the battle mode (S207). The line of the combination display W113 is drawn between the name of the new client system and the name of the client system that has won. Further, the number of markers is increased in the winning number display W112 of the remaining client system. Then, the processing after setting the communication character (S201 to S207) is repeated.

  When the “general” of any subgroup loses (S206: YES), the game server 20 notifies each client system 1 of the result of the team battle (S208). The game server 20 updates the result display W114 in the subgroup according to the battle result.

  The class determination is performed by the game server 20 before and after the battle result display, as in the first embodiment. The battle history is uploaded to the WWW server in the same manner as in the first embodiment.

As described above, according to the second embodiment, in addition to the same effects as the first embodiment, since it is configured to be able to execute a team battle, it is possible to provide a unique way of playing in which remote players fight with each other as a team It is.
(Embodiment 3)
Embodiment 3 of the present invention relates to a communication game system for performing a round-robin battle in a battle group. Since the system configuration, hardware configuration, overall processing procedure, and operation in each client system in the third embodiment are the same as those in FIGS. 1 to 3 and FIG. 8 and the corresponding description in the first embodiment, the description thereof is omitted. To do.

  The “round-robin battle” in the present embodiment refers to a battle mode in which one client system battles with all other client systems in the same group. When a battle by one combination is completed, a client system that is not yet in a battle with each client system and that is not in a battle is determined as a next battle combination for each client system.

  The “brute force battle conference room” (brute force battle battle group) is created when the client system 1 serving as the host selects “brute force battle” in the menu M2 in the state S12 (FIG. 12) of FIG. The The client system 1 that creates the “brute force strategy conference room” determines the battle type, the number of seconds, the number of sets, and the number of stages in the same manner as in the first embodiment in creating the conference room in the state S13. In particular, in this conference room, the game server 20 causes a plurality of combinations of client systems 1 to perform a battle at the same time. Therefore, the host client system 1 selects members who participate in the brute force battle from the battle group. Register with.

  In the expert lobby strategy menu (FIG. 10), the player of the client system 1 who wants to participate in the “round-robin battle” cursors over the strategy meeting room icon in the strategy name list W3 in which the battle mode is “round-robin battle”. Take it. The game server 20 searches the expert lobby DB 212 based on the strategy name information, identifies the brute force DB 215 in which the corresponding “brute force battle” battle group is stored, reads the detailed information, and the client Return to system 1. When a predetermined operation (for example, pressing the “A” button) is performed by the player in the battle status report window W5 (state S20), the game server 20 receives a request to participate in the selected battle group from the client system 1. The client system 1 is registered as a new participant in this battle group (S50). That is, the round-robin battle DB 215 is updated by newly associating the personal information of the client system 1 that wishes to participate in the group information of the battle group.

  FIG. 23 shows a screen display example provided to the client system 1 participating in the “round-robin battle” battle mode. This “strategy conference room” is provided only to the person (host) who started the battle group or to those who participated in it. The game server 20 performs each display by reading the corresponding record from the round-robin battle DB 215.

  The title window W1 shows "round-robin battle" which is this battle mode. Below that, a status display indicating whether or not a battle is in progress, a strategy name that is the name of this battle group, and the number of participants are displayed. The chat window W2, member list W8, and game rule window W9 are the same as in FIG. However, since the round robin is a game rule in the game rule window W9, there is no setting for “change at end”. In the participating member window W12, a list of battle participating members assigned by the client system 1 of the host is displayed. In the beginning W131 of the participating member window W13, the number of battle participants in the brute force battle, the battle start time, the battle end time, and the like are displayed. The name column W132 displays the names of the members participating in the battle. The number of wins for each member up to the present is displayed in the number-of-wins column W133. The grade column W134 is marked with a star from the top to a certain rank for the participating members with excellent grades.

  The player data window can be displayed in the same manner as in the first and second embodiments.

  In the state S50, only when the player of the client system 1 as a host presses the start button of the control pad 11, a start menu similar to that shown in FIG. 11 is displayed (S51). However, the difference is that items of “start of game” and “registration of brute force participation members” are added to the start menu M1.

  Only the client system 1 as a host is authorized to change the game rules. When the host player selects “registration of brute force participation member”, the game server 20 moves to the participation member registration state (S52) and enters the brute force participation member as shown in FIG. A registration window W13 is displayed. In this window, the member selected by the host client system 1 from the member list W8 can be registered and changed in any column of the brute force battle participation member list. The battle type, number of seconds, number of sets, stage values and rules are also determined by selection.

  When the player of the host client system 1 selects “start game” in the start menu, the game server 20 moves each client system 1 to the battle mode (S54).

  A detailed operation in the round-robin battle mode will be described with reference to FIG.

  The game server 20 appropriately divides the members registered as battle participating members into a plurality of groups and transmits a command for causing the client system 1 to shift to the battle mode (S300). The game server 20 transmits a command for shifting to the watching mode to the client system 1 and the other client systems 1 that have an odd number of participating members and are omitted from the first battle. If there is a client system 1 that has joined the conference room later, the game server 20 causes the system to participate in the round-robin battle in the watching mode.

  The game server 20 causes the client system 1 entering the battle mode to designate a character to be displayed in the battle (S301). For example, the character is selected from a plurality of candidates. If the player designates a specific key operation such as an escape key when setting a communication character (S302: YES), it is possible to escape from the permanent loop and return to the expert lobby.

  When the setting of the communication character is completed (S303: YES), the game server transmits a command for starting a battle to the client system 1 assigned to the first battle combination (S304). The operations of the client systems 1 and the game server 20 in the battle mode and the watching mode are the same as those in the first embodiment.

  The battle process is continued until the battle in the first combination is completed (S305: NO). When the battle is over (S305: YES), the round-robin battle is continued unless all the battles are over (S306: NO). That is, after the game server 20 records the results of the first match in the number-of-wins field W133 and the result field W134, the game server 20 matches each client system 1 with the unmatched participating members without considering the victory or defeat of the first match. Let There is no limitation on how to determine the combination. Although it may be divided in the order of the participation list, it is preferable that the combination is decided from those who have finished the battle first, and the next battle is started without waiting for the completion of the battle of the other group because the time loss is small. When the client system 1 that has already played against all the other participating members has appeared, the game server 20 transmits a command for shifting to the watching mode (S307). The number of wins and results will be updated each time the match ends.

  When the round robin has ended for all the battle participating members (S306: YES), the game server 20 informs each client system 1 of the result of the round robin battle (S308). The game server 20 displays the winning and losing of the members participating in the battle in the format of a winning star chart W15 as shown in FIG.

  The class determination is performed by the game server 20 before and after the battle result display, as in the first embodiment. The battle history is uploaded to the WWW server in the same manner as in the first embodiment.

As described above, according to the third embodiment, the same effects as those of the first embodiment are achieved, and the round-robin battle can be executed. It is possible to provide a unique way of playing such as competing for superiority and inferiority.
(Embodiment 4)
Embodiment 4 of the present invention relates to a communication game system for conducting a tournament battle in a battle group. Since the system configuration, hardware configuration, overall processing procedure, and operation in each client system in the fourth embodiment are the same as those in FIGS. 1 to 3 and FIG. 8 and the corresponding description in the first embodiment, description thereof is omitted. To do.

  The “tournament battle” of the present embodiment is a battle mode in which a battle is played in a so-called winning game format within the same group. A combination in which the game server 20 battles with reference to the tournament group information in advance is set, and a client system that starts the battle by this combination from the lower layer and becomes the winner of the battle is determined as the next battle combination. And ultimately determine the winner of one.

  The “tournament battle battle conference room” (tournament battle battle group) is created when the host client system 1 selects “tournament battle” in the menu M2 in the state S12 (FIG. 12) of FIG. The client system 1 creating the “tournament strategy conference room” determines the battle type, the number of seconds, the number of sets, and the number of stages in the same manner as in the first embodiment in creating the conference room in the state S13. In particular, in this meeting room, the host client system 1 sets a combination of tournaments among the participating members participating in the tournament battle.

  In the expert lobby strategy menu (FIG. 10), the player of the client system 1 who wants to participate in the “tournament battle” has a cursor on the strategy meeting room icon of the strategy name list W3 in which the battle mode is “tournament battle”. To go. The game server 20 searches the expert lobby DB 212 based on the strategy name information, identifies the tournament battle DB 216 in which the corresponding “tournament battle” battle group is stored, reads the detailed information, and reads the client system 1. Return to When a predetermined operation (for example, pressing the “A” button) is performed by the player in the battle status report window W5 (state S20), the game server 20 receives a request to participate in the selected battle group from the client system 1. The client system 1 is registered as a new participant in this battle group (S60). That is, the tournament battle DB 216 is updated by newly associating the personal information of the client system 1 that wishes to participate in the group information of the battle group.

  FIG. 25 shows a screen display example provided to the client system 1 participating in the “tournament battle” battle mode. This “strategy conference room” is provided only to the person (host) who started the battle group or to those who participated in it. The game server 20 performs each display by reading the corresponding record from the tournament battle DB 216.

  The title window W1 shows the “tournament battle” which is the battle mode. Below that, a status display indicating whether or not a battle is in progress, a strategy name that is the name of this battle group, and the number of participants are displayed. The chat window W2, member list W8, and game rule window W9 are the same as in FIG. However, since the tournament is a game rule in the game rule window W9, there is no setting for “change at end”. In the battle schedule window W16, a tournament combination table of battle participating members determined by the host client system 1 is displayed. In the beginning W161 of the battle schedule window W16, the number of players participating in the tournament battle, the battle start time, the battle end time, and the like are displayed. The name column W163 displays the names of the members participating in the battle. In the combination display field W162, combinations of battle participating members are displayed in a diagram form. The route of the remaining participating members is displayed with a continuous thick line or color coding.

  The player data window can be displayed in the same manner as in the first and second embodiments. In the state S60, a start menu similar to that shown in FIG. 11 is displayed only when the player of the client system 1 as a host presses the start button of the control pad 11 (S61). However, the difference is that items of “start of game” and “registration of members participating in tournament game” are added to the start menu M1.

  Only the client system 1 as a host is authorized to change the game rules. When the player of the host selects “Register Tournament Battle Participant”, the game server 20 moves to the participation member registration state (S62) and enters the tournament battle participation member registration window as shown in FIG. W17 is displayed. In this window, the member selected by the host client system 1 from the member list W8 can be registered and changed in any name column W163 of the battle schedule window W16 of the tournament battle. The battle type, number of seconds, number of sets, stage values and rules are also determined by selection.

  When the player of the host client system 1 selects “start of game” in the start menu, the game server 20 moves each client system 1 to the battle mode (S64).

  Detailed operations in the tournament battle mode will be described with reference to FIG.

  The game server 20 transmits a command for shifting to the battle mode to the client system 1 of the battle participating member who is to fight in the first combination of the tournament battle (S400). The game server 20 transmits a command to shift to the watching mode to the client system 1 of the opponent members who have not participated in the battle. If there is a client system 1 that has joined the conference room later, the game server 20 causes the system to participate in the tournament battle in the watching mode.

  The game server 20 causes the client system 1 entering the battle mode to designate a character to be displayed in the battle (S401). For example, the character is selected from a plurality of candidates. When the player designates a specific key operation such as an escape key when setting a communication character (S402: YES), it is possible to escape from the permanent loop and return to the expert lobby.

  When the setting of the communication character is completed (S403: YES), the game server transmits a command for starting a battle between the client systems 1 of the first round combination according to the combination of the tournament battle (S404). The operations of the client systems 1 and the game server 20 in the battle mode and the watching mode are the same as those in the first embodiment.

  The battle process is continued until the first round is over (S405: NO). When the round is over (S405: YES), unless the final is over (S406: NO), the next winning match is entered. In other words, the game server 20 displays the route in a specific display manner up to the position of the second round of the client system 1 that has won the first round. The game server 20 transmits a command to shift to the battle mode so that those who have won in the first round in the second round face each other, and sends a command to shift to the watching mode to the client system broken in the first round. (S407). Such processing (S401 to S407) is repeated until the final game is completed.

  When the final game is over (S406: YES), the game server 20 notifies each client system 1 of the result of the tournament game (S408). That is, the game server 20 performs display on the tournament strategy conference room (FIG. 25) so as to honor the winner and the runner-up.

  The class determination is performed by the game server 20 before and after the battle result display, as in the first embodiment. Especially for the winner and the runner-up, the degree of advancement of the class may be increased. The battle history is uploaded to the WWW server in the same manner as in the first embodiment.

As described above, according to the fourth embodiment, in addition to the same effects as the first embodiment, the tournament battle can be executed, so that the remote players can compete with each other for new strong players. Can be provided.
(Modifications related to Embodiments 1 to 4)
The present invention can be applied in various modifications without being restricted by the above-described embodiment. For example, in the above embodiment, a typical sports battle format such as normal, team battle, round-robin battle, or tournament battle is applied, but other battle formats may be applicable.

  Moreover, although the participating member was defined from the battle group in the said embodiment, you may provide the battle by the battle mode of this invention with respect to all the connection persons. The battle environment of the present invention is provided to the client server that is connected at the time when the game server is called and has applied for participation. Particularly in team battles, a battle between specific categories, such as an east-west battle, is possible. In tournament battles, national tournaments can be held, which is preferable.

  Further, in the above embodiment, when determining the combination of battles in the battle group, no judgment is made based on the class, but it is determined whether the combination is possible or not according to the degree of strength determined from the battle history information of each client system. You may comprise. In other words, it is conceivable that the game server prohibits the battle because it is clear that the players who are too far apart from each other play a battle.

  When determining a battle combination in the battle group, a handicap may be set for each client system based on the battle history information. In this way, fairness can be maintained because it is possible to play with equal power relationships. In the case of a battle in a combination in which a handicap is set, it may be configured to prohibit a class change due to the battle result as in the simulated battle.

  Further, the processing for generating vibration is performed by the client system based on a command from the game server. However, if the client system is in a predetermined operation condition, it may be configured to independently drive the vibration generating means. The effect is obtained.

  That is, the configuration of the database and the role sharing between the game server system and the client system can be easily changed in design according to the system, and is not limited to the above embodiment.

(Embodiment 5)
Next, Embodiment 5 according to the present invention will be described with reference to FIGS.

  The communication game system according to this embodiment is characterized by a character selection process, and the configuration of this selection process is applicable to the above-described first to fourth embodiments.

  Note that the system configuration and the overall processing procedure in the fifth embodiment are substantially the same as those in the above-described embodiments, so that the description thereof will be omitted and the differences will be mainly described. The main difference is character selection processing in each client system.

  In order to execute this character selection process, each client system 1 according to the present embodiment includes a control pad 11 shown in FIG.

  The control pad 11 has a configuration as a manual operation device operated by each player, and includes an operation button group 301, a cross key 302, an analog direction key 303, an R trigger switch 304, and the like as an operation unit. The connection cord 305 provided with can be connected to the game machine main body 11.

  Among these, for example, the quick message described in the first embodiment is assigned to each button of the operation button group 301, for example. Therefore, the player can send the data of the quick message assigned to the button to the game machine main body 11 only by operating the desired button of the operation button group 301 with one touch during the game. The quick message is transmitted via the game network 40 to the client system of the opponent or the spectator, and is displayed superimposed on the game screen of those monitors 12.

  The control pad 11 is configured to output pad data to the game machine body 10 in the format shown in FIG. 28 when the above-described various operation units (301 to 304, etc.) are operated. That is, it consists of all 16-bit pad data, and 0 to 13 bits are assigned to the operation state of the operation unit such as a pad or a stick. The 14 bits indicate whether the device used is a twin stick or a pad. The last 15 bits are assigned to a bit for notifying the end of the custom selection mode when selecting a character, which will be described later. Normally, 15 bits = 0, and when notifying the end of the custom selection mode, 15 bits = 1 is set.

  Further, a portable card memory 306 as an external recording medium can be detachably attached to the control pad 11. Two connection ports PT of the card memory 306 are prepared in one control pad 11 although not shown in FIG. Further, as shown in FIG. 27, the game machine body 11 is provided with four ports A to D for connecting the control pad 11. Therefore, a maximum of four control pads 11 can be connected to the game machine main body 11, and at the time, a maximum of eight memory cards 306 can be operated.

  In this embodiment, the memory card 306 is used to store (custom-made) character data customized at the time of character selection to be described later. A customized character is a character that a player has prepared as a default in each client system 1 without changing the shape of the part and changing the color and brightness of the part according to preference. . That is, each client system 1 can have a maximum of 8 memory cards, that is, 8 customized character data.

  By connecting the memory card 306 to the port of the control pad 11, the game machine body 10 reads out the customized character data from the memory card 306, loads it into the RAM of its own system, and sets up the game network 40. To the client system 1 of the other party.

  Note that the memory card 306 may load customized character data into the game machine main body 10 using another recording medium such as a CD-ROM.

  29 to 31 are processes executed in each client system 1 and correspond to FIG. 8 in the above-described first embodiment.

  Specifically, as shown in FIGS. 29 and 30, the game machine body 10 of each client system 1 reads the operation signal (S599) and checks whether the operation content indicates the start of communication (S600). . If the communication is not started (S600: NO), it is an independent mode, and the processing as a normal stand-alone game device is continued (S601).

  On the other hand, when the communication start is indicated (S600: YES), the game machine body 10 executes a general procedure for establishing a connection in order to perform communication in the synchronous mode. That is, the game machine body 10 selects and calls a pre-registered server, and transmits necessary information such as a handle name, ID, and password after connection (S602). If the connection cannot be established, the processing apparatus displays that fact and returns.

  After the connection is established, the game machine body 10 displays a main menu (S603), further reads a transmission command from the game network 40, and interprets it based on a predetermined command rule. (S604, 605).

  Thereafter, when the command indicates an easy lobby (simple battle mode) operation window display (S606: YES), the game machine body 10 displays a basic screen (see FIG. 9 described above) called an easy lobby operation window. (S607). Further, the game machine body 10 performs character selection as described later (S608: see FIG. 31).

  Similarly, when the command indicates an expert lobby (expert battle mode) operation window display (S609: YES), the game machine body 10 displays a basic screen called an expert lobby operation window (S610). Further, the game machine body 10 performs character selection as described later (S611: see FIG. 31).

  The expert lobby strategy window here includes various window displays (FIGS. 11 to 26 described above) in addition to the basic screen (see FIG. 10 and the like described above). These basic screens are displayed based on image data stored in the client system. However, the hypertext format file for displaying these operation windows is stored in the game server system 2, and this file is provided to the client system in a timely manner and displayed based on the function of the browser for browsing hypertext. It may be configured.

  If the command indicates transition to the battle mode (S612: YES), the game machine body 10 executes a battle process based on image data in the client system instead of these screen displays ( S613).

  Subsequently, when an operation signal is supplied from the control pad 11 (S614: YES), the game machine body 10 reads the operation signal (S615), converts it into a command according to a predetermined command protocol, and sends it to the game network 40. It is sent out (S616).

  Further, when the read operation signal includes information of a quick message output by operating the operation button of the control pad 11 with one touch, the game machine body 10 converts the information into a command and converts it to the game network 40. To the game server system 2 (S617). This quick message is notified to all the client systems 1 of the opponent and the spectator by the game server system 2.

  Furthermore, when the operation signal includes information on the viewpoint change for the client system 1 that is observing, the game machine body 10 changes the viewpoint of the virtual camera in the game space according to the information, and the position The self-system commands the imaging processing of the game space projected from (S618). That is, the change of the camera viewpoint functions effectively only in the client system 1 that is watching the game.

  When a command is transmitted from the game network 40 (S619: YES), the game machine body 10 reads this and interprets it based on the command convention (S620).

  Next, when chat information is sent as a command, the game machine body 10 displays character information on the screen of the monitor 12 based on the chat information (S621). In the present embodiment, the chat information is communicated to all the client systems 1 that are watching the game, but the chat information may be exchanged between the specific client systems 1 that are watching the game. Good. In addition, even if the client system 1 in a battle | competition receives this information, this will be discarded, and it is keeping the opponent's feeling from being distracted by chat information.

  When a command to vibrate is sent as a command, the game machine body performs a process of vibrating the vibration generating means 111 of the control pad 11 (S622).

  The game machine body 10 executes an endless loop process that does not return unless a special operation such as escape is performed around steps S604 to S622.

  Next, the character selection routine described above will be described with reference to FIG.

  The game machine body 10 displays the normal character selection screen GM1 for the normal selection mode (first selection mode) as an initial screen in order to allow the player to select his / her character (S701: FIG. 32). Since this screen display is performed between both client systems 1 in which a battle is organized, both players will initially see a common screen GM1 regarding character selection. Both players specify a desired character while selecting a character button on the screen to be described later while viewing this screen GM1.

  As shown in FIG. 32, the normal character selection screen GM1 is hung from the vicinity of the center to the upper side, and is stored in the game machine main body 10 or the game server system 2 as a default in advance for the normal mode (hereinafter referred to as “normal character”). Button B1 to B11 for selecting a character), a button for selecting a character for a random mode: “Random” B12, and two buttons for selecting a character for a custom mode: “Custom” B13 and “custom load” B14. In this normal character selection screen GM1, a window for displaying necessary game information is set in addition to message windows M1 and M2 for displaying a message from the user and a message from the opponent.

  The normal character selection screen GM1 is used not only for selecting a normal character, but also serves as a button screen for selecting a character in a random mode and a custom mode.

  Buttons B1 to B11 are buttons specified in the normal mode. These buttons are character selection buttons that are set in advance as defaults and are common to all client systems 1, and can be designated by simply selecting one of the buttons with a cursor as will be described later. Here, a desired character can be selected from 11 types of characters (a battle game machine).

  The button B12 (“Random”) is a button designated in the random mode. When this button B12 is designated, a character is automatically prepared on the CPU side of the game machine body 10 of the client system 1.

  Further, the two buttons B13 and B14 (“custom” and “custom load”) are buttons that are selectively designated in the custom mode. If any of these buttons is designated while character data is not yet loaded, the procedure for loading customized character data from the memory card 306 mounted on the control pad 11 is entered. .

  Next, the game machine body 10 calculates the positions of the 1P cursor (own character selection cursor) and the 2P cursor (other character selection cursor) currently placed on the normal character selection screen MG1 (S702). This cursor position is generated as the above-described pad data, and is sent to the other party via the game server system 2. The cursor position can be arbitrarily changed by operating the control pad 11. The user's 1P cursor is displayed as it is on the normal character selection screen MG1, for example, as a green frame around the buttons B1 to B14. The data of the opponent's 2P cursor is sent via the game network 40, and is displayed around the buttons B1 to B14 as, for example, a red frame on his normal character selection screen MG1.

  In the state of the normal character selection screen MG1 illustrated in FIG. 32, the user's 1P cursor is placed on the “custom load” of the button B14, while the partner's 2P cursor is placed on the button B3.

  Therefore, the game machine body 10 determines whether “custom load” or “custom” for the first time is designated based on the position on the screen indicated by its own 1P cursor (S703).

  If it is determined that “custom load” or “custom” for the first time is designated, the custom data selection screen GM2 is displayed (S704: see FIG. 32). As illustrated in FIG. 33, the custom data selection screen GM2 includes windows A1, A2, B1,... Imitating the symbols of the four ports AD of the game machine body 10 and the memory card 306 belonging to each port. , D1 and D2. In addition, the window indicating the location where the memory card 306 is actually mounted is displayed with increased brightness (indicated by hatching in FIG. 33). In this case, FIG. 33 shows that the memory cards 306 are respectively attached to the ports B1 and B2 of the control pad 11 connected to the port B of the game machine body 10.

  Therefore, the game machine body 10 designates a desired memory card 306 via the buttons on the control pad 11 (FIG. 31: S705). That is, in the present example, one of the memory cards 306 of the ports B1 and B2 is designated. When this designation is made, the character data is loaded from the memory card 306 at the designated port into the game machine body 10 (S706). The processing in steps S704 to S706 corresponds to custom mode processing. Thereafter, the screen is returned to the normal character selection screen GM1 (S707).

  On the other hand, if the determination in step S703 is NO, the game machine body 10 determines whether the button selection is in the “custom (button B13)” state after the “custom load (button B14)” has been performed once. (S708). In this case, since the customized desired character data is already loaded in the RAM of the game machine body 10, the custom mode processing in steps S704 to S706 is omitted.

  In other words, both “custom load (button B14)” and “custom (button B13)” are used to specify the custom mode, but in the case of “custom (button B13)”, the customized character data is already loaded. The user can easily reset the same character with one touch. However, when the customized character data is a new designation that has not yet been loaded, the custom mode processing of steps S704 to S707 is performed regardless of which of “custom load (button B14)” and “custom (button B13)” is operated. Is newly executed (S703).

  Next, in the case of NO determination in step S708, the game machine body 10 determines whether or not the selection button is “random” of B12 (S709). When it is determined that “random” is designated, an appropriate random mode process such as presenting a character automatically set by the computer is performed (S710), and the character data is stored in the VRAM of the game machine body 10. To be loaded.

  On the other hand, if NO is determined in step S708, the game machine body 10 has the selected button for the normal mode. For example, in the case of FIG. 32, it is one of the buttons B1 to B11. Therefore, the game machine body 10 determines a designated button, and executes a process (normal mode process) for loading normal character data assigned to the button into its own VRAM (S711).

  In parallel with the character selection as described above, synchronous communication with the game server system 2 is periodically performed bidirectionally via the game network 40 by the communication device 101 of the game machine body 10.

  For this reason, the cursor position information on the screen GM1 calculated in step S702 and the character data loaded in its own VRAM are transmitted to the game server system 2 via the game network 40. This character data is sent to and stored in the opponent's client system 1 and used for display of a game screen associated with the subsequent battle. On the other hand, the character data and information sent from the client system 1 of the other party to the control of the game server system 2 via the game network 40 are also periodically received by the communication device 101 of the game machine main body 10 at any time. And downloaded to the game machine body 10.

  Therefore, the game machine body 10 currently uses the character data for the custom mode (custom data) or the character for the random mode based on the cursor position on the normal character selection screen MG1 included in the received information. It is determined whether data (random data) is being selected (S721). If this determination is NO, whether or not custom data or random data has started to be selected is subsequently determined based on the cursor position information (S722). If this determination is also NO, it is understood that the normal mode is designated, so the game machine body 10 commands a screen display process in the normal mode (S723).

  In the screen display process in the normal mode, the character selected by the opponent is a normal character, so a process for aligning the position of the 2P cursor with the button corresponding to the cursor position is instructed.

  On the other hand, when “YES” is determined in the step S722, it indicates that selection of custom data or random data is started at the other party. That is, when the button “random”, “custom load”, or “custom” is designated. For this reason, the game machine body 10 commands a discarding process of the cursor position (pat data) received thereafter (S724). That is, although the pad data is read, a process of discarding the data as it is (ie, an invalidation process) is issued without being attached to the display process.

  Next, the game machine body 10 instructs display screen processing in a custom mode to replace the cursor position (pat data) used until immediately before starting the discarding process instead of the discarded pad data (S725). Therefore, while the destruction of the cursor position continues, that is, while the other party's selection process for the random mode or the custom mode continues, the assistance of the determination in step S726 described later is obtained and the normal character selection screen MG1 is displayed. The position of the displayed 2P cursor of the other party does not change.

  Further, the game machine body 10 determines whether or not the selection of custom data or random data has been completed from the above-described 15-bit binary state of the pad data (S726). When this determination is NO, it is assumed that such selection is continued, and the pad data read-out process and the custom mode display screen process are continued (S724, S725).

  However, if YES is determined in step S726, the selection of custom data or random data has been completed, so the screen display process is returned to the normal mode (S727).

  Since the character selection in this embodiment is performed as described above, not only in the normal mode, but also in the custom mode and the random mode, the character data is loaded in a natural screen state and in a state in which game characteristics are secured. can do.

  In other words, when one player who plays the game specifies those modes on the screen, the other player's screen is selected on the other player's screen by discarding (invalidating) the received cursor position, that is, the pad data. The 2P cursor shown remains fixed to a “custom load”, “custom”, or “random” button and does not move until the character selection in such a mode is complete. Thereby, the other player mentioned above can recognize that the other party selects a character in the custom mode or the random mode. At this time, the cursor does not make an unnatural movement that does not match the screen content, and a sense of incongruity does not occur. On the other hand, players who know the inside of their hands may be able to predict the opponent's selected character from the unnatural movement of the opponent's cursor, but the opponent cursor does not move in these modes, so instead, The expectation of is raised.

  In this way, it is not necessary to change the format of the transmitted / received data only for specific processing such as character selection, and data that is not desired to be displayed by the other party can be transmitted / received for real-time synchronous communication by simple invalidation processing such as discarding after receiving data Processing consistency can be maintained.

  An example of the game screen obtained through character selection in this way is schematically shown in FIGS. These game screens are gathered through the expert lobby operation window. For example, among 12 players, two players who are determined to play according to the game mode and the remaining 10 spectators (waiters) It is a screen to see.

  FIG. 34 shows an example of a game screen viewed from the monitor 12 by one of the two players who are competing. This game screen shows a game space in which the camera viewpoint is placed on the head of one character, and the characters C1 and C2 selected through the above-described character selection process face each other. The emblems EB1 and EB2 of both opponents are displayed together with their identification numbers ID1 and ID2 at positions below the left and right ends of the screen. In addition, a quick message window WDa is displayed at a lower position in the center of the screen. This quick message is sent and displayed not only to the opponent but also to all the client systems 1 that are watching the game. Since the quick message can be displayed by a simple operation, the game operation is hardly hindered and the game atmosphere can be raised. Furthermore, on this game screen, a window WDb indicating the remaining time, life gauges LG1, LG2, and the like indicating the remaining power of both characters are displayed.

  FIG. 35 shows an example of a game screen viewed from a monitor 12 by a player who is watching a game. This game screen shows a game space of another game in which the camera viewpoint is placed at an arbitrary position in the game space. The difference from the case of FIG. 34 is that a window WDc that displays the current camera viewpoint mode is displayed near the lower left of the screen, and a window WDd that displays chat information between spectators at the top of the screen. It is to be done.

  In the case of a spectator, each client system 1 can watch a game from a unique arbitrary camera viewpoint, and the camera viewpoint mode at that time is displayed.

  The chat information is displayed in the window WDd that has been subjected to the translucent process. Thus, the game screen is hardly affected, and the spectators can exchange their feelings about the current game state through this window. Therefore, a sense of unity, such as participating in the game together, is enhanced, interest in the game is further increased, and it is less likely to get tired. Since this chat information can be exchanged only by the spectators and is not displayed to the opponents, adverse effects such as the loss of concentration in the game can be prevented.

  Thus, when a certain client system 1 is assigned to the battle mode, the game machine body 10 moves its own character based on the operation signal, and also based on the operation command provided from the game network 40. Change the position and mode of the enemy character. The assignment of operation commands can be arbitrarily determined for each game. With these processes, the player can perform a game battle as if he were playing a game against another person by connecting the two control pads 11 to one game machine.

  On the other hand, when a certain client system 1 is assigned to the watching mode, the game machine body 10 moves both characters in the battle on the screen based on an operation command provided from the game network 40, and displays it. Change aspects. At this time, the game screen being watched is easily changed to a desired position and angle by the player operating the switch of his / her control pad 11 (see FIG. 35).

  By this viewpoint changing process, the player who is watching the game can easily obtain an image of the game viewed from any place in the game space. Thereby, the player can observe the progress of the game in more detail, can enjoy a greater sense of realism of the game, and can feel a sense of unity with the game. Therefore, just watching the game, there is a high interest in the game, and you will hardly get bored.

  In addition, since the client systems 1 assigned to this watching mode can chat with each other, the game is as if the player is cheering for a friend playing a game at an amusement center. You can watch the game.

  In the above-described embodiment, the display invalidation process based on the discarding of the received data has been described with respect to the character selection process. However, the present invention is not limited to this, and the game is different between both client systems. It can be applied when expressing scenes.

  In addition, in each of the above embodiments as a method for providing images and sounds to the client system, basic image data, sound data, and program data for operating them are stored in the client system, and these are received from the game server. The client system is operated by sending a command to operate.

  However, you may comprise so that an image and a sound can be provided directly from the game server side by browsing the file of a hypertext format. For example, it is preferable to browse a file only on a window screen of a strategy meeting room or the like from the viewpoint of easy information update and load distribution to the apparatus.

DESCRIPTION OF SYMBOLS 1 ... Client system 2 ... Game server system 3 ... WWW server system 4 ... Network 10 ... Game machine main body 11 ... Control pad 12 ... Monitor 20 ... Game server 21 ... Storage area (database)
30 ... WWW server 31 ... HTML storage area 40 ... Game network 41 ... Internet 100, 200 ... Processing device 101, 201 ... Communication device 102 ... Output data generation device 110 ... Operation device 111 ... Vibration generating means 210 ... User database 211 ... Easy Lobby database 212 ... Expert lobby database 213 ... Normal database 214 ... Team battle database 215 ... Round-robin battle database 216 ... Tournament battle database 306 ... Card memory

Claims (2)

A game system in which a plurality of game devices are communicably connected via a game server system and execute a battle game between the game devices,
The game server system includes:
A battle group creating means for creating a battle group for playing the battle game based on group information including rule information related to the battle game in response to a request from one of the game devices. When,
When there is a request for participation in the battle group from another game device, battle group participation permission means for permitting the other game device to participate in the battle group;
Among game devices that are allowed to participate in the battle group by the battle group participation permission means, a game device that satisfies a predetermined condition is shifted to the battle mode, and a game device that does not satisfy the predetermined condition is set to the watching mode. Battle / watch game allocation means to be transferred,
The operation input information is received from the game device that has shifted to the battle mode, and the received operation input information is transmitted to a game device other than the game device that has transmitted the operation input information among the game devices permitted to participate. Operation input information transmitting / receiving means to perform,
The chat information transmitted from the game device that has shifted to the watching mode is received, and the chat information is transmitted to a game device other than the game device that transmitted the chat information among the game devices permitted to participate. 1 chat information transmission / reception means;
A battle end judging means for judging whether or not the battle of the game apparatus that has shifted to the battle mode is finished based on the information of the rule;
With
Each of the game devices permitted to participate is
When the game mode is shifted to the battle mode, it corresponds to the game character of the battle game based on the input operation input information and the operation input information of the game device that is shifted to the battle mode transmitted from the game server system. While the game image to be updated is updated, when the mode is shifted to the watching mode, the game character corresponding to the battle game is input based on the operation input information of the game device that is transferred to the battle mode transmitted from the game server system. Game image updating means for updating the game image;
The chat information transmitted by the first chat information transmission / reception unit is received from the start of the battle until the battle end determination unit determines the end of the battle, and the first chat information transmission / reception unit receives the chat information. A second chat information transmitting / receiving means for transmitting chat information;
Chat information output means for outputting the chat information received by the second chat information transmitting means from the first chat information transmitting / receiving means in a state recognizable to a player;
Comprising
Game system. The game device discards the chat information received by the second chat information transmitting / receiving unit so as not to be output by the chat information output unit when the game apparatus is in the battle mode;
The game system according to claim 1, further comprising:

Images