JP4920838B2 - How to manage network games - Google Patents

Description

[0001]
[Industrial application fields]
The present invention relates to a game management method of a game server that provides a game to a game device of a player who has logged in through a communication network, or a game device, game server, game program, or storage medium that is applied to a game using a communication network. .
[0002]
[Prior art]
As a multiplayer RPG (Role Playing Game) using the Internet, Ultima Online provided by Electronic Arts Square is well known. In such a multiplayer RPG, a game map and player character data are prepared on a game server on the Internet, and a virtual space where the player character appears is displayed on the display of each client computer logged into the game server. It is reproduced. Another player character also appears in the virtual space, and this player character is operated by another client computer. In this way, since all the player characters appearing in the virtual space are operated by the client computer, it is possible to enjoy realistic bargaining that cannot be experienced with a stand-alone RPG.
[0003]
[Problems to be solved by the invention]
However, in the prior art, only the player character logged into the game server appears in the virtual space. For this reason, in order to play a game with a player who is not logged in to the game server, a non-real-time method such as writing on a bulletin board provided in the game is used, or a real-space contact method such as making a call is used. It had to be time-consuming to start the game. In addition, in games such as the prior art, there are many players who do not want to have a relationship with the opponent in the real space even if they play a role as friends in the game, and such players are contacted by telephone. I can't.
[0004]
In addition, in a multiplayer game, it is one of the pleasures to meet people with a common hobby, but in the conventional system, new friends can be found only among players who are logged in at that time. Of course, you can meet people who have a common hobby by leaving a message such as “People who like XXX, come to △△ at XX days” on the bulletin board. It is necessary not only to be flexible because it is necessary to access at the meeting time, but it is also necessary to allow sufficient time for the message to be read by the other party after writing the message on the bulletin board. For this reason, there is a problem that it takes time to enjoy the game with the desired opponent.
[0005]
Therefore, a main object of the present invention is to provide a game management method capable of easily and quickly playing a game between a player who is logged into the game server and a player who is not logged into the game server. is there.
[0006]
Another object of the present invention is to provide a game server in which a player who has logged in can easily and quickly play a game with a player who has not logged in.
[0007]
Another object of the present invention is to provide a game device that can easily and quickly play a game with a player who has not logged into the game server.
[0008]
Still another object of the present invention is to provide a game program capable of easily and quickly playing a game between a player who is logged into the game server and a player who is not logged into the game server.
[0009]
Another object of the present invention is to provide a storage medium storing a game program capable of easily and quickly playing a game between a player who is logged into the game server and a player who is not logged into the game server. That is.
[0010]
[Means for Solving the Problems]
  According to a first aspect of the present invention, there is provided a game server game management method for providing a game to a first game device of a first player who has logged in through a communication network among a plurality of pre-registered players. Player information indicating the second player who is not playing is transmitted to the first game deviceSteps to doWhen a first selection signal for selecting the second player is received from the first game device, a login operation request is transmitted to the second game device of the second player.Including steps toThis is a game management method.
[0011]
A second invention provides a game server that provides a game to a first game device of a first player who has logged in through a communication network among a plurality of pre-registered players, and the second that is not logged in among the plurality of players. Transmission means for transmitting player information indicating the player to the first game device, and transmission for transmitting a login operation request to the second game device of the second player when a selection signal for selecting the second player is received from the first game device. It is a game server characterized by including a means.
[0012]
According to a third aspect of the present invention, in a game device operated by a player who has logged in to a game server through a communication network, player information indicating a specific player who has been registered in advance and has not logged in to the game server when logging in to the game server is displayed. Player information receiving means for receiving from the player, guidance means for guiding selection of the specific player based on the player information, request means for requesting the game server to transmit a login operation request to the specific player when the specific player is selected, and a game A game apparatus comprising: a login operation request receiving means for receiving a login operation request from a game server when not logged into the server.
[0013]
According to a fourth aspect of the present invention, in a game program to be executed by a game device operated by a player who logs in to a game server through a communication network, a specific player who is registered in advance when logging in to the game server and is not logged in to the game server A player information receiving step for receiving player information indicating the player information, a selection guidance step for guiding selection of a specific player based on the player information, and transmission of a login operation request to the specific player when the specific player is selected. And a log-in operation request receiving step of receiving a log-in operation request from the game server when not logged in to the game server.
[0014]
  According to a fifth aspect of the present invention, in a storage medium storing a game program to be executed by a game device operated by a player who logs in to a game server through a communication network, the game program is registered in advance when logging into the game server and A player information receiving step for receiving player information indicating a specific player who has not logged into the game server from the game server, a selection guidance step for guiding selection of a specific player based on the player information, and a specific player when a specific player is selected. A storage medium comprising: a requesting step for requesting a game server to transmit a login operation request of the user; and a login operation request receiving step for receiving a login operation request from the game server when not logged in to the game server. .
  According to a sixth aspect of the present invention, in a game system operated by a player who logs in to a game server through a communication network, player information indicating a specific player who has been registered in advance and has not logged in to the game server when logging in to the game server is displayed. Player information receiving means for receiving from the player, guidance means for guiding selection of the specific player based on the player information, request means for requesting the game server to transmit a login operation request to the specific player when the specific player is selected, and a game A game system comprising: a login operation request receiving means for receiving a login operation request from a game server when not logged into the server.
[0015]
[Action]
In the first and second inventions, a plurality of players are registered in advance in the game server, and the game server provides a game to the first game device of the first player who has logged in through the communication network. At this time, the game server transmits player information indicating the second player who has not logged in to the first game device, and receives the first selection signal for selecting the second player from the first game device. A login operation request is transmitted to the second game device. By transmitting the player information to the first game device, the second player who has not logged in can be easily grasped by the first game device. Here, when the second player is selected by the first player, a first selection signal is given from the first game device to the game server, and a login operation request is transmitted from the game server to the second game device. That is, participation from the first player is invited to the second player.
[0016]
In one aspect of the present invention, each player can register, in the game server, first transmission information that uniformly permits / prohibits transmission of a login operation request. When the first transmission information of the second player indicates prohibition, the game server returns a first message to the first game device without transmitting a login operation request to the second game device.
[0017]
In another aspect of the present invention, each player can register, in the game server, second transmission information for permitting / prohibiting transmission of a login operation request for each player. When the second transmission information of the second player indicates prohibition for the first player, the game server returns a first message to the first game device without transmitting a login operation request to the second game device.
[0018]
In another aspect of the present invention, the game server returns a second message to the first game device when the login operation rejection is returned from the second game device in response to the login operation request.
[0019]
The login operation request may include identification information that can identify the first player.
[0020]
In still another aspect of the present invention, each player can register personal information in the game server. When the second selection signal for selecting the second player is received from the first game device, the game server returns the personal information of the second player to the first game device.
[0021]
In another aspect of the present invention, the game server already has a first character signal indicating the first character operated by the first player, a two character signal indicating the second character operated by the second player, and at the time of login of the first player. The third character signal indicating the third character operated by the logged-in third player is read from the memory, the player information is added to the second character signal, and the second character is added with the first character signal and the player information. The signal and the third character signal are transmitted to the first game device. The second character is displayed on the first game device in a manner different from that of the first character and the third character.
[0022]
In the third to fifth inventions, when the player operates the game device, the game server is logged in through the communication network. When logging in to the game server, player information indicating a specific player registered in advance and not logged in to the game server is transmitted from the game server, and selection of the specific player is guided based on this player information. When a specific player is selected, a transmission request for a login operation request to the specific player is transmitted to the game server. A game device that has not logged in to the game server receives a login operation request from the game server. That is, when a specific player is selected in the logged-in game device, a login operation request is given to the specific player's game device.
[0023]
【The invention's effect】
According to the first and second inventions, when the second player is selected by the first player, the first selection signal is given from the first game device to the game server, and the game server logs in to the second game device. Since the request is transmitted, the game can be easily and quickly performed between the first player and the second player.
[0024]
According to the third to fifth inventions, when a specific player is selected in the logged-in game device, a login operation request is given to the game device of the specific player, so that the logged-in player logs in. It is possible to play a game easily and quickly with a non-player.
[0025]
The above object, other objects, features and advantages of the present invention will become more apparent from the following detailed description of embodiments with reference to the drawings.
[0026]
【Example】
Referring to FIG. 1, a network game system 10 according to this embodiment includes a game server 20 that is always wiredly connected to a communication network 40, and a plurality of portable communication terminals 30 that are wirelessly connected to the communication network 40 as necessary. 30 ... included. When a player registered in the game server 20 operates his / her mobile communication terminal 30 and logs in to the game server 20, the game server 20 provides a game to the mobile communication terminal 30 of the logged-in player. This allows a game between logged-in players.
[0027]
As shown in FIG. 2, the game server 20 includes a CPU 22 and a memory 24. The memory 24 includes a program storage area 24a, a terrain matrix storage area 24b, a character data storage area 24c, and a work area 24d as shown in FIG. It is formed. The program storage area 24a stores game programs, and the terrain matrix storage area 24b stores matrix data indicating the terrain of the virtual space where the game is played. In addition, the character data storage area 24c stores data (character data) of characters 1, 2, 3,... Operated by each player. Furthermore, the work area 24d stores matrix data (character matrix) indicating characters appearing in the virtual space, a transmission list listing transmission destinations of the character matrix, and the like.
[0028]
As the memory 24, a detachable storage medium such as a magneto-optical disk or a memory card is used in addition to a storage medium provided inside the apparatus which is not detachable such as a hard disk or a nonvolatile memory (for example, EEPROM). Also good.
[0029]
The game program stored in the program storage area 24a executes processing according to the flowcharts shown in FIGS.
[0030]
The matrix data stored in the terrain matrix storage area 24b is data indicating the terrain (map) of the entire virtual space. The virtual space is divided into n blocks in both the horizontal direction and the vertical direction, and coordinates (X1, Y1) to (Xn, Yn) are assigned to each block. The terrain matrix is represented by the coordinate data of each block and the identification number (graphic number) of the graphic data to be reproduced in each block.
[0031]
The character data stored in the character data storage area 24c includes a character ID, a name, a mail address, an IP address, personal information, position information, map size information, status information, and reception mode information. The character ID is a unique identifier assigned to each character, the name is a unique character name assigned to each character, and the mail address and the IP address are the player who operates the character (mobile communication terminal 30). It is a unique address assigned to. The mail address is used when a login operation request is transmitted from the game server 20 side to the mobile communication terminal 30, and the IP address is used when map data or the like is transmitted to the mobile communication terminal 30 that has completed login.
[0032]
The personal information includes the character's gender, the character's age, the character's occupation, the character's graphic number, the character's ability, the character's belongings (items), and a message that the character issues to each player. The position information is information indicating which block (coordinates) the character is in and in which direction, and the map size information is the size of the virtual space of the size 1 or the size 2 of the player. The status information is information indicating whether to be displayed on the mobile communication terminal 30, and the status information is information indicating whether the player is in a login / logout state.
[0033]
The acceptance mode information is information indicating from which player the call may be accepted. When accepting a call from any player (neutral acceptance), “permit call” is set for switch 1, “permit all characters” is set for switch 2, and the character list is blank. When only a call from a specific character is accepted (only a call from a friend is accepted), “Allow call” is set in switch 1, “Allow only specific character” is set in switch 2, and The name of a specific character (friend character) is registered in the character list.
[0034]
When accepting a call from a character other than a specific character (rejecting a call from a person who needs attention), “Allow call” is set for switch 1 and “Allow non-specific character” is set for switch 2 Then, the name of a specific character (attention character) is registered in the character list. When a call from any character is rejected, the switch 1 is set to “prohibit calling” and the contents of the switch 2 and the character list are invalidated. When a certain player requests transmission of a login operation request to another player, the game server 20 refers to the reception mode information and determines whether or not the login operation request should be transmitted.
[0035]
A player who wants to participate in the game needs to be pre-registered with the game server 20, and arbitrary character data is created by the player at the time of registration.
[0036]
The character matrix stored in the work area 24d is matrix data indicating characters appearing in the virtual space. The character matrix is created for a part of the virtual space centered on the character of the requesting player when a login request, a logout request, a character movement request, or the like is given from the player. This part of the virtual space is divided into m blocks in both the horizontal direction and the vertical direction, and coordinates (Xp, Yp) to (Xp + m, Yp + m) are assigned to each block (m <n). ). Similarly to the terrain matrix, the character matrix is also represented by coordinate data and graphic numbers.
[0037]
Even if they are the same character, the display mode is different if the direction of the character is different (forward, backward, right, left). Further, the character being logged out is displayed in the virtual space in a sleeping state. As described above, since a character has a plurality of display modes, an extension is added to each graphic number in order to identify the display mode. For example, “f” is added if the character is forward, “b” is added if the character is backward, “r” is added if the character is right, and “l” if the character is left. Is added, and “s” is added if the character is asleep. The coordinates and orientation of each character are specified by position information, and login / logout is specified by status information.
[0038]
The transmission list stored in the work area 24d is a list that enumerates players to whom map data including a terrain matrix and a character matrix should be transmitted. The mobile communication terminal 30 that needs to update the virtual space depends on the relative position between the character of the player who gave the login request, the logout request, the movement request, and the like, and the size (map size) of the virtual space to be displayed. Different. For this reason, based on the position information and map size information of each character, players that need to update the virtual space are listed in the transmission list.
[0039]
From the terrain matrix area 24b and the work area 24d, a part of the terrain matrix and the character matrix centered on the enumerated characters of each player are extracted, and the extracted terrain matrix and character matrix are used as map data for each player. Are transmitted to the mobile communication terminal 30.
[0040]
The mobile communication terminal 30 includes a main body 32 formed in an elongated elliptical shape as shown in FIG. An antenna 34 projects from the upper surface of the main body 32, and a speaker 36 for calling, a display 38, a game key 40, a telephone key 42, and a calling microphone 44 are arranged on the front surface of the main body 32. The game key 40 includes an A button 40a and a B button 40b for controlling the behavior of the user's character, the display of the menu screen, the selection of the menu item, and the like, and for moving the user's character or the cursor on the menu screen. There is a cross key 40c. The telephone keys 42 include a hook key 42a, a hold key 42b, numeric keys 42c indicating "0" to "9", a * key 42d, a # key 42e, a manner key 42f, and a voice memo key 42g. The numeric key 42c, the * key 42d, and the # key 42e are assigned alphabets, hiragana, and the like, so that mail can be created.
[0041]
The inside of the main body 32 is configured as shown in FIG. The antenna 34 is connected to the communication circuit 44, and the call speaker 36 and the call microphone 42 are connected to the sound conversion circuit 46. The communication circuit 44 and the audio conversion circuit 46 are connected to each other and both are controlled by the CPU 48. The CPU 48 is also connected with a non-volatile memory 50 such as a game key 40, a telephone key 42, a display 36, a vibration motor 52, a calling speaker 54, and an EEPROM. The vibration motor 52 vibrates the main body 32 when receiving a mail or an incoming call signal, and the calling speaker 54 outputs a ringing tone when receiving a mail or an incoming call signal. The calling speaker 54 is provided on the back surface of the main body 32.
[0042]
In the memory 50, as shown in FIG. 6, a program storage area 50a, a graphic data storage area 50b, a work area 50c, and a display area 50d are formed. The program storage area 50a stores a game program received from the game server 20 when the player registers character data. The graphic data storage area 50b stores graphic data received from the game server 20 when logging in. The work area 50c stores map data received from the game server 20 during login, reception mode information set by the player himself, and an acquaintance character list. The reception mode information and the acquaintance character list are transferred from the program storage area 50a to the work area 50d at the time of login, and transferred from the work area 50d to the program storage area 50a at the time of logout.
[0043]
The program storage area 50a needs to be formed in a nonvolatile memory, but the graphic data storage area 50b, the work area 50c, and the display area 50d may be formed in a volatile RAM. Further, the graphic data may be received together with the game program at the time of registration in the game server 20, but in this case, the graphic data storage area 50b needs to be formed in a nonvolatile memory.
[0044]
The game program stored in the program storage area 50a executes processing according to the flowcharts shown in FIGS.
[0045]
The graphic data stored in the graphic data storage area 50b includes image data of objects forming a virtual space such as “tree”, “rock”, “lawn”, and image data of characters appearing in the virtual space. Different image numbers are assigned to the image data. As described above, the character has five states: forward, backward, right, left, and sleeping, and image data indicating each state is prepared in the graphic data storage area 50b. A common graphic number is assigned to each image data, but extensions added to the graphic numbers are different from each other.
[0046]
The map data stored in the work area 50c includes a terrain matrix and a character matrix of a virtual space (size 1 or size 2 virtual space) reproduced on the display 38. As shown in FIG. 7, the terrain matrix is composed of the coordinates (X1, Y1) to (Xs, Ys) of each block forming the virtual space and the graphic number of the terrain reproduced in each block. It consists of the coordinates (X1, Y1) to (Xs, Ys) of each block forming the virtual space and the graphic number of the character reproduced in each block. In the case of the size 1 virtual space, the number of horizontal blocks and the number of vertical blocks is, for example, “9” (s = 9), and in the case of the size 2 virtual space, the number of horizontal blocks and the number of vertical blocks is, for example, “5”. (S = 5). Note that for both size 1 and size 2, s <m.
[0047]
Based on such map data and graphic data in the graphic data storage area 50b, virtual space data (game screen data) of size 1 or size 2 shown in FIG. 8 is created. The created virtual space data is stored in the display area 50d, and a virtual space (game screen) based on the data is displayed on the display 38. According to FIG. 8, the topography is expressed by “rock”, “tree”, “stone pavement”, and characters such as “clown”, “magician”, “Yamao” appear on the topography. The logged-in character stands up and walks around the virtual space. On the other hand, the character being logged out is sleeping in the place that existed immediately before the logout. That is, in this embodiment, the characters registered in the game server 20 are all reproduced in the virtual space regardless of whether or not the player is logged in to the game server 20.
[0048]
Returning to FIG. 6, the reception mode information stored in the work area 50 c has only the switch 1 and the switch 2, unlike the reception mode information that forms the character data on the game server 20 side. However, an acquaintance character list is stored separately from the acceptance mode information, and sub-lists of “friend character”, “neutral character” and “attention person character” are formed in this character list. The meanings of the switch 1, the switch 2, the friend character, the neutral character, and the caution character are the same on the game server 20 side and the portable communication terminal 30 side.
[0049]
A start menu screen as shown in FIG. 9 is displayed on the display 38 of the mobile communication terminal 30 during logout. When “game” is selected here, the start menu screen is displayed as a game menu screen shown in FIG. Updated to According to FIG. 10, the title “Online Game” is displayed on the upper side of the screen, and the menu items “Start game” and “Change reception mode” and the cursor pointing to one of the menu items are displayed on the lower side of the screen. Is done. When the player selects “start game” with the cross key 40 c and the A button 40 a, a login request is transmitted from the mobile communication terminal 30 to the game server 20. The game server 20 detects the character data of the player who transmitted the login request from the character data storage area 24c shown in FIG. 3, and updates the status information included in the detected character data from “logout” to “login”.
[0050]
Furthermore, based on the position information, map size information, and status information included in each character data, the players whose screens need to be updated by this login are listed in the transmission list, and the listed players are individually listed. Create map data. The created map data is individually transmitted to the mobile communication terminal 30 of each listed player, and the mobile communication terminal 30 that has received the map data displays a game screen based on the map data on the display 38. The display of the mobile communication terminal 30 logged in this time is updated from the game menu screen shown in FIG. 10 to the game screen shown in FIG. 11 or FIG. In the mobile communication terminal 30 that is already logged in, the sleeping character displayed on the game screen stands up.
[0051]
When the logged-in player operates the cross key 40c, a movement request is transmitted to the game server 20. When the movement request is given, the game server 20 detects the character data of the requesting player from the character data storage area 24b, and updates the position information included in the detected character data. Further, in the same manner as described above, the players who need to update the game screen are listed, different map data is created for each listed player, and the created map data is transmitted to the mobile communication terminal 30 of each player. To do. Thereby, the display on the display 38 of the mobile communication terminal 30 that has received the map data is updated based on the map data. That is, the player character who operates the cross key 40c moves on the game screen of each mobile communication terminal 30 that has received the map data.
[0052]
When the player moves his / her character in front of another character and operates the A button 40a, an action menu screen having two menu items “examine” and “wake up” is displayed on the upper right side of the screen as shown in FIG. Multiple display. Here, when the player operates the cross key 40c and the A button 40a to select “Check”, “Check” information is transmitted to the game server 20. The game server 20 detects the character data of the player who transmitted the “investigation” information from the character data storage area 24c shown in FIG. 3, and converts it into character data different from the position information (coordinates and orientation) included in the detected character data. Based on the position information (coordinates) included, the character data of the other party (the character existing ahead) to be examined is specified. Then, the character name and personal information included in the specified character data are returned to the transmission source of the “search” information. The mobile communication terminal 30 that has received the character name and personal information first registers the character name in the “neutral character” sub-list shown in FIG. 6 and then displays a personal information screen as shown in FIG. .
[0053]
According to FIG. 14, the character image is displayed on the upper left of the screen, the name, occupation, sex and age of the character are displayed on the right side of the character image, and a message is displayed on the lower side of the screen. The character image is generated based on the graphic number included in the personal information and the graphic data stored in the graphic data storage area 50b shown in FIG. In addition, capabilities and belongings are not displayed in the received personal information.
[0054]
When “wake up” is selected on the action menu screen shown in FIG. 13, “wake up” information is transmitted from the mobile communication terminal 30 to the game server 20. The game server 20 detects the character data of the player who transmitted the “wake up” information from the character data storage area 24c shown in FIG. 3, and the position information included in the detected character data and the position information included in another character data, Based on the above, the character data of the opponent who wants to wake up (the character existing ahead) is specified. Then, the reception mode information included in the specified character data is determined.
[0055]
Here, if the content of the switch 1 is “prohibit calling”, the information A is returned to the transmission source of the “wake up” information. On the display 38 of the mobile communication terminal 30 that has received the information A, a message “There is no sign of sleep due to sleep” as shown in FIG. 15 is displayed. Even if the content of switch 1 is “permit call”, the content of switch 2 is “permit only certain characters”, and the character name of the source of the information to “wake up” is not registered in the character list If the content of the switch 2 is “permits other than specific characters” and the character name of the sender of the information to “wake up” is registered in the character list, the information A is returned in the same manner as described above. The message shown in FIG. 15 is displayed on the mobile communication terminal 30 that is the transmission source.
[0056]
On the other hand, when the contents of the switch 1 and the switch 2 are “permit call” and “permit all characters”, the contents of the switch 1 and the switch 2 are “permit call” and “specific”. If the character name of the request source is registered in the character list, or the contents of the switch 1 and switch 2 are “allow call” and “allow other than specific characters” When the character name of the request source is not registered in the list, a game-dedicated mail (login operation request) is transmitted from the game server 20 to the mobile communication terminal 30 of the other party who wants to wake up. In other words, the mail address of the other party who wants to wake up is detected from the character data storage area 24c, and the game-dedicated mail including the request source character name is transmitted to the detected address.
[0057]
A call screen as shown in FIG. 17 is displayed on the display 38 of the mobile communication terminal 30 that has received the game-dedicated mail. According to FIG. 17, a call message including the requesting character name is displayed at the center of the screen, and “Start game”, “Do not play now”, and “Change to call prohibit mode” are displayed below the call message. Three menu items are displayed.
[0058]
Here, when the player who has received the game-dedicated mail selects “start game” with the cross key 40 c and the A button 40 a, the corresponding command information is returned to the game server 20. The game server 20 performs the same processing as when the login request is received, and thereby a plurality of mobile communication terminals 30 including the mobile communication terminal 30 that has transmitted the “wake-up” information and the mobile communication terminal 30 that has received the game-dedicated mail. The display of is updated.
[0059]
When the player who has received the game dedicated mail selects “do not play now” shown in FIG. 17, the corresponding command information is returned to the game server 20. At this time, the game server 20 returns information B to the sender of the information that “wakes up”. On the display 38 of the mobile communication terminal 30 that has received the information B, a message “Munya… I won't get up” is displayed as shown in FIG.
[0060]
When the player who has received the game-specific mail selects “change to call prohibition mode” shown in FIG. 17, the contents of switch 1 in the reception mode information shown in FIG. 6 are updated to “prohibit call” and selected. Command information corresponding to the menu item is returned to the game server 20. At this time, the game server 20 detects the character data of the player who transmitted the command information from the character data storage area 24c shown in FIG. 3, and the content of the switch 1 of the reception mode information included in the detected character data is “prohibited to call”. Change to “Yes”. Further, the information A is transmitted to the transmission source of the information that “wakes up”. The message shown in FIG. 15 is displayed at the sender of the “wake up” information.
[0061]
As shown in FIG. 12, when the player operates the B button 40b without any menu screen being displayed, the system menu screen shown in FIG. According to FIG. 18, three menu items of “screen size change”, “other settings”, and “game end” are displayed on the display 38.
[0062]
Here, when the player selects “change screen size” using the cross key 40 c and the A button 40 a, a size change request is transmitted to the game server 20. At this time, the game server 20 detects the request source character data from the character data storage area 24c shown in FIG. 3, and updates the map size information included in the detected character data. That is, if the map size information before receiving the size change request is “size 1”, it is updated to “size 2”, and if the map size information before receiving the size change request is “size 2”, “size” is updated. Update to 1 ". Further, map data is created based on the updated map size information, and the created map data is returned to the requesting mobile communication terminal 30. The mobile communication terminal 30 creates game screen data based on the received map data, whereby the game screen shown in FIG.
[0063]
When the system menu screen shown in FIG. 18 is displayed and the cursor is set to “game end” and the A button 40 a is pressed, a logout request is transmitted to the game server 20. The game server 20 detects the character data of the requesting player from the character data storage area 24b, and updates the status information included in the detected character data. Further, in the same manner as described above, the players who need to update the game screen are listed, different map data is created for each listed player, and the created map data is transmitted to the mobile communication terminal 30 of each player. To do. The display of the mobile communication terminal 30 that has received the map data is updated based on this map data, and the player character who has logged out changes to a sleeping state on the game screen. On the other hand, the display of the mobile communication terminal 30 that transmitted the logout request is updated from the game screen shown in FIG. 18 to the start menu screen shown in FIG.
[0064]
When the player selects “change reception mode” on the game menu screen shown in FIG. 10, a reception mode setting screen shown in FIG. 19 is displayed on the display 38. According to FIG. 19, “Switch 1”, “Switch 2”, “Character List Edit” and “Setting End” are displayed as main items, and “Allow Call” and “Call” are displayed below “Switch 1”. Sub-items of “prohibit” are displayed below “switch 2”, and sub-items of “permit all characters”, “permit only specific characters”, and “permit other than specific characters” are displayed.
[0065]
Initially, a cursor directed to “switch 1”, “switch 2”, “character list editing” or “setting end” is validated, and when the cross key 40c is operated, this valid cursor moves. When the A button 40a is pressed while the cursor is directed to a desired main item, the cursor of the sub item positioned below the desired main item is validated. When the activated cursor is set to a desired sub item, the content of the desired sub item is set in the reception mode information shown in FIG. For example, when the valid cursor is set to “permit call”, “permit call” is set in the switch 1 of the reception mode information shown in FIG. When the valid cursor is set to “permit only a specific character”, “permit only a specific character” is set in the switch 2 of the reception mode information shown in FIG.
[0066]
When the A button 40a is pressed while the valid cursor is directed to “character list editing”, a character list editing screen shown in FIG. 20 is displayed on the display 38 instead of the reception mode setting screen. According to FIG. 20, “Friend”, “Neutral”, “Need to Watch” and “End of Editing” are displayed as the main list, and the friend character is displayed below “Friend”, “Neutral” and “Need to Watch”. A sub-list, a neutral character sub-list, and a sub-list of cautionary character are respectively displayed. Each sublist matches the sublist shown in FIG.
[0067]
Again, at first, the cursor on the main list is activated, and when the A button 40a is pressed while the effective cursor is directed to the desired menu item, the cursor is displayed on the sub-list below the desired menu item. The cursor is activated. When the A button 40a is pressed while the valid cursor on the sublist is pointing to the desired character name, the movement destination list is displayed as shown in FIG. The menu items of the movement destination list are two sublists to which the effective cursor is not currently directed. For example, if the valid cursor is directed to the neutral character name, “friend” and “person who needs attention” are displayed in the destination list.
[0068]
When the cursor on the destination list is set to a desired item and the A button 40a is pressed, the character name pointed to by the cursor in the sublist is deleted from the sublist, and the deleted character name is the cursor in the destination list. Is added to the sub-list of items that are oriented. At this time, the acquaintance character list shown in FIG. 6 is also changed at the same time. For example, if “Richard” is selected in the neutral character name sub-list and “friend” is selected in the destination list, “Richard” is deleted from the neutral character sub-list and the friend character sub-list is selected. “Richard” is added to the list.
[0069]
After the character list is edited in this way, when the cursor is set to “end editing” and the A button 40a is pressed, the character list editing screen is updated to the reception mode setting screen shown in FIG. When the cursor is set to “end of setting” on the reception mode setting screen and the A button 40a is pressed, reception mode information (transmission data) composed of the switch 1, the switch 2 and the character list is created. 20 is transmitted. At this time, the transmission data switch 1 and switch 2 coincide with the reception mode information switch 1 and switch 2 shown in FIG. 6, and the setting of the character list follows the contents of the switch 2. If switch 2 “allows all characters”, the character list is blank, if switch 2 “allows only certain characters”, the friend character name is set in the character list, and switch 2 “specifies” If it is “Allow other characters”, the name of the character requiring attention is set in the character list.
[0070]
The created reception mode information is transmitted to the game server 20. The game server 20 detects the character data of the player who transmitted the reception mode information from the character data storage area 24c shown in FIG. 3, and updates the reception mode information included in the detected character data with the received reception mode information. On the mobile communication terminal 30 side, after the reception mode information is transmitted, the display on the display 38 is updated from the reception mode setting screen shown in FIG. 19 to the game menu screen shown in FIG.
[0071]
Processing of the CPU 22 provided in the game server 20 will be described with reference to FIGS.
[0072]
First, referring to FIG. 23, CPU 22 determines what request or information is given from portable communication terminal 30 in each of steps S1, S5, S9, S13, S17, S21 and S25. When a login request is given, YES is determined in step S1, and login processing is performed in step S3. When a logout request is given, YES is determined in step S5, and logout processing is performed in step S7. When a movement request is given, YES is determined in step S9, and movement processing is performed in step S11. When a size change request is given, YES is determined in step S13, and a size change process is performed in step S15. When "wake up" information is given, YES is determined in step S17, and the process of raising in step S19 is performed. When the process of step S3, S7, S11, S15 or S19 is completed, the process returns to step S1.
[0073]
When the reception mode information is given, the process proceeds from step S21 to step S23. In this step, the character data of the transmission source player is detected from the character data storage area 24c based on the character ID added to the reception mode information, and the reception mode information included in the detected character data is transmitted from the portable communication terminal 30. It is updated according to the received reception mode information. As described above, the received reception mode information includes the switch 1, the switch 2 and the character list, and the reception mode information switch 1, switch 2 and the character list detected from the character data storage area 24c are transmitted. The reception mode information is updated by switch 1 and switch 2 and the character list.
[0074]
When “investigation” information is given, the process proceeds from step S25 to step S27. In this step, the character data of the transmission source player is detected from the character data storage area 24c based on the character ID included in the “investigating” information, and is included in character data different from the position information included in the detected character data. Based on the position information, character data of a partner to be examined (a character existing ahead of the transmission source character) is specified. Further, the character name and personal information are detected from the specified character data, and the detected character name and personal information are returned to the transmission source of the “check” information.
[0075]
The login process in step S3 follows a subroutine shown in FIG. First, in step S31, the character data of the requesting player is detected from the character data storage area 24b shown in FIG. 3 based on the character ID included in the login request, and the status information included in the detected character data is detected from “logout”. Update to “Login”. When the update of the status information is completed, login permission is transmitted to the requesting mobile communication terminal 30 in step S33, and the players whose map data should be updated are listed in step S35. In subsequent step S37, the map data is transmitted to the mobile communication terminal 30 of the listed player. Specifically, map data (terrain matrix and character matrix) is created based on position information and map size information included in the character data of the listed player, and the created map data is transmitted to the mobile communication terminal 30. . Such a process is performed for each character ID listed, and when the process is completed, the process returns to the upper hierarchy routine.
[0076]
The logout process in step S7 shown in FIG. 23 follows a subroutine shown in FIG. First, in step S41, the character data of the requesting player is detected from the character data storage area 24b based on the character ID included in the logout request, and the status information included in the detected character data is changed from “login” to “logout”. Update. Subsequently, a logout notice (end notice) is transmitted to the requesting mobile communication terminal 30 in step S43, and the players whose map data should be updated are listed in step S45. In step S47, map data is transmitted to the mobile communication terminal 30 of the listed player, and when the transmission is completed, the process returns to the upper layer routine.
[0077]
The movement process in step S11 shown in FIG. 23 follows a subroutine shown in FIG. First, in step S51, the character data of the requesting player is detected from the character data storage area 24d based on the character ID included in the movement request, and the position information (coordinates or orientation) included in the detected character data is detected according to the movement request. Update. In step S53, the players who need to update the map data are listed, and in step S55, the map data is transmitted to the mobile communication terminals 30 of the listed players. When transmission is completed, the routine returns to the upper hierarchy.
[0078]
The size changing process in step S15 shown in FIG. 23 follows a subroutine shown in FIG. First, in step S61, the character data of the requesting player is detected from the character data storage area 24c based on the character ID included in the size change request, the map information included in the detected character data is specified, and the specified map is detected. Update information. If the current map information is “size 1”, it is updated to “size 2”, and if the current map information is “size 2”, it is updated to “size 1”. In step S63, a list-up process similar to that described above is performed, and in step S65, map data is transmitted only to the transmission source of the size change request. When transmission is completed, the routine returns to the upper layer routine.
[0079]
The list-up process in step S35, S45, S53 or S63 follows the subroutine shown in FIGS. First, in step S71, the contents of the character matrix and transmission list formed in the work area 24d are cleared. In step S73, the character data (character n) of the player who transmitted the login request, logout request, movement request, or size change request is specified from the character data storage area 24c, and position information and map size information are detected from the specified character data. To do. In the subsequent step S75, the center coordinates of the character matrix formed in the work area 24d shown in FIG. 3 are determined based on the position information detected in step S73. The center coordinates of the character matrix coincide with the coordinates included in the detected position information, and the size of the character matrix is always twice the larger map size (size 1). For this reason, the center coordinates and size of the character matrix are determined as shown in FIG.
[0080]
When the center coordinates and size of the character matrix are determined, step S77 sets the character number i to "1", and in step S79, position information is detected from the character data of the character i (specified from the character data storage area 24c). . In step S81, it is determined whether or not the character i is included in the character matrix range based on the position information detected in step S79. If NO, the process directly proceeds to step S87. On the other hand, if “YES” in the step S79, status information and a graphic number are detected from the character data of the character i in a step S83, and the graphic number is mapped to a character matrix in a step S85, and then, the process proceeds to a step S87. In step S85, specifically, the extension determined based on the position information (the direction of the character i) and the status information is added to the graphic number, and the graphic number with the extension added is the position detected in step S79. Mapping to the character matrix according to the information (coordinates of character i).
[0081]
In step S87, the character number i is incremented, and in the subsequent step S89, the incremented character number i is compared with the maximum character number imax. Here, if i ≦ imax, the processes in steps S79 to S87 are repeated. As a result, the graphic numbers of a plurality of characters existing around the character n are mapped to the character matrix. According to FIG. 22, among the characters i, i ', i "and n, the graphic numbers of the characters i, i" and n are mapped to the character matrix.
[0082]
When i> imax, the process proceeds from step S89 to step S91, and the character number i is set to “1” again. In a succeeding step S93, it is determined whether or not the character i matches the character n. If “YES” here, the character ID of the character i (= n) is added to the transmission list in a step S103, and the process proceeds to a step S105. That is, the character ID of the character n is unconditionally added to the transmission list.
[0083]
On the other hand, if “NO” in the step S93, status information is detected from the character data of the character i (stored in the character data storage area 24c) in a step S95, and whether the character i is in a login state or a logout state in a step S97. Is determined. If it is in the logout state, the process proceeds to step S105 without performing the transmission list addition process. On the other hand, if it is a login state, map size information is detected from the character data of the character i at step S99, and it is judged whether the character n exists in the visual field of the character i at step S101. Specifically, based on the detected map size information and position information of the character i, it is determined whether or not the coordinates of the character n are included within the range of the map size of the character i. And if it is YES, it will progress to step S105 through the transmission list addition process in step S103, but if it is NO, it will progress to step S105 as it is.
[0084]
In step S105, the character number i is incremented, and in the subsequent step S107, the incremented character number i is compared with the maximum character number imax. If i ≦ imax, the processes in steps S93 to S107 are repeated. As a result, the character ID of the character n and the character ID of the character in which the character n exists in the field of view are added to the transmission list. According to FIG. 22, only character i has character n in the field of view. For this reason, the character IDs of the characters n and i are added to the transmission list. If i> imax is determined, the process returns to the upper-level routine.
[0085]
In steps S37, S47, and S55 described above, map data is created by cutting out the terrain matrix and the character matrix for each player registered in the transmission list in this way. On the other hand, in step S65, only for the player who transmitted the size change request, map data is created by cutting out the terrain matrix and the character matrix. In either case, the size of the map data follows the map size information of the destination player, and the graphic number of the destination player is assigned to the center coordinates of the map data.
[0086]
In step S19 shown in FIG. 23, the subroutine shown in FIGS. 30 and 31 is processed. In step S111, the character data of the transmission source player is specified from the character data storage area 24c based on the character ID included in the “wake up” information, and based on the position information (coordinates and orientation) included in the specified character data. The character data of the opponent to be woken up is specified, and the reception mode information is detected from the specified character data of the opponent. In step S113, it is determined whether or not the content of the switch 1 of the detected reception mode information is “permit call”. If NO, the permission / prohibition flag is set to “prohibited” in step S125. On the other hand, if “YES” in the step S113, the contents of the switch 2 are determined in steps S115 and S117.
[0087]
If the content of the switch 2 is “permit all characters”, YES is determined in a step S115, and a permission / prohibition flag is set to “permitted” in a step S123. If the content of the switch 2 is “permit only a specific character”, the process proceeds from step S117 to step S121, and it is determined whether or not the calling character is registered in the character list of the reception mode information detected in step S111. If YES here, the permission / prohibition flag is set to “permitted” in step S123, but if NO, the permission / prohibition flag is set to “prohibited” in step S125. If the content of the switch 2 is “permits other than specific characters”, the process proceeds from step S117 to step S119, and it is determined whether or not the caller character is registered in the character list of the reception mode information detected in step S111. If NO here, the permission / prohibition flag is set to “permitted” in step S123, but if YES, the permission / prohibition flag is set to “prohibited” in step S125.
[0088]
When the setting of the permission / prohibition flag is completed in this way, the setting state of the permission / prohibition flag is determined in step S127. If the setting state is “prohibited”, information A is transmitted in step S137, and then the routine returns to the upper layer routine. When the information A is transmitted, a message “There is no sign of awake sleep” is displayed on the display 38 of the caller mobile communication terminal 30.
[0089]
On the other hand, if the setting state is “permitted”, a game-dedicated e-mail is created in step S129, and the created game-dedicated e-mail is transmitted to the partner mobile communication terminal 30 in step S131. The game-dedicated e-mail is an e-mail for requesting the other party to log in, and includes the character name of the caller. In response to this game-dedicated mail (login operation request), when the opponent selects “change to call prohibition mode”, the process proceeds from step S133 to step S135. In this step, the opponent character data is detected from the character data storage area 24c, and the switch 1 of the reception mode information included in the detected character data is updated to “prohibit calling”. When the update process is completed, information A is transmitted in step S137, and then the process returns to the upper hierarchy routine.
[0090]
When the other party selects “Do not play now” for the game-dedicated mail, the process proceeds from step S139 to step S141, and information B is transmitted to the calling mobile communication terminal 30. When the information B is transmitted, a message “Munya Munya… is likely to wake up and does not wake up” is displayed on the display 38 of the caller mobile communication terminal 30. When the transmission of the information B is completed, the process returns to the upper layer routine.
[0091]
In response to the game-dedicated mail, if the opponent selects “start game” or times out before the opponent selects anything, YES is determined in step S143 or S145, and the process returns to the upper level routine. To do. However, when “start game” is selected, a login request is transmitted from the mobile communication terminal 30, and the game is started by the login process in step S3 shown in FIG.
[0092]
Next, processing of the CPU 48 provided in the mobile communication terminal 30 will be described with reference to flowcharts shown in FIGS.
[0093]
First, the CPU 48 determines whether or not a signal is received from the outside and the key operation by the player in each of steps S151, S153, and S155. When a signal is received from the outside, the process proceeds from step S151 to step S157, and it is determined whether the received signal is a mail signal or an incoming call signal for a call. If the received signal is an incoming call signal, the process proceeds to step S159 to perform call processing. In step S161, it is determined whether the call process is completed. If NO, the process returns to step S159 to repeat the call process. If YES, the process returns to step S151.
[0094]
If the received signal is a mail signal, it is determined in step S165 whether this mail signal is a normal mail or a game-dedicated mail. If it is a normal mail, the process returns to step S151 through the normal mail process in step S167. On the other hand, if the received mail signal is a game-dedicated mail, game mail processing is performed in step S169, and the state of the game start flag is determined in step S171. If the game start flag is in the reset state, the process directly returns to step S151. If the game start flag is in the set state, the login process, the game process, and the logout process are performed in steps S173, S175, and S177, and then step S151. Return to.
[0095]
In the menu screen shown in FIG. 10, when the player moves the cursor to “change accept mode” with the cross key 040c and presses the A button 40a, the process proceeds from step S153 to step S163, and accept mode change processing is performed. When the process is completed, the process returns to step S151. On the other hand, if the player selects “start game” with the cross key 40c and the A button 40a on the menu screen shown in FIG. 10, “YES” is determined in the step S155, and the process proceeds to a step S173.
[0096]
The game mail process in step S169 follows a subroutine shown in FIG. First, in step S181, a ringing sound is generated through the calling speaker 54, and vibration is generated by the vibration motor 52 in step S183. In step S185, the character name of the caller is detected from the received game mail, and in step S187, the detected character name is added to the “neutral character” sub-list formed in the work area 50c shown in FIG. If the detected character name is already registered in the acquaintance character list, the process of step S187 is not performed.
[0097]
When the process of step S187 is completed, the call screen shown in FIG. 11 is displayed on the display 38 in step S189, and any of the menus “start game”, “do not play now”, and “change to call prohibit mode” is displayed. Whether or not the item has been selected by the player is determined in steps S191, S197, and S205.
[0098]
When the cursor is set to “start game” by the cross key 40c and the A button 40a is pressed, the process proceeds from step S191 to step S193, and command information corresponding to the selected menu item is transmitted to the game server 20. Then, after setting the game start flag in step S195, the process returns to the upper hierarchy routine. When “set to call prohibition mode” is selected by the cross key 40c and the A button 40a, “YES” is determined in the step S197, and command information corresponding to this menu item is transmitted to the game server 20 in a step S199. In step S201, “inhibit call” is set in the switch 1 of the reception mode information stored in the work area 50c. Then, after resetting the game start flag in step S203, the process returns to the upper hierarchy routine.
[0099]
If “do not play now” is selected by the cross key 40c and the A button 40a, YES is determined in the step S205, and the command information corresponding to the menu item is transmitted to the game server 20 in the step S207, and then the step is performed. The process proceeds to S203. If a time-out occurs before the player selects any menu item, YES is determined in step S209, and the process directly proceeds to step S203.
[0100]
On the game server 20 side, the determination processing of steps S133, S139, and S143 shown in FIG. 31 is performed based on the command information transmitted in steps S193, S199, or S207.
[0101]
The login process in step S173 follows a subroutine shown in FIG. First, initialization is performed in step S211, and a login request is transmitted to the game server 20 in step S213. In response to the login request, the game server 20 returns login permission and map data (steps S33 and S37). For this reason, the mobile communication terminal 30 side determines login permission and whether or not map data is received in each of steps S215 and S217, and proceeds to step S219 when map data is received. In step S219, a virtual space (game screen) as shown in FIG. 11 or 12 is displayed on the display 38 based on the received map data. When the display process is completed, the routine returns to the upper hierarchy.
[0102]
The game process in step S175 follows a subroutine shown in FIGS. First, in step S221, map update processing is performed, and then in steps S223, S227, and S229, it is determined whether or not the cross key 40c, the A button 40a, and the B button 40b are operated. When the cross key 40c is operated, the moving process is performed in step S225, and when the process is completed, the process returns to step S221.
[0103]
When the A button 40a is pressed, the process proceeds to step S231, and it is determined whether or not another character exists in front of the own character. If “NO” here, the process returns to the step S221, but if “YES”, the process proceeds to a step S233 to display the action menu screen shown in FIG.
[0104]
Here, when the player sets the cursor to “Check” with the cross key 40c and presses the A button 40a, YES is determined in Step S235, and the check is performed in Step S237. When the process is completed, the process returns to step S221. On the other hand, when the player sets the cursor to “raise” by the cross key 40c and presses the A button 40a, YES is determined in the step S239, and a process of raising in the step S241 is performed. When the process is completed, the process returns to step S221. On the other hand, when the player presses the B button 40b, YES is determined in step S243, the action menu screen is erased in step S245, and the process returns to step S221.
[0105]
While the player does not perform any key operation, map update processing is performed in step S247, and it is determined in step S249 whether another character exists in front of the player's own character. If YES, the process returns to step S235. If NO, the action menu screen is erased in step S245, and then the process returns to step S221. Therefore, when another character leaves the front of his / her character, the action menu screen is erased without operating the B button 40b.
[0106]
If the player operates the B button 40b while the action menu screen is not displayed, YES is determined in step S229, and the system menu screen shown in FIG. 18 is displayed on the display 38 in step S251. Here, when the player sets the cursor to “change screen size” with the cross key 40c and presses the A button 40a, YES is determined in step S253, and size change processing is performed in step S255. When the process is completed, the process returns to step S221. When the player sets the cursor to “other setting process” with the cross key 40c and presses the A button 40a, YES is determined in step S257, and the process returns to step S221 through the other setting process in step S259. When the player presses the B button 40b, “YES” is determined in the step S261, the system menu screen is erased in a step S263, and then the process returns to the step S221. When the player sets the cursor to “game end” using the cross key 40c and presses the A button 40a, YES is determined in step S265, and the process returns to the upper-level routine.
[0107]
While the player does not perform any key operation, map update processing is performed in step S267, and the process returns to step S253. Thereby, another character moves on the game screen while the system menu screen is displayed.
[0108]
The map update process in step S221, S247 or S267 follows a subroutine shown in FIG. First, in step S271, it is determined whether or not new map data has been received. If NO, the process returns to the upper hierarchy routine. If YES, the game screen is updated in step S273. That is, the map data stored in the work area 50c shown in FIG. 6 is updated with the map data received this time. In the display area 50d, game screen data created based on the updated map data and the graphic data stored in the graphic data storage area 50b is developed, whereby the game screen on the display 38 is updated. When such an update process is completed, the routine returns to the upper layer routine.
[0109]
The movement process in step S225 follows a subroutine shown in FIG. First, in step S281, a movement request including its own character ID and destination information (upper, lower, right, or left) is transmitted to the game server 20. On the game server 20 side, position information update processing (step S51) corresponding to the requesting player and new map data return processing (step S55) are performed. When the map data is returned, YES is determined in step S283, and the game screen is updated in the same manner as step S273 described above in step S285. When the update is completed, the routine returns to the upper layer routine.
[0110]
The checking process in step S237 follows a subroutine shown in FIG. First, in step S291, “investigation” information including its own character ID is transmitted. Since the game server 20 performs character name and personal information detection / return processing (step S27), it is determined whether or not the character name and personal information are received in the subsequent step S293. If “YES” is determined here, the process proceeds to a step S295 so as to register the received character name in the “neutral character” sub-list shown in FIG. In step S297, the personal information screen data based on the received personal information is developed in the display area 50d shown in FIG. 6, and the personal information screen as shown in FIG. In step S299, it is determined whether or not the B button 40b is operated, and when the B button 40b is pressed, the process returns to the upper layer routine. Note that the addition processing in step S295 is performed when the same character name does not exist in the acquaintance character list, as described above.
[0111]
The process that occurs in step S241 follows a subroutine shown in FIG. First, in step S301, "wake up" information including his / her character ID is transmitted. Since the game server 20 returns information A or information B in response to the “wake up” information (step S137 or S141), after transmitting the “wake up” information, the reception of the information A or information B is received in step S303 or S307. Determine presence or absence. When the information A is returned, the process proceeds to step S305, and a message “There is no sign of sleep due to sleep” as shown in FIG. When the information B is returned, the process proceeds to step S309, and a message “Manyamya… is likely to wake up” is displayed on the display 38 as shown in FIG. In step S313, it is determined whether or not the B button 40b is operated. When the B button 40b is pressed, the routine returns to the upper hierarchy. If a timeout occurs before receiving either information A or information B, YES is determined in step S311, and the process directly returns to the upper layer routine.
[0112]
The size changing process in step S255 follows a subroutine shown in FIG. First, in step S321, a size change request including its own character ID is transmitted to the game server 20. Since the game server 20 returns map data in response to the size change request (step S65), it is determined whether or not map data is received in step S323. If map data is received, it will progress to step S325 and will update a game screen. That is, the map data stored in the work area 50c shown in FIG. 6 is updated with the map data received this time. In the display area 50d, game screen data created based on the updated map data and the graphic data in the graphic data storage area 50b is developed, whereby the game screen on the display 38 is updated. When the update process is completed, the routine returns to the upper hierarchy.
[0113]
The logout process in step S177 shown in FIG. 32 follows a subroutine shown in FIG. First, in step S331, a logout request including its own character ID is transmitted to the game server 20. Since the game server 20 transmits a logout notification in response to the logout request (step S43), in step S333, it is determined whether or not there is a logout notification. When a logout notification is received, a game end process is performed in step S335, and then the process returns to the upper hierarchy routine.
[0114]
The acceptance mode changing process in step S163 shown in FIG. 32 follows a subroutine shown in FIG. First, in step S341, the acceptance mode setting screen shown in FIG. 19 is displayed on the display 38, and the cursor pointing to "switch 1", "switch 2", "character list editing" or "setting end" is validated. Subsequently, in each of steps S343, S347, S351, and S355, it is determined which one of “switch 1”, “switch 2”, “character list editing”, and “setting end” has been selected.
[0115]
When the player moves the cursor to “Switch 1” using the cross key 40c and presses the A button 40a, YES is determined in step S343, and SW1 changing processing is performed in step S345. On the other hand, when the player moves the cursor to “switch 2” using the cross key 40c and presses the A button 40a, YES is determined in step S347, and SW2 change processing is performed in step S349.
[0116]
Referring to FIG. 19, the SW1 change process enables a cursor pointing to “permit call” or “prohibit call”, and SW2 change process “allows all characters”, “allows only specific characters”. Enables a cursor that points to "or allow non-specific characters". When the cursor is set to a desired menu item by the cross key 40c, the switch 1 or the switch 2 of the reception mode information shown in FIG. 6 is updated by the menu item to which the cursor points. When the B button 40b is pressed, the cursor pointing to “switch 1”, “switch 2”, “character list editing” or “setting end” is validated, and the process returns to step S343.
[0117]
When the player moves the cursor to “character list editing” with the cross key 40c and presses the A button 40a, YES is determined in step S351, and character list editing processing is performed in step S353. When the character list editing process is completed, the process returns to step S343.
[0118]
When the player moves the cursor to “end setting” with the cross key 40c and presses the A button 40a, the process proceeds from step S355 to step S357, and it is determined whether or not the setting has been changed. If “NO” here, the process proceeds to a step S363 as it is, and after the mode change screen is erased, the process returns to the upper hierarchy routine. On the other hand, if “YES” in the step S357, reception mode information creation processing is performed in a step S359, and in the subsequent step S361, the user ID is added to the created reception mode information and transmitted to the game server 20. When the transmission is completed, the mode change screen is erased in step S363, and then the routine returns to the upper layer routine.
[0119]
The character list editing process in step S353 follows a subroutine shown in FIG. First, in step S371, the character list editing screen shown in FIG. 20 is displayed on the display 38. In each of steps S373, S377, S381, and S385, any one of “friend”, “neutral”, “person who needs attention” and “end editing” is displayed. Determine if was selected.
[0120]
If the A button 40a is pressed while the cursor is set to "friend", the process proceeds from step S373 to step S375, and the sub-list editing process for the friend character is performed. When the A button 40a is pressed while the cursor is set to "neutral", the process proceeds from step S377 to step S379, and the sub-list editing process for the neutral character is performed. If the A button 40a is pressed in a state where the cursor is set to “person requiring attention”, the process proceeds from step S381 to step S383, and a sublist editing process is performed for the person character requiring attention. When the process of step S375, S379 or S383 is completed, the process returns to step S373. If the A button 40a is pressed in a state where the cursor is set to “end editing”, YES is determined in the step S385, and the editing screen is erased in a step S387, and then the process returns to the upper hierarchy routine.
[0121]
The sublist editing process shown in steps S375, S379, or S383 follows the subroutine shown in FIG. In step S391, a cursor is displayed on the selected sublist. When "Friend" is selected, the cursor is displayed so that it points to one of the friend character names. When "Neutral" is selected, the cursor is displayed so that it points to one of the neutral character names. When “Caution required person” is selected, a cursor is displayed so as to point to one of the caution character names. Here, when the player operates the cross key 40c, YES is determined in a step S393, the cursor is moved in a step S395, and then the process returns to the step S393. When the player operates the B button 40b, YES is determined in step S399, the cursor in the sublist is erased in step S401, and the process returns to the upper hierarchy routine.
[0122]
When the player operates the A button 40a, YES is determined in a step S397, and a movement destination list as shown in FIG. The moving destination list shown in FIG. 21 is a list displayed when sublist editing is performed for a neutral character, and the menu items are “friends” and “persons requiring attention”. In the sublist editing process for the friend character, the menu items of the destination list are “neutral” and “person to be watched”. In the sublist editing process for the attention character, the menu item of the destination list is “friend”. "And" Neutral ".
[0123]
When the player operates the cross key 40c in a state where the movement destination list is displayed, the process proceeds from step S405 to step S407, and the cursor in the movement destination list is moved in a desired direction. When the movement process is completed, the process returns to step S405. On the other hand, when the player operates the B button 40b, YES is determined in the step S411, the movement destination list is deleted in a step S419, and the process returns to the step S393.
[0124]
On the other hand, when the player operates the A button 40a, the processing after step S413 is performed. First, in step S413, the character name to which the cursor is pointing in the currently displayed sublist is deleted from the corresponding sublist in the work area 50c shown in FIG. In step S415, the character name deleted in step S413 is added to the sublist of FIG. 6 corresponding to the menu item to which the cursor is pointing in the destination list. When the movement of the character name is completed in this way, the character list editing screen is updated in step S417, the movement destination list is deleted in step S419, and the process returns to step S393.
[0125]
The reception mode information creation processing in step S359 shown in FIG. 43 follows a subroutine shown in FIG. First, in steps S421 and S423, the contents of switch 1 and switch 2 of the reception mode information shown in FIG. 6 are set in the column of switch 1 and switch 2 of the reception mode information (transmission data) to be transmitted. In steps S425 and S429, the content of the set switch 2 is determined. If the content of the switch 2 is “permit all characters”, the process proceeds from step S425 to step S427, and the character list column of the transmission data is cleared. On the other hand, if the content of the switch 2 is “permit only a specific character”, the process proceeds from step S429 to step S431, and the friend character name registered in the acquaintance character list shown in FIG. 6 is set in the character list of the transmission data. On the other hand, if the content of the switch 2 is “permits other than a specific character”, the process proceeds from step S429 to step S433, and the caution character name registered in the acquaintance character list shown in FIG. Set. When transmission data is created in this way, the process returns to the upper-level routine.
[0126]
As can be seen from the above description, a plurality of players are registered in advance in the game server 20, and the game server 20 provides a game to the mobile communication terminal 30 of the player who has logged in through the communication network 40. At this time, the game server 20 transmits not only the graphic number indicating the character of the logged-in player but also the graphic number indicating the logged-out character to the game device 30 of the logged-in player. Each character image is displayed on the display 38 of the game apparatus 30 in a manner corresponding to login / logout. Here, when “wake up” is selected for the character being logged out, “wake up” information is given from the mobile communication terminal 30 to the game server 20.
[0127]
The game server 20 determines the reception mode information of the character being logged out, and returns the information A to the transmission source of the “wake up” information if the content of the switch 1 is “prohibit calling”. On the mobile communication terminal 30 that has received the information A, a message “There is no sign of waking up in a deep sleep ...” is displayed. Even if the content of switch 1 is “permit call”, the content of switch 2 is “permit only certain characters”, and the character name of the source of the information to “wake up” is not registered in the character list If the content of the switch 2 is “permits other than specific characters” and the character name of the sender of the information to “wake up” is registered in the character list, the information A is returned in the same manner as described above. The
[0128]
On the other hand, when the contents of the switch 1 and the switch 2 are “permit call” and “permit all characters”, the contents of the switch 1 and the switch 2 are “permit call” and “permit only a specific character”. If “Yes” is selected and the character name of the request source is registered in the character list, or if the contents of the switch 1 and switch 2 are “allow call” and “allow other than specific characters”, the request is made to the character list. If the original character name is not registered, a login operation request is transmitted from the game server 20 to the partner mobile communication terminal 30. On the display 38 of the mobile communication terminal 30 that has received the login operation request, a call message including the caller character name is displayed.
[0129]
Here, when the player who has received the login operation request selects “start game”, the game server 20 performs login processing, whereby the game is played on the portable communication terminal 30 of the player who has selected “start game”. Provided. When the player who has received the login operation request selects “do not play now”, the game server 20 information B is returned to the sender of the information to “wake up”. On the display 38 of the mobile communication terminal 30 that has received the information B, a message “Munya… I wo n’t get up” is displayed.
[0130]
Thus, when the logged-in player character is selected by the logged-in player, the “wake-up” information is given to the game server 20 from the logged-in portable communication terminal 30, and the portable communication logged out from the game server 20. A login operation request is transmitted to the terminal 30. Therefore, it is possible to easily and quickly play a game between a logged-in player and a logged-out player.
[0131]
In this embodiment, the game is progressed using a game screen formed by the terrain and character graphic data. However, the game has a screen consisting only of text data as shown in FIGS. You may make it progress using.
[0132]
FIG. 47 shows a game menu screen, in which the title “Online game” is displayed in the center of the screen, and “start game”, “change reception mode”, and “return” menu items are displayed at the bottom of the screen.
[0133]
FIG. 48 shows a game screen, where the current location name “Prairie Prairie” is displayed at the top of the screen, a plurality of character names are displayed at the center of the screen, and menu items are displayed at the bottom of the screen. As for the character name, your character name “Ninten” is displayed at the top, and the names of other characters “Robin”, “Wil”, “Marian” and “John” in the prairie grassland are It is displayed under “Tenten”. Robin is logging out and status information “sleeping” is displayed on the right side of “Robin”. For menu items, four items of “move”, “examine”, “set”, and “end” are displayed.
[0134]
Here, when “move” is selected, a move menu screen shown in FIG. 49 is displayed. According to FIG. 49, the command name “move” is displayed on the upper side of the screen, and the current location name “prairie grassland” is displayed below it. In the center of the screen, the moving directions “north”, “south”, “west” and “east” and the place names “Selva Forest”, “Orlean Forest”, “Nord Wetlands” and “Volkhoko” exist in each direction. "Mountain" is displayed. The menu item “Return” is displayed at the bottom of the screen. Here, when a desired destination is selected, a game screen including the place name of the destination and the name of the character existing at the destination is displayed as shown in FIG. When “RETURN” is selected, the game screen shown in FIG. 48 is restored.
[0135]
When an arbitrary character name and “Check” are selected on the menu screen shown in FIG. 48, a personal information screen as shown in FIG. 50 is displayed. The name, gender, and status of the selected character are displayed at the top of the screen, the profile (message) of the selected character is displayed at the center of the screen, and two types of “examine” and “return” are displayed at the bottom of the screen. Menu items are displayed. When “wake up” is selected here, a call screen shown in FIG. 51 is displayed on the mobile communication terminal of the Robin player. According to FIG. 51, the title “Online Game” is displayed at the top of the screen, the message “Nenten-san is waking you” is displayed at the center of the screen, and “Start the game” is displayed at the bottom of the screen. , Three menu items “not play now” and “set to call prohibition” are displayed. Here, the operation when the Robin player selects each menu item is substantially the same as in the above-described embodiment.
[0136]
In this way, even on a game screen made up of text data, if the character name being logged out is displayed and a login operation request is transmitted to the player when this character name is selected, it is easy to connect with the player being logged out. And a game can be played promptly.
[0137]
Further, in this embodiment, as shown in FIG. 23, all of login processing, logout processing, movement processing, size change processing, waking processing, reception mode update processing, and personal information transmission processing may be performed by one game server. However, the above-described processing may be shared by a plurality of servers spaced from each other. In this case, a game server is formed by a plurality of servers installed at different positions.
[0138]
Furthermore, in this embodiment, the specific contents and types of the game are not described in detail, but all the characters that can be freely controlled by the player in the virtual space are considered to be included in the concept of “game”. It is done.
[Brief description of the drawings]
FIG. 1 is an illustrative view showing one embodiment of the present invention;
FIG. 2 is a block diagram illustrating an example of a configuration of a game server.
FIG. 3 is an illustrative view showing a mapping state of a memory provided in the game server.
FIG. 4 is an external view showing an example of a mobile communication terminal.
FIG. 5 is a block diagram illustrating an example of a configuration of a mobile communication terminal.
FIG. 6 is an illustrative view showing a mapping state of a memory provided in the mobile communication terminal.
FIG. 7 is an illustrative view showing a structure of map data.
FIG. 8 is an illustrative view showing one example of a virtual space.
FIG. 9 is an illustrative view showing one example of a start menu screen displayed on the mobile communication terminal.
FIG. 10 is an illustrative view showing one example of a game menu screen displayed on the mobile communication terminal.
FIG. 11 is an illustrative view showing one example of a virtual space displayed on the mobile communication terminal.
FIG. 12 is an illustrative view showing another example of the virtual space displayed on the mobile communication terminal.
FIG. 13 is an illustrative view showing one example of a virtual space and an action menu screen displayed on the mobile communication terminal.
FIG. 14 is an illustrative view showing one example of a personal information screen displayed on a mobile communication terminal.
FIG. 15 is an illustrative view showing one example of a virtual space, an action menu screen, and a response message displayed on the mobile communication terminal.
FIG. 16 is an illustrative view showing another example of a virtual space, an action menu screen, and a response message displayed on the mobile communication terminal.
FIG. 17 is an illustrative view showing one example of a call screen displayed on a mobile communication terminal;
FIG. 18 is an illustrative view showing one example of a virtual space and a system menu screen displayed on the mobile communication terminal.
FIG. 19 is an illustrative view showing one example of a reception mode setting screen displayed on the mobile communication terminal.
FIG. 20 is an illustrative view showing one example of a character list editing screen displayed on the mobile communication terminal.
FIG. 21 is an illustrative view showing one example of a character list editing screen and a destination list displayed on a mobile communication terminal;
FIG. 22 is an illustrative view showing one portion of operation of the game server;
FIG. 23 is a flowchart showing a part of processing of the game server.
FIG. 24 is a flowchart showing another part of the processing of the game server.
FIG. 25 is a flowchart showing another part of the processing of the game server.
FIG. 26 is a flowchart showing yet another portion of the processing of the game server.
FIG. 27 is a flowchart showing another part of the process of the game server.
FIG. 28 is a flowchart showing another part of the processing of the game server.
FIG. 29 is a flowchart showing yet another portion of the processing of the game server.
FIG. 30 is a flowchart showing another part of the process of the game server.
FIG. 31 is a flowchart showing still another part of the processing of the game server.
FIG. 32 is a flowchart showing a part of the processing of the mobile communication terminal.
FIG. 33 is a flowchart showing another portion of the processing of the mobile communication terminal.
FIG. 34 is a flowchart showing another part of the processing of the mobile communication terminal.
FIG. 35 is a flowchart showing yet another portion of the processing of the mobile communication terminal.
FIG. 36 is a flowchart showing another part of the process of the mobile communication terminal.
FIG. 37 is a flowchart showing still another portion of the processing of the mobile communication terminal.
FIG. 38 is a flowchart showing yet another portion of the processing of the mobile communication terminal.
FIG. 39 is a flowchart showing another portion of the process of the mobile communication terminal.
FIG. 40 is a flowchart showing another part of the processing of the mobile communication terminal.
FIG. 41 is a flowchart showing yet another portion of the processing of the mobile communication terminal.
FIG. 42 is a flowchart showing another portion of the processing of the mobile communication terminal.
FIG. 43 is a flowchart showing another portion of the processing of the mobile communication terminal.
FIG. 44 is a flowchart showing yet another portion of the processing of the mobile communication terminal.
FIG. 45 is a flowchart showing another part of the process of the mobile communication terminal.
FIG. 46 is a flowchart showing still another portion of the processing of the mobile communication terminal.
FIG. 47 is an illustrative view showing one example of a game menu screen displayed on the mobile communication terminal in another embodiment of the present invention;
FIG. 48 is an illustrative view showing one example of a game screen displayed on a mobile communication terminal in another embodiment of the present invention;
FIG. 49 is an illustrative view showing one example of a movement menu screen displayed on the mobile communication terminal in another embodiment of the present invention;
FIG. 50 is an illustrative view showing one example of a personal information screen displayed on a portable communication terminal in another embodiment of the present invention.
FIG. 51 is an illustrative view showing one example of a call screen displayed on a mobile communication terminal in another embodiment of the present invention;
[Explanation of symbols]
10 Network system
20 ... Game server
22, 48 ... CPU
24, 50 ... Memory
30. Mobile communication terminal
38 ... Display

Claims (12)

In a game management method of a game server for providing a game to a first game device of a first player who has logged in through a communication network among a plurality of pre-registered players,
And transmitting the player information of a second player who is not the log of the plurality of players to the first game device,
A game management method comprising a step of transmitting a login operation request to a second game device of the second player when a first selection signal for selecting the second player is received from the first game device. Each of the players can register, with the game server, first transmission information that uniformly permits / prohibits transmission of the login operation request,
When the first transmission information before Symbol second player indicates the prohibition, comprising the step of returning the first message to the first game device without transmitting the login operation request to the second game device, wherein Item 1. A game management method according to Item 1. Each of the players can register, in the game server, second transmission information that permits / prohibits transmission of the login operation request for each player,
When the second transmission information before Symbol second player indicates the prohibition for the first player, back to the first game device said first message without sending the login operation request to the second game device The game management method according to claim 2 , further comprising a step of : From the second game device to the front Symbol login operation request when the login operation rejected is sent back, including the step of returning the second message to the first game device, according to any one of claims 1 to 3 Game management method.   The game management method according to claim 1, wherein the game server includes identification information that can identify the first player in the login operation request. Each of the players can register personal information with the game server,
When receiving the second selection signal for selecting a pre-Symbol second player from the first game device, comprising the step of returning the personal information of the second player in the first game device, of claims 1 to 5 The game management method according to any one of the above. Before Symbol Already third player who is logged to log in the first player and the second character signal indicating the second character the first character signal indicating the first character second player operates the first player operation wherein the but a step to read out a third character signal indicative of a third character operated from the memory, as the display mode of the second character in the first game device is different from the first character and the third character a step of adding the player information to the second character signal, the step of transmitting the second character signal the player information and the first character signal is added as a third character signal to the first game device A game management method according to any one of claims 1 to 6, further comprising : In a game server that provides a game to a first game device of a first player who has logged in through a communication network among a plurality of pre-registered players,
Transmitting means for transmitting player information indicating the second player who has not logged in among the plurality of players to the first game device; and a selection signal for selecting the second player is received from the first game device. A game server comprising a transmission means for transmitting a login operation request to the second game device of the second player. In a game device operated by a player who logs in to a game server through a communication network,
Player information receiving means for receiving, from the game server, player information indicating a specific player who has been registered in advance when logging into the game server and has not logged into the game server;
Guiding means for guiding selection of the specific player based on the player information;
Request means for requesting the game server to transmit a log-in operation request to the specific player when the specific player is selected, and log-in for receiving the log-in operation request from the game server when not logging into the game server A game device comprising operation request receiving means. In a game program to be executed by a game device operated by a player who logs in to a game server through a communication network,
A player information receiving step of receiving, from the game server, player information indicating a specific player who has been registered in advance when logging in to the game server and has not logged in to the game server;
A selection guidance step for guiding the selection of the specific player based on the player information;
A requesting step for requesting the game server to transmit a login operation request to the specific player when the specific player is selected, and a login for receiving the login operation request from the game server when not logging in to the game server A game program comprising an operation request receiving step. In a storage medium storing a game program to be executed by a game device operated by a player who logs in to a game server through a communication network,
The game program is
A player information receiving step of receiving, from the game server, player information indicating a specific player who has been registered in advance when logging in to the game server and has not logged in to the game server;
A selection guidance step for guiding the selection of the specific player based on the player information;
A requesting step for requesting the game server to transmit a login operation request to the specific player when the specific player is selected, and a login for receiving the login operation request from the game server when not logging in to the game server A storage medium comprising an operation request receiving step. In a game system operated by a player who logs in to a game server through a communication network,
Player information receiving means for receiving, from the game server, player information indicating a specific player who has been registered in advance when logging into the game server and has not logged into the game server;
Guiding means for guiding selection of the specific player based on the player information;
Request means for requesting the game server to transmit a login operation request to the specific player when the specific player is selected; and
A game system comprising: a login operation request receiving means for receiving the login operation request from the game server when not logged in to the game server .

Images