WO2018042468A1 - ゲームシステム、ゲーム処理方法、ゲームプログラム、およびゲーム装置 - Google Patents

ゲームシステム、ゲーム処理方法、ゲームプログラム、およびゲーム装置 Download PDF

Info

Publication number
WO2018042468A1
WO2018042468A1 PCT/JP2016/004003 JP2016004003W WO2018042468A1 WO 2018042468 A1 WO2018042468 A1 WO 2018042468A1 JP 2016004003 W JP2016004003 W JP 2016004003W WO 2018042468 A1 WO2018042468 A1 WO 2018042468A1
Authority
WO
WIPO (PCT)
Prior art keywords
game
player
battle
parameter
index data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2016/004003
Other languages
English (en)
French (fr)
Inventor
秀樹 紺野
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nintendo Co Ltd
Original Assignee
Nintendo Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nintendo Co Ltd filed Critical Nintendo Co Ltd
Priority to JP2017534762A priority Critical patent/JP6442061B2/ja
Priority to PCT/JP2016/004003 priority patent/WO2018042468A1/ja
Priority to US15/668,860 priority patent/US10729982B2/en
Publication of WO2018042468A1 publication Critical patent/WO2018042468A1/ja
Anticipated expiration legal-status Critical
Priority to US16/913,622 priority patent/US11298620B2/en
Ceased legal-status Critical Current

Links

Images

Classifications

    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/79—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
    • A63F13/795—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories for finding other players; for building a team; for providing a buddy list
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/20—Input arrangements for video game devices
    • A63F13/21—Input arrangements for video game devices characterised by their sensors, purposes or types
    • A63F13/214—Input arrangements for video game devices characterised by their sensors, purposes or types for locating contacts on a surface, e.g. floor mats or touch pads
    • A63F13/2145—Input arrangements for video game devices characterised by their sensors, purposes or types for locating contacts on a surface, e.g. floor mats or touch pads the surface being also a display device, e.g. touch screens
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/40—Processing input control signals of video game devices, e.g. signals generated by the player or derived from the environment
    • A63F13/42—Processing input control signals of video game devices, e.g. signals generated by the player or derived from the environment by mapping the input signals into game commands, e.g. mapping the displacement of a stylus on a touch screen to the steering angle of a virtual vehicle
    • A63F13/426—Processing input control signals of video game devices, e.g. signals generated by the player or derived from the environment by mapping the input signals into game commands, e.g. mapping the displacement of a stylus on a touch screen to the steering angle of a virtual vehicle involving on-screen location information, e.g. screen coordinates of an area at which the player is aiming with a light gun
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/40—Processing input control signals of video game devices, e.g. signals generated by the player or derived from the environment
    • A63F13/44—Processing input control signals of video game devices, e.g. signals generated by the player or derived from the environment involving timing of operations, e.g. performing an action within a time slot
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/45—Controlling the progress of the video game
    • A63F13/46—Computing the game score
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/50—Controlling the output signals based on the game progress
    • A63F13/52—Controlling the output signals based on the game progress involving aspects of the displayed game scene
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/79—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
    • A63F13/798—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories for assessing skills or for ranking players, e.g. for generating a hall of fame
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/80—Special adaptations for executing a specific game genre or game mode
    • A63F13/822—Strategy games; Role-playing games

Definitions

  • the present invention relates to a competitive game system and the like, and more particularly, to a game system using a player rate in a competitive game.
  • Patent Document 1 a numerical value representing the play ability of the player, which is the strength of play, is used as the ability rating. Then, the players whose ability ratings are antagonistic are selected and determined as opponents to play against.
  • the rate is simply used to select an opponent.
  • an object of the present invention is to provide an unprecedented new game system using the above rate.
  • An example of the configuration example is a game system that executes a game process including a battle game in which a battle with another player is played and a training game in which a predetermined training target is trained, and includes a battle game processing unit, index data storage, and the like.
  • a game system comprising means, index updating means, determination means, first parameter changing means, and presenting means.
  • the battle game processing means executes a battle game process with another player.
  • the index data storage means stores index data that fluctuates according to the result of the player's victory or defeat in the battle game by the battle game processing means.
  • the index updating means updates the index data based on the result of the player winning or losing in the battle game by the battle game processing means.
  • the determination unit determines whether or not the index data satisfies a predetermined condition.
  • the first parameter changing unit changes the first parameter associated with the first object included in the predetermined breeding target.
  • the presenting means presents an image of the first object that reflects the changed parameter to the player.
  • the object here includes the meaning of an object group composed of a plurality of objects.
  • the game system may further include game selection means for selectively executing a battle game and a breeding game.
  • the index data may be a rate (sometimes referred to as a rating) indicating a player's game ability with a predetermined value.
  • the skill and ability of the player's game can be reflected in a game element that nurtures a predetermined object, for example. Further, the player's efforts in the battle game can be visually presented to the player. Thereby, the motivation with respect to a player's game can be improved synergistically.
  • the index updating means performs either one of the increase or decrease of the index data value in response to the victory of the battle game result player, and the battle game result player has lost.
  • the other of the increase or decrease of the value of the index data may be performed.
  • the value of the index data is a value that increases or decreases according to the result of the player's victory or defeat in the battle game, and the index update means increases the value of the index data when the player wins as a result of the battle game, When defeated, the value of the index data may be decreased.
  • the index can be presented to the player in an easily understandable manner.
  • the game system may further include selection means for selecting another player having a value close to the player's index data as an opponent in the battle game process.
  • the selection means may select a plurality of opponents as battle candidates, and the game system is a candidate for displaying the plurality of battle candidates so that the player can select any one of the plurality of battle candidates.
  • You may further provide the display means and the opponent selection means which selects either of several battle candidates based on operation of a player.
  • the determination unit may be configured to determine that a predetermined condition is satisfied when the value of the index data exceeds a predetermined threshold.
  • the first parameter changing unit may change the first parameter without requiring the player's operation when it is determined that the index data satisfies a predetermined condition.
  • the presenting means may change the appearance of the predetermined object based on the change of the first parameter and present it.
  • the game system changes a second parameter, which is a parameter associated with the second object included in the predetermined breeding target and is different from the first parameter, based on the operation of the player
  • Second parameter changing means may be further provided.
  • the presenting means may further present the image of the second object based on the second parameter changed by the second parameter changing means to the player.
  • the second parameter may be changed based on the player's operation by the second parameter changing means.
  • the value of the first parameter may be the value before the change by the first parameter changing unit even if the index data once satisfies a predetermined condition and then does not satisfy the predetermined condition due to a change in the index data. It may not be returned to the value.
  • the battle game processing means determines the victory or defeat by comparing the scores of the player and the opponent in the battle game, and the index update means determines the fluctuation amount of the index data based on the player score. It may be determined. Alternatively, the index update means may determine the amount of change in the index data based on the opponent's score.
  • the index decreases by an amount based on one's own score, and when winning, the index can be increased by an amount based on the opponent's score.
  • the index can be increased by an amount based on the opponent's score.
  • the game system further includes battle parameter changing means for changing a battle game parameter used in the battle game process based on the first parameter changed by the first parameter changing means. Also good.
  • the predetermined breeding target may be a city composed of a plurality of objects
  • the first object may be an object that can be arranged in the city.
  • FIG. 1 is a schematic diagram showing an overall image of a game system which is an example of the present embodiment.
  • FIG. 2 is a functional block diagram of the smart device 102.
  • FIG. 3 is a functional block diagram of the server 101.
  • FIG. 4 is an example of a game screen in the game processing of this embodiment.
  • FIG. 5 is an example of an opponent selection screen.
  • FIG. 6 is an example of a play screen for a battle game.
  • FIG. 7 is an example of the result screen.
  • FIG. 8 is a diagram illustrating an example of the growth of the castle object 203.
  • FIG. 9 is a diagram illustrating an example of the growth of the castle object 203.
  • FIG. 10 is a diagram illustrating an example of the growth of the castle object 203.
  • FIG. 10 is a diagram illustrating an example of the growth of the castle object 203.
  • FIG. 11 is a diagram illustrating an example of programs and information stored in the main memory 123 of the server 101.
  • FIG. 12 is a diagram illustrating an example of programs and information stored in the main memory 113 of the smart device 102.
  • FIG. 13 is a flowchart showing details of the game processing according to the present embodiment.
  • FIG. 14 is a flowchart showing details of the town screen generation processing.
  • FIG. 15 is a flowchart showing details of the battle game process.
  • FIG. 16 is a flowchart showing details of the result processing.
  • FIG. 17 is a diagram illustrating another example of a city area.
  • FIG. 18 is a diagram illustrating another example of a city area.
  • FIG. 19 is a diagram illustrating another example of a city area.
  • FIG. 20 is a diagram illustrating another example of a program and information stored in the main memory 113 of the smart device 102.
  • FIG. 1 is a schematic diagram showing an overall image of the game system according to the present embodiment.
  • a game system 100 according to the present embodiment includes a server 101 and a plurality of portable smart devices 102 (hereinafter simply referred to as smart devices) which are examples of information processing apparatuses.
  • the smart device 102 is, for example, a smartphone or a tablet machine.
  • the server 101 and the smart device 102 are configured to be able to communicate via the Internet.
  • FIG. 2 is a functional block diagram of the smart device 102.
  • the smart device 102 includes a processor unit 111, an internal storage device 112, a main memory 113, a communication unit 114, an operation unit 115, and a display unit 116.
  • the processor unit 111 controls the operation of the smart device 102 by executing a system program (not shown) for executing information processing to be described later and controlling the overall operation of the smart device 102.
  • the processor unit 111 may be mounted with a single processor or a plurality of processors.
  • the internal storage device 112 stores various programs executed by the processor unit 111 and various data used by the programs.
  • the internal storage device 112 is, for example, a flash EEPROM or a hard disk device.
  • the main memory 113 temporarily stores computer programs and information.
  • the communication unit 114 is connected to a network by wired or wireless communication, and transmits / receives predetermined data to / from the server 101.
  • the operation unit 115 is an input device for receiving an operation from a user, for example.
  • the display unit 116 is typically a liquid crystal display device. In the processing according to the present embodiment, a touch panel integrated with a liquid crystal screen is assumed as the operation unit 115 and the display unit 116. In another embodiment, a predetermined pointing device other than the touch panel may be used as the operation unit 115.
  • FIG. 3 is a functional block diagram of the server 101.
  • the server 101 includes at least a processor unit 121, an internal storage device 122, a main memory 123, and a communication unit 124.
  • the processor unit 121 executes various programs for controlling the server 101.
  • the internal storage device 122 stores various programs executed by the processor unit 121 and various data used.
  • the main memory 123 temporarily stores computer programs and information.
  • the communication unit 124 is connected to a network by wired or wireless communication, and transmits / receives predetermined data to / from the smart device 102 and other servers (not shown).
  • the game process according to the present embodiment is a game process having two different game elements, that is, a battle-type action game and a training game for training a predetermined training target. Further, in this game, it is possible to selectively execute a battle-type action game and a breeding game. In this game, the player battles with other players in the battle-type action game, and a value called “rate” increases or decreases according to the result of winning or losing. Then, based on this rate, the predetermined breeding target breeding process is executed. That is, it is a game in which the rate is reflected on the degree of training of the training target.
  • the rate in the present embodiment is a numerical value representing the skill and ability of the player's game. That is, it is a value that serves as an indicator of the skill and ability of the player. For example, it is assumed that the rate is indicated by 10 levels of 1 to 10. Further, it is assumed that the initial rate when the game is newly started is “5”. And if a battle play is performed and it wins, a rate will be increased by one. If the player loses, the rate is reduced by one. Therefore, if it continues to win, the rate will eventually be “10”, and if it continues to lose, the rate will eventually be “1”.
  • the rate in the present embodiment is a value that increases or decreases in accordance with the result of winning or losing the competitive game, and is a value that has an indicator significance for the skill of the player.
  • the rate is indicated as the number of resident characters (population in the town) described later.
  • FIG. 4 is an example of a game screen in the game processing according to the present embodiment.
  • the screen is a screen corresponding to a so-called “home screen” in this game.
  • the screen includes two display areas, a town area 201 and a menu area 202.
  • a castle object 203 is displayed in the city area 201.
  • “town” is a term having the meaning of “kingdom” of the player.
  • two button images 204A and 204B are displayed.
  • the button image 204A is a button image for playing the action game as described above alone.
  • the button image 204B is a button image for playing the action game in a battle format with other players. That is, it is possible to selectively execute a battle-type action game from the home screen.
  • a battle play is performed in a one-to-one format using a side-scroll type jump action game. It is a game that wins by acquiring more coins arranged in the stage within the time limit.
  • an example of a side scroll type jump action game is shown, but any game may be used as long as it is a battle game.
  • a race game or a fighting fighting game may be employed, and not only an action game but also a table game such as a card game or a quiz game may be employed.
  • FIG. 4 when the player taps the button image 204 ⁇ / b> B, an instruction that the player wants to play is transmitted to the server 101.
  • the server 101 performs an opponent selection process (matching process). Then, the result is transmitted from the server 101, and based on this, an opponent selection screen as shown in FIG. 5 is displayed.
  • the selection is performed using the rate as described above.
  • the server 101 executes a process of randomly selecting another player with a rate close to that of the player. In other words, the selection is made so that the players can compete against each other to some extent.
  • player information is displayed on the upper left of the screen, and opponent candidate information for five players is shown in a list on the right side of the screen.
  • opponent candidate information for five players is shown in a list on the right side of the screen.
  • a player name As information of each candidate, a player name, an image related to the player (for example, a portrait image), and a rate are shown.
  • the player can start a battle play with the opponent by tapping any opponent from the battle candidates.
  • only one person may be selected without selecting a plurality of opponent candidates as described above.
  • the opponent selection screen is not displayed, and if an opponent is selected, the opponent's information may be displayed to start the opponent play.
  • the battle in this embodiment is not a real-time battle, but an asynchronous battle. Specifically, it is a format in which it is played against so-called “ghost data”.
  • the ghost data of the candidate player is downloaded from the server 101.
  • information indicating the configuration of the stage that has been played, information indicating the content of the play (what operation the opponent has performed), the number of coins acquired by the player, and the number of resident characters described later are indicated. Information etc. are included.
  • a game stage virtual game space
  • the player plays the stage.
  • the ghost data as described above is appropriately generated based on the content of play when the above-mentioned action game is played alone, and is uploaded to the server 101.
  • a real-time battle game that does not use ghost data as described above may be employed.
  • FIG. 6 shows an example of the play screen of the action game (match game). As described above, this action game is a side scroll type jump action game. In the game screen shown in FIG. 6, a player character 221 and a coin 222 are shown. Moreover, although illustration is abbreviate
  • a “resident character” can be obtained separately from the coin by satisfying a predetermined condition in the course of progressing the course.
  • the resident character is a character positioned as a resident of the castle object 203 described above.
  • the number of the resident characters is related to the growth (growth) of the castle object. That is, at the beginning of a new game, there is only one resident character, and the player can collect (increase the number of) resident characters by repeating the battle play.
  • the number of resident characters in other words, the population of the city
  • the castle object 203 grows (specifically, the appearance changes). The growth of the castle object 203 will be described later.
  • FIG. 7 a result screen as shown in FIG. 7 is displayed.
  • information on the player is shown in the upper half of the screen, and information on the opponent is shown in the lower half.
  • a player name, an image 231A related to the player, a resident character 233A collected by the player, and a coin count 232A collected by the player are displayed as information related to the player.
  • a simple replay area 234A is also displayed. In this display area, the play contents of the player are simply replay displayed.
  • an image 231B about the opponent, a resident character 233B collected by the opponent, and a coin count 232B collected by the opponent are displayed.
  • a simple replay area 234B in which the play content of the opponent is displayed in a simple replay is also displayed. Note that, when the result screen is displayed, data indicating the result of the battle play at that time may be uploaded to the server 101.
  • the winning or losing of the match is determined by the number of coins collected.
  • the player has collected 61 coins and the opponent has collected 106 coins. For this reason, in the example of this figure, it is determined that the opponent has won.
  • the following processes according to the result of winning / losing are performed. First, when the player “wins”, the resident character 233B collected by the opponent can be acquired. That is, you can increase the population of your city. On the other hand, when the player is “defeated”, the amount of the resident characters 233A collected by the player in the play is subtracted from the current city population.
  • the number of resident characters that is, the population of the city corresponds to the above-described rate. That is, it is a parameter that increases or decreases depending on the result of the match. Furthermore, when the player loses, the number of resident characters decreases based on his play results (the number of resident characters he collects), and when he wins, the opponent's play results (the opponent's It can be said that it increases based on the number of collected resident characters. That is, it can be said that the resident character is a parameter that increases or decreases based on the play result of either one of the player or the opponent. In another embodiment, the increase / decrease value of the resident character may be determined based on both the own play result and the opponent's play result.
  • the increase / decrease in the resident character affects only the player and does not affect the opponent. That is, even if the player wins and acquires the resident character of the opponent, the number of resident characters is not subtracted from the data of the opponent. Conversely, even if the player loses and the number of resident characters decreases, the reduced amount is not added to the resident character of the opponent.
  • this embodiment is an asynchronous battle using ghost data, and it is assumed that the same ghost data is downloaded to a large number of players. Therefore, the opponent's data is not affected. I am trying not to.
  • FIG. 8 shows the castle object 203 immediately after the game is newly started.
  • the castle object 203 in this state is in a considerably small state.
  • the castle object 203 in this state is referred to as a “rank 1” castle.
  • the appearance of the castle object 203 changes as shown in FIG.
  • the scale of the castle object 203 is larger than that of FIG. This change in appearance automatically changes when, for example, the number of resident characters exceeds 100.
  • the player does not spend a predetermined point, for example, to grow the castle object 203, but automatically grows when a predetermined condition is satisfied.
  • the castle object 203 in the state of FIG. 9 is referred to as a “rank 2” castle.
  • the appearance of the castle object 203 is further improved as shown in FIG. Change.
  • the scale of the castle object 203 is larger than that of FIG.
  • the castle object 203 in the state of FIG. 10 is referred to as a “rank 3” castle.
  • the castle object 203 grows.
  • the number of resident characters has the significance of the above rate, and there is also an aspect in which the player's skill and effort are shown. Therefore, the better the game, the larger the scale of the castle object 203 can be. In other words, it can be said that the skill and effort of the player in the battle action game are visually reflected in the form of the castle object 203 and presented to the player. Therefore, the player's motivation for the game can be further improved.
  • the growth degree of the castle object 203 differs for every player. That is, the castle object 203 is different for each player. In the above example, the growth example of the three-stage castle object 203 is shown, but it goes without saying that the number of growth stages may be increased and subdivided.
  • the castle object 203 once grown does not return to the previous rank state.
  • the number of resident characters increases / decreases depending on the result of the battle, so that once the number of resident characters reaches 100, it may decrease to 90.
  • the “rank” it does not return to the “1” state, and the “rank 2” state is maintained.
  • the degree of growth of the castle object and the number of resident characters are not completely linked (integrated).
  • the rank of the castle object 203 also decreases, and the player's motivation for battle play decreases. Therefore, even if the number of resident characters is reduced as described above, the degree of growth of the castle object 203 is maintained to maintain the player's motivation.
  • FIG. 11 shows an example of programs and information stored in the main memory 123 of the server 101.
  • the main memory 123 of the server 101 stores a selection processing program 301, a player database 302, battle ghost data 303, and the like.
  • the selection processing program 301 is a program for selecting an opponent in response to a request from the smart device 102.
  • the player database 302 is a database in which information about players who are playing this game is stored. Specifically, data such as an ID for identifying each player, the number of resident characters (ie, rate), the current castle rank, and the like are stored in association with each player.
  • the ghost data 303 for battle is ghost data used in the battle play as described above, and ghost data relating to a plurality of players is stored.
  • the battle ghost data is appropriately generated based on the content of play when the action game is played alone, and is uploaded to the server 101 and stored.
  • the ghost data 303 for battle includes, for example, data indicating the player ID related to the ghost data, data indicating the configuration of the game stage, the number of coins acquired, the number of acquired resident characters, and the like.
  • FIG. 12 shows an example of programs and information stored in the main memory 113 of the smart device 102.
  • the main memory 113 includes a game processing program 321, operation data 322, resident character count data 323, current castle rank data 324, castle object data 325, rank-up condition definition data 326, action stage data 327, battle work data 328. Etc. are stored.
  • the game processing program 321 is a program for executing the game processing as described above. Specifically, it is a program for executing the flowchart processing of FIG.
  • the operation data 322 is data indicating various operations performed on the smart device 102.
  • the operation data 322 includes button data and touch panel data. These data are data indicating the contents of operations performed on the operation unit 115, and are data indicating the pressed state of various buttons, touch coordinates of the touch panel, touch duration, and the like.
  • the resident character number data 323 is data indicating the number of resident characters (population in the city) as described above. This data also has significance as the above-mentioned rate.
  • the current castle rank data 324 is data indicating the degree of growth of the castle object 203.
  • the degree of growth of the castle object 203 is indicated by the concept of “rank” as described above.
  • the castle object data 325 is image data or model data used to draw the castle object 203.
  • the castle object data 325 stores image data of the castle object 203 corresponding to the “rank”.
  • Rank-up condition definition data 326 is data defining conditions for growing the castle object 203 (raising the rank). For example, it is data in which a condition such as “grow to rank 2 when the number of resident objects becomes 100 or more in the state of rank 1” is defined.
  • the action stage data 327 is various data for constructing a virtual game space for the action game as described above. That is, model data of various terrain objects, enemy characters, player characters, and the like are included.
  • the battle work data 328 is data that is temporarily generated and used when the battle game as described above is executed.
  • the battle work data 328 includes acquired coin count data 329, acquired resident count data 330, opponent ghost data 331, stage data 332, and the like.
  • the acquired coin count data 329 is data indicating the number of coins acquired by the player during the battle play as described above.
  • the acquired number-of-residents data 330 is data indicating the number of resident characters acquired by the player during the battle play.
  • the opponent ghost data 331 is data in which the above-mentioned opponent ghost data 303 relating to the opponent is downloaded from the server 101 and stored. The content is the same as that of the ghost data 303 for battle.
  • the stage data 332 is data indicating the configuration of the virtual game space generated based on the opponent ghost data 331. That is, it is data indicating the layout of terrain objects, enemy characters, coins, resident characters, and the like.
  • FIG. 13 is a flowchart showing details of the game process.
  • step S1 the processor unit 111 executes an initial process.
  • initialization of various data login processing, processing for acquiring data necessary for game processing from the server 101, and the like are executed.
  • the current resident character count is acquired from the player database 302 and stored in the main memory 113 as the resident character count data 323, or data indicating the current castle rank is acquired and the main castle rank data 324 is stored in the main memory.
  • stored in 113 are performed.
  • step S2 the processor unit 111 executes a town screen generation process. That is, processing for generating an image to be displayed in the city area 201 of FIG. 4 is executed.
  • FIG. 14 is a flowchart showing details of the city screen generation processing.
  • the processor unit 111 acquires current castle rank data 324 from the main memory 113 in step S ⁇ b> 11.
  • step S ⁇ b> 12 the processor unit 111 acquires the resident character number data 323 from the main memory 113.
  • step S ⁇ b> 13 the processor unit 111 refers to the rank-up condition definition data 326 and determines whether a condition for growing the castle object 203, that is, a rank-up condition is satisfied.
  • step S14 the processor unit 111 updates the current castle rank data 324 to the content indicating the rank after rank-up ( Note that the current castle rank data 324 updated here is also transmitted to the server 101 as appropriate, and the contents of the player database 302 are also updated as appropriate.
  • the rank-up condition is not satisfied (NO in step S13)
  • the process in step S14 is skipped.
  • step S15 the processor unit 111 acquires the current castle rank data 324 again, and acquires image data of the castle object 203 corresponding to the content from the castle object data 325.
  • step S16 the processor unit 111 generates an image of the castle object 203 based on the acquired image data and the like. This is the end of the city screen generation process.
  • step S3 the processor unit 111 generates and displays the home screen as shown in FIG. 4 based on the generated image of the castle object 203 and the like.
  • step S4 the processor unit 111 acquires the operation data 322.
  • step S ⁇ b> 5 the processor unit 111 determines whether or not the start of the battle is selected based on the operation data 322. That is, it is determined whether or not the button image 204B is tapped on the screen of FIG. As a result of the determination, when the start of the battle is selected (YES in step S5), the processor unit 111 executes a battle game process in step S6.
  • FIG. 15 is a flowchart showing details of the battle game process.
  • the processor unit 111 executes a selection process for searching for an opponent. Specifically, a request for the selection process is transmitted to the server 101 together with information such as the resident character count data 323 (ie, rate) of the player.
  • the player database 302 is referred to, and five players are randomly extracted from the players with the closest number of resident characters. Then, data indicating the extraction result is transmitted from the server 101 to the smart device 102.
  • the selection process ends.
  • step S22 the processor unit 111 executes a process of generating and displaying an opponent selection screen as shown in FIG. 5 based on the data indicating the extraction result received from the server 101. Then, when the player performs an operation for selecting a predetermined opponent on the screen, the processor unit 111 executes an action game process in step S23.
  • the process will be described more specifically.
  • a process of acquiring the ghost data 303 for battle for the selected opponent from the server 101 is executed.
  • a virtual game space (game stage) is generated based on the battle ghost data 303, and various characters such as player characters are also arranged.
  • a game screen is displayed, and an action game process based on the player's operation is appropriately executed. In this process, the contents of the acquired coin number data 329 and the acquired inhabitant number data 330 are updated as appropriate.
  • FIG. 16 is a flowchart showing details of the result processing.
  • the processor unit 111 performs a battle win / loss determination based on the acquired coin count data 329 and the data on the acquired coin count of the opponent included in the opponent ghost data 331.
  • step S32 the processor unit 111 determines whether or not the player wins as a result of the win / loss determination. If the result of the determination is that the player is victorious (YES in step S32), in step S33, the processor unit 111 determines the number of resident characters acquired by the opponent indicated by the opponent ghost data 331 as the resident character number data 323. Add to. On the other hand, when the player is defeated (NO in step S32), in step S34, the processor unit 111 subtracts the number indicated by the acquired resident number data 330 from the resident character number data 323 (note that it is updated here). The resident character number data 323 is also transmitted to the server 101 as appropriate, and the contents of the player database 302 are also updated as appropriate).
  • step S35 the processor unit 111 generates and displays a result screen as shown in FIG. As a result, the result processing is completed.
  • step S ⁇ b> 5 if the result of determination in step S ⁇ b> 5 is that a match has not been selected (NO in step S ⁇ b> 5), the processor unit 111 appropriately performs other game processing based on operation data 322 in step S ⁇ b> 7. Execute. For example, execution of an action game process for one person is performed.
  • step S8 the processor unit 111 determines whether or not a condition for ending the game is satisfied. If the condition is not satisfied (NO in step S8), the process returns to step S2. Repeat the process. If the condition is satisfied (YES in step S8), the game process ends. Above, description of the game process concerning this embodiment is complete
  • the player enjoys the battle in the action game, and at the same time, the rate (the number of resident characters) is increased or decreased according to the battle result, and this rate is reflected in the growth of the castle object 203. ing.
  • the index (rate) indicating the prowess, ability and effort of the player also has significance as a criterion for the growth factor, thereby motivating the player to play both the battle action game and the castle object 203. It can improve synergistically.
  • the index indicating the skill of the player as described above and the element serving as the reference for the growth element are unified as the “resident character”, it can be presented in a form that is easy for the player to understand.
  • FIG. 17 shows an example of an image of the city area 201 in such a case.
  • FIG. 17 there is a central area 251 in which the castle object 203 is displayed in the central part of the city area 201.
  • twelve rectangular areas (hereinafter referred to as peripheral areas) 252 indicated by dotted lines are shown surrounding the periphery.
  • peripheral areas twelve rectangular areas (hereinafter referred to as peripheral areas) 252 indicated by dotted lines are shown surrounding the periphery.
  • the appearance corresponds to the current castle rank data 324.
  • an arbitrary one of the 12 surrounding regions 252 is determined based on the player's operation.
  • the building objects may be arranged (see FIG. 18). For example, when the player taps an arbitrary area from among the 12 surrounding areas 252, a screen for selecting a building object to be arranged in that area may be displayed. Further, even when the castle object 203 has grown from the “rank 2” state to the “rank 3”, a predetermined building object may be arranged in another area (see FIG. 19).
  • a predetermined building object is selected based on the player's operation for any one of the 12 surrounding areas 252. May be arranged. For example, when the number of resident characters is 50 or more, building objects can be arranged in any one area. Thereafter, when the number of resident characters becomes 100 or more, building objects may be arranged in another area. That is, as the number of resident characters increases, a predetermined building object may be arranged in a step-by-step manner on the 12 peripheral areas 252 one by one based on the player's operation. In other words, just because the number of resident characters increases, it is not automatically arranged.
  • the castle object 203 automatically grows, but the surrounding area 252 has a configuration in which the player needs to manually install the building object.
  • two types of objects that is, the castle object 203 and the building object in which the peripheral area 252 can be arranged as described above, may be included as the “town” as a training target. It can be said that the growth of the castle object 203 and the arrangement with the building objects are part of the development of the “town”.
  • the castle object 203 and the object arranged in the peripheral area 252 are examples arranged in different areas.
  • the arrangement is not limited to the case where these two types of objects are arranged in different areas, and may be arranged such that one is included in the other area.
  • an area “room” may be prepared inside the castle object 203, and another object (furniture object or the like) may be placed in this “room”. In this case, the number of “rooms” inside the castle may be increased as the castle object 203 grows.
  • the peripheral area data 341 in FIG. 20 includes first area data 342A to twelfth area data 342L corresponding to the 12 peripheral areas 252.
  • Each area data 342 includes information indicating whether or not a building object is arranged in the area, information indicating the arranged building object itself, and the like. Then, it is assumed that each area data 342 cannot be changed at first, and each area data 342 can be changed step by step (based on the user's operation) as the number of resident characters increases. You can do it. Then, based on the contents of each area data 342, a building object different from the castle object 203 may be additionally displayed in the corresponding peripheral area 252. Thereby, it becomes possible to raise interest property further about the upbringing of a town.
  • the nurturing target may be, for example, a tower type object in addition to the castle object 203 as described above.
  • the height of the tower may be increased as the number of resident characters increases.
  • the “town” to be trained does not include the castle object 203 as described above, but includes various objects such as road objects and vehicle objects in addition to building objects such as a plurality of house objects and store objects. It may be a city composed of different types of objects.
  • the training target is not limited to the form of “town”, and for example, as long as a plurality of objects are arranged in a predetermined area such as a city, a village, an island, a room, etc. Form may be sufficient.
  • an object having a creature as a motif may be used as a training target as another training target.
  • a predetermined animal object or person object may be displayed as a training target.
  • the growth direction may be changed according to the content of play in the action game. For example, some types of the resident characters are allowed to appear. As an example, it is assumed that three types of resident characters “type A resident”, “type B resident”, and “type C resident” are defined. Each resident character number is increased or decreased according to the result of the battle, as in the above-described process. Then, the growth content of the castle object 203 may be varied according to the type ratio of the resident character acquired by the player in the action game. That is, the appearance of the castle object 203 in the same “rank 2” state may be made different depending on the ratio of the resident character type. For example, assuming that there are 100 resident characters, the appearance of the castle object 203 in the “rank 2” state when 80 of them are “type A residents” and when 80 are “type B residents”. May be different.
  • a plurality of growth parameters may be set for the castle object 203, and the degree of influence on the growth parameters may be varied depending on the plurality of types of resident characters. For example, three parameters, a parameter A relating to the color of the castle object, a parameter B relating to the shape, and a parameter C relating to the size, are set as parameters affecting the appearance of the castle object 203. . Then, at the end of each action game (at the result screen), the value of each parameter may be changed according to the number of resident characters of each type acquired at that time. For example, the number of type A residents is added to parameter A, the number of type B residents is added to parameter B, the number of type C residents is added to parameter C, and so on.
  • the appearance of the upgraded castle object 203 may be changed based on the three parameters.
  • the parameters may be changed based on factors other than the above-described rate (number of resident characters). For example, you may make it change a parameter based on the play time of a game, or the total number of wins in a competitive game.
  • some parameters may be changed at random. For example, the parameter C related to the size of the castle object 203 changes based on the number of resident characters, but the parameters A and B related to the color and shape of the castle object 203 may be changed randomly.
  • the total population of these types of resident characters may be used as the rate, or the population of each type of resident character may be used as the rate. It may be used (in the latter case, multiple types of rates are used).
  • the winning / losing determination of the action game is determined based on the number of acquired coins, but in other embodiments, the winning / losing determination may be made based on the number of acquired resident characters without using coins. Good.
  • the rate (the number of resident characters), that is, the index indicating the player's skill is indicated by a numerical value.
  • the index may be indicated by a value other than a numerical value.
  • the “increase” and “increase” of the index means that the index changes to an index indicating higher skill (for example, when “B +” changes to “A”).
  • the “decrease” and “decrease” of the index means that the index changes to an index indicating lower proficiency (for example, when “B +” changes to “B”).
  • the “increase” and “increase” of the index correspond to the case where the “third stage” changes to “second stage”.
  • “down” and “decrease” of the index correspond to a case where “3rd stage” is changed to “4th stage”.
  • a predetermined parameter associated with the player character 221 in the action game may be changed in response to the increase in the rate (the number of resident characters). For example, as the number of resident characters increases, the parameters of the player character 221 may be changed so as to obtain an advantageous effect for the player. For example, the jumping power and moving speed of the player character 221 may be increased. Alternatively, the physical strength of the player character 221 and the number of remaining machines may be increased. Alternatively, the game play time limit may be extended from the initial time. In addition, the appearance of the player character 221 may be simply changed (in this case, although an advantageous effect is not necessarily given, an apparent change can be given). More specifically, the following control may be performed.
  • the parameters as described above are prepared as data relating to the player character 221.
  • the control of directly changing the parameter of the player character 221 may be performed in accordance with the increase in the rate (the number of resident characters).
  • the rate the number of resident characters
  • the parameter associated with the castle object 203 changes, and the parameter of the player character 221 is changed based on the parameter.
  • the control may be such that the jump power of the player character 221 increases when the “height” of the castle object 203 exceeds a predetermined value.
  • the game program or the like according to the present embodiment can provide a new game process using an index indicating the player's game ability, and is useful for applications such as portable smart devices and various game devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Human Computer Interaction (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • Processing Or Creating Images (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

他のプレイヤとの対戦ゲーム処理を実行する対戦ゲーム処理手段と、対戦ゲームの勝敗結果に応じて変動する指標データを記憶する指標データ記憶手段と、当該指標データを前記プレイヤの勝敗結果に基づいて更新する指標更新手段と、指標データが所定の条件を満たしたとき、所定の育成対象に含まれる第１オブジェクトに関連づけられた第１パラメータを変更する第１パラメータ変更手段と、変更後のパラメータが反映された第１オブジェクトの画像をプレイヤに提示する提示手段とを備える、ゲームシステムである。

Description

ゲームシステム、ゲーム処理方法、ゲームプログラム、およびゲーム装置
　本発明は、対戦型ゲームシステム等に関し、より特定的には、対戦型ゲームにおけるプレイヤのレートを用いたゲームシステムに関する。
　従来から、プレイの実力が拮抗したプレイヤ同士をより適切にマッチングさせるゲームシステムが知られている（例えば特許文献１）。このようなゲームシステムでは、プレイの強さであるプレイヤのプレイ能力を数値で表したものを実力レーティングとして用いている。そして、実力レーティングが拮抗した値であるプレイヤ同士を選択して、対戦プレイをする相手として決定している。
特開２０１４－１４４３６７号公報
　上記のようなゲームシステムでは、単純に、対戦相手の選択のためにレートが用いられるに過ぎなかった。
　それ故に、本発明の目的は、上記のようなレートを利用した今までに無い新たなゲームシステムを提供することである。
　上記目的を達成するために、例えば以下のような構成例が挙げられる。
　構成例の一例は、他のプレイヤとの対戦を行う対戦ゲームと、所定の育成対象を育成させる育成ゲームとを含むゲーム処理を実行するゲームシステムであって、対戦ゲーム処理手段と、指標データ記憶手段と、指標更新手段と、判定手段と、第１パラメータ変更手段と、提示手段とを備える、ゲームシステムである。対戦ゲーム処理手段は、他のプレイヤとの対戦ゲーム処理を実行する。指標データ記憶手段は、対戦ゲーム処理手段による対戦ゲームにおける前記プレイヤの勝敗結果に応じて変動する指標データを記憶する。指標更新手段は、対戦ゲーム処理手段による対戦ゲームにおける前記プレイヤの勝敗結果に基づいて前記指標データを更新する。判定手段は、指標データが所定の条件を満たしているか否かを判定する。第１パラメータ変更手段は、所定の条件を満たしていると判定した場合、前記所定の育成対象に含まれる第１オブジェクトに関連づけられた第１パラメータを変更する。提示手段は、変更されたパラメータが反映された第１オブジェクトの画像をプレイヤに提示する。なお、ここでいうオブジェクトには、複数のオブジェクトで構成されるオブジェクト群の意味も含まれる。
　上記構成例によれば、対戦ゲームの勝敗結果に基づく指標を、対戦ゲーム以外のゲーム要素に反映することができる、新しい形態のゲームを提供することができる。
　他の構成例として、ゲームシステムは、対戦ゲームと育成ゲームとを選択的に実行するゲーム選択手段を更に備えていてもよい。
　上記構成例によれば、対戦ゲームと育成ゲームの双方に対するプレイヤのモチベーションを相乗効果的に高めることが可能となる。
　他の構成例として、指標データは、プレイヤのゲームの実力を所定の値で示すレート（レーティングと呼ばれることもある）であってもよい。
　上記構成例によれば、プレイヤのゲームの腕前や実力を、例えば所定のオブジェクトを育成するようなゲーム要素に反映することができる。また、対戦ゲームにおけるプレイヤの努力等をビジュアルでプレイヤに提示することができる。これにより、プレイヤのゲームに対するモチベーションを相乗効果的に向上させることができる。
　他の構成例として、指標更新手段は、対戦ゲームの結果プレイヤが勝利したことに応じて指標データの値の上昇または下降のうちのいずれか一方を行い、当該対戦ゲームの結果プレイヤが敗北したことに応じて指標データの値の上昇または下降のうちの他方を行うようにしてもよい。更には、指標データの値は、対戦ゲームにおけるプレイヤの勝敗結果に応じて増加または減少する値であり、指標更新手段は、対戦ゲームの結果プレイヤが勝利したときは指標データの値を増加させ、敗北したときは当該指標データの値を減少させるようにしてもよい。
　上記構成例によれば、指標についてプレイヤにわかりやすい形で提示することができる。
　他の構成例として、ゲームシステムは、プレイヤの指標データと近い値を有する他のプレイヤを対戦ゲーム処理における対戦相手として選出する選出手段を更に備えていてもよい。また、選出手段は、複数の対戦相手を対戦候補として選出してもよく、ゲームシステムは、複数の対戦候補のうちのいずれかをプレイヤが選択可能なように当該複数の対戦候補を表示する候補表示手段と、プレイヤの操作に基づいて複数の対戦候補のうちのいずれかを選択する対戦相手選択手段を更に備えていてもよい。
　上記構成例によれば、ゲームの実力が近いプレイヤ同士で対戦ゲームを行わせることができ、ゲームの興趣性を高めることができる。
　他の構成例として、判定手段は、指標データの値が所定の閾値を超えたときに、所定の条件を満たしていると判定するよう構成してもよい。
　上記構成例によれば、例えば指標の数値がどの程度の値になれば、所定のオブジェクトに関するパラメータを変更できるかについて、プレイヤに理解しやすい形で示すことが可能となる。
　他の構成例として、第１パラメータ変更手段は、指標データが所定の条件を満たしていると判定されたとき、第１パラメータをプレイヤの操作を要することなく変更してもよい。また、提示手段は、第１パラメータの変更に基づいて所定のオブジェクトの外観を変更して提示するようにしてもよい。
　上記構成例によれば、所定のオブジェクトの外観が自動的に変化するため、プレイヤに驚きを与え、また、ゲ－ムプレイへのモチベーションを高めることができる。
　他の構成例として、ゲームシステムは、所定の育成対象に含まれる第２オブジェクトに関連づけられるパラメータであって、第１のパラメータとは異なるパラメータである第２のパラメータをプレイヤの操作に基づいて変更する第２パラメータ変更手段を更に備えていてもよい。また、提示手段は、第２パラメータ変更手段によって変更された第２のパラメータに基づいた第２のオブジェクトの画像を更にプレイヤに提示するようにしてもよい。更に、指標データが所定の条件を満たしていると判定されたときに、第２パラメータ変更手段によるプレイヤの操作に基づいた第２のパラメータの変更が可能となるようにしてもよい。
　上記構成例によれば、指標を反映させるゲーム要素として、例えば、第１のオブジェクトに加えて第２のオブジェクトも提示することが可能となり、指標を反映させるゲーム要素についての興趣性をより高めることができる。
　他の構成例として、第１パラメータの値は、一旦指標データが所定の条件を満たした後、当該指標データの変動によって当該所定の条件を満たさなくなっても、第１パラメータ変更手段による変更前の値には戻らないようにしてもよい。
　上記構成例によれば、プレイヤのゲームに対するモチベーションを落とさずに維持することが可能となる。
　他の構成例として、対戦ゲーム処理手段は、対戦ゲームにおけるプレイヤと対戦相手とのスコアを比較することで勝敗の決定を行い、指標更新手段は、指標データの変動量をプレイヤのスコアに基づいて決定するようにしてもよい。あるいは、指標更新手段は、指標データの変動量を対戦相手のスコアに基づいて決定するようにしてもよい。
　上記構成例によれば、例えば、対戦ゲームに負けた場合は自分のスコアに基づく分だけ指標が減少し、勝った場合は、相手のスコアに基づく分だけ指標を増加させることができる。これにより、指標の変動についてプレイヤにわかりやすい形で提示することができる。
　他の構成例として、ゲームシステムは、第１パラメータ変更手段によって変更された前記第１パラメータに基づいて、対戦ゲーム処理において用いられる対戦ゲーム用パラメータを変化させる対戦用パラメータ変化手段を更に備えていてもよい。
　上記構成例によれば、対戦ゲームについてのモチベーションと、第１パラメータが反映される所定のオブジェクトを変化（例えば成長）させたいというモチベーションという２つのモチベーションを相乗効果的に上昇させることができ、ゲームの興趣性を更に高めることができる。
　他の構成例として、所定の育成対象は、複数のオブジェクトから構成される街であってもよく、第１オブジェクトは、当該街に配置可能なオブジェクトであってもよい。
　上記構成例によれば、例えば数々の建築物等のオブジェクトが含まれる「街」を成長させていく育成ゲームの興趣性をより高めることができる。
　本実施形態によれば、対戦ゲームの勝敗結果に基づく指標を当該対戦ゲーム以外のゲーム要素に反映することが可能な今までにない新しいゲームを提供することができる。
図１は、本実施形態の一例であるゲームシステムの全体像を示す模式図である。 図２は、スマートデバイス１０２の機能ブロック図である。 図３は、サーバ１０１の機能ブロック図である。 図４は、本実施形態のゲーム処理におけるゲーム画面の一例である。 図５は、対戦相手選択画面の一例である。 図６は、対戦ゲームのプレイ画面の一例である。 図７は、リザルト画面の一例である。 図８は、城オブジェクト２０３の成長の一例を示す図である。 図９は、城オブジェクト２０３の成長の一例を示す図である。 図１０は、城オブジェクト２０３の成長の一例を示す図である。 図１１は、サーバ１０１のメインメモリ１２３に記憶されるプログラムおよび情報の一例を示す図である。 図１２は、スマートデバイス１０２のメインメモリ１１３に格納されるプログラムおよび情報の一例を示す図である。 図１３は、本実施形態にかかるゲーム処理の詳細を示すフローチャートである。 図１４は、街画面生成処理の詳細を示すフローチャートである。 図１５は、対戦ゲーム処理の詳細を示すフローチャートである。 図１６は、リザルト処理の詳細を示すフローチャートである。 図１７は、街エリアの他の例を示す図である。 図１８は、街エリアの他の例を示す図である。 図１９は、街エリアの他の例を示す図である。 図２０は、スマートデバイス１０２のメインメモリ１１３に格納されるプログラムおよび情報の他の一例を示す図である。
　以下、本発明の一実施形態について説明する。
　図１は、本実施形態に係るゲームシステムの全体像を示す模式図である。本実施形態のゲームシステム１００は、サーバ１０１と、情報処理装置の一例である複数の携帯型スマートデバイス１０２（以下では、単にスマートデバイスと呼ぶ）とを含んでいる。スマートデバイス１０２は、例えばスマートフォンやタブレット機等である。サーバ１０１と、スマートデバイス１０２とは、インターネットを介して通信可能に構成されている。
　次に、上記システムにおける各ハードウェアの構成について説明する。図２は、スマートデバイス１０２の機能ブロック図である。図２において、スマートデバイス１０２は、プロセッサ部１１１と、内部記憶装置１１２と、メインメモリ１１３と、通信部１１４と、操作部１１５と、表示部１１６とを備えている。プロセッサ部１１１は、後述する情報処理を実行したり、スマートデバイス１０２の全体的な動作を制御したりするためのシステムプログラム（図示せず）を実行することで、スマートデバイス１０２の動作を制御する。なお、プロセッサ部１１１は、単一のプロセッサを搭載してもよいし、複数のプロセッサを搭載するようにしてもよい。内部記憶装置１１２には、プロセッサ部１１１によって実行される各種プログラムや当該プログラムで利用される各種データが格納されている。内部記憶装置１１２は、例えば、フラッシュＥＥＰＲＯＭやハードディスク装置である。メインメモリ１１３は、コンピュータプログラムや情報を一時的に記憶する。通信部１１４は、有線、または無線通信によってネットワークと接続し、上記サーバ１０１との間で所定のデータを送受信する。操作部１１５は、例えば、ユーザからの操作を受け付けるための入力装置である。表示部１１６は、典型的には液晶表示装置である。なお、本実施形態に係る処理では、操作部１１５及び表示部１１６として、液晶画面と一体化したタッチパネルを想定する。他の実施形態では、操作部１１５として、タッチパネル以外の所定のポインティングデバイスを用いてもよい。
　次に、上記サーバ１０１の構成について説明する。図３は、サーバ１０１の機能ブロック図である。サーバ１０１は、プロセッサ部１２１と、内部記憶装置１２２と、メインメモリ１２３と、通信部１２４とを少なくとも備えている。プロセッサ部１２１は、サーバ１０１を制御するための各種プログラムを実行する。内部記憶装置１２２には、プロセッサ部１２１によって実行される各種プログラムや利用される各種データが格納されている。メインメモリ１２３は、コンピュータプログラムや情報を一時的に記憶する。通信部１２４は、有線、または無線通信によってネットワークと接続し、上記スマートデバイス１０２や他のサーバ（図示せず）との間で所定のデータを送受信する。
　次に、本実施形態にかかるゲーム処理の動作概要を説明する。本実施形態にかかるゲーム処理は、対戦型アクションゲームと、所定の育成対象を育成する育成ゲームという２つの異なるゲームの要素を併せ持つゲーム処理である。また、本ゲームでは、対戦型アクションゲームと育成ゲームとを選択的に実行することが可能となっている。そして、本ゲームでは、対戦型アクションゲームにおいて他のプレイヤと対戦し、その勝敗結果に応じて「レート」と呼ばれる値が増減する。そして、このレートに基づいて、上記所定の育成対象の育成処理が実行される。すなわち、レートが育成対象の育成度合いに反映されるというゲームとなっている。
　ここで、本実施形態におけるレートについて補足説明する。本実施形態におけるレートは、プレイヤのゲームの腕前や実力を数値で表したものである。つまり、プレイヤの腕前や実力の指標となるような値である。例えば、レートが１～１０の１０段階で示されるとする。また、ゲームを新規に開始したときの初期レートが「５」であるとする。そして、対戦プレイを行い、勝利すれば、レートが１つ増加される。また、負けた場合は、レートが１つ減少される。そのため、勝ち続ければ、最終的にレートは「１０」となり、負け続ければ、最終的にレートは「１」となる。すなわち、レートが「１０」のプレイヤは、そのゲームの腕前が高いであろうことの指標となり、また、レートが「１」のプレイヤは、あまり腕前は高くないことの指標となる。このように、本実施形態におけるレートは、対戦ゲームの勝敗結果に応じて増減する値であり、プレイヤのゲームの腕前の指標的な意義を有する値である。なお、本実施形態では、当該レートは、後述する住民キャラクタの数（街の人口）として示される。
　次に、本ゲームの大まかな流れについて、図面を用いて更に説明する。図４は、本実施形態にかかるゲーム処理におけるゲーム画面の一例である。当該画面は、本ゲームにおける、いわゆる「ホーム画面」に相当する画面である。図４において、画面には街エリア２０１とメニューエリア２０２の２つの表示領域が含まれている。街エリア２０１には、城オブジェクト２０３が表示されている。なお、本実施形態では、「街」は、いわばプレイヤの「王国」という意味合いを有する用語である。そして、本実施形態では、当該「街」を育成対象としており、より具体的には、城オブジェクト２０３を上記の育成対象としている（城オブジェクトの成長＝街の成長という捉え方である）。メニューエリア２０２には、２つのボタン画像２０４Ａ、２０４Ｂが表示されている。ボタン画像２０４Ａは、上述したようなアクションゲームを一人でプレイするためのボタン画像である。ボタン画像２０４Ｂは、上記アクションゲームを他のプレイヤと対戦形式でプレイするためのボタン画像である。つまり、当該ホーム画面から、対戦型アクションゲームを選択的に実行することが可能となっている。本実施形態では、この対戦形式でアクションゲームをプレイする場合を説明する。また、本実施形態では、横スクロール型のジャンプアクションゲームを用いて、１対１の形式での対戦プレイが行われる。制限時間内に、ステージ内に配置されたコインの数をより多く獲得したほうが勝ちとなるゲームである。なお、本実施形態では、横スクロール型のジャンプアクションゲームの例を示すが、対戦ゲームであればどのようなものでもよい。他の実施形態では、例えば、レースゲームや対戦格闘ゲームを採用しても良いし、アクションゲームに限らず、例えばカードゲーム等のテーブルゲームやクイズゲームを採用しても良い。
　以下、上記のようなアクションゲームについて図面を用いて説明する。図４において、プレイヤがボタン画像２０４Ｂをタップすると、対戦プレイを希望する旨の指示がサーバ１０１に送信される。これに応じて、サーバ１０１において対戦相手の選出処理（マッチング処理）が行われる。そして、その結果がサーバ１０１から送信され、これに基づいて図５のような対戦相手の選択画面が表示される。ここで、当該選出は、上述したようなレートを利用して行われる。具体的には、プレイヤと近いレートの他のプレイヤをランダムで選択する処理がサーバ１０１において実行される。すなわち、腕前がある程度近いプレイヤ同士で対戦が行われるように選出がされる。
　図５の対戦相手選択画面では、画面左上にプレイヤの情報が表示され、画面右側に５人分の対戦相手候補情報がリスト状で示されている。各候補の情報としては、プレイヤ名、そのプレイヤに関する画像（例えば似顔絵画像）、レートが示されている。プレイヤは、当該対戦候補の中から任意の相手をタップすることで、その相手との対戦プレイを開始することができる。
　なお、他の実施形態では、上記のような複数人の対戦相手候補の選出は行わずに、一人だけ選出するようにしてもよい。この場合は、上記対戦相手選択画面は表示されず、対戦相手が選出されれば、その相手の情報を表示して対戦プレイが開始されるようにすればよい。
　ここで、本実施形態での対戦は、リアルタイム形式の対戦ではなく、非同期型で対戦プレイが行われるものとする。具体的には、いわゆる「ゴーストデータ」と対戦する形式である。上記対戦候補選択画面から任意の候補をタップすると、その候補プレイヤのゴーストデータがサーバ１０１からダウンロードされる。このゴーストデータには、プレイしたステージの構成を示す情報と、プレイ内容（対戦相手がどのような操作を行ったか）を示す情報、そのプレイヤが獲得したコイン数、および後述する住民キャラクタ数を示す情報等が含まれている。そして、スマートデバイス１０２において、当該ゴーストデータに基づいてゲームステージ（仮想ゲーム空間）が生成され、プレイヤが、当該ステージをプレイするという流れとなる。つまり、ダウンロードした対戦相手と同じステージにおいて、同じ制限時間でコインをどれだけ獲得できるか、を非同期で競う形となる。なお、上記のようなゴーストデータは、上記アクションゲームを一人でプレイしたときのプレイ内容に基づいて適宜生成され、サーバ１０１にアップロードされる。また、他の実施形態では、上記のようなゴーストデータを使わない、リアルタイム形式の対戦ゲームを採用してもよい。
　図６に、当該アクションゲーム（対戦ゲーム）のプレイ画面の一例を示す。上記のように、本アクションゲームは、横スクロール型のジャンプアクションゲームである。図６に示すゲーム画面には、プレイヤキャラクタ２２１、コイン２２２が示されている。また、図示は省略するが、敵キャラクタも存在している。プレイヤは、プレイヤキャラクタ２２１を操作して、制限時間内にコイン２２２を集めながらゲームステージを進んでいくことができる。
　ところで、本実施形態では、コースを進めていく過程で、所定の条件を満たす等することで、上記コインとは別に「住民キャラクタ」を獲得することができる。当該住民キャラクタは、上述した城オブジェクト２０３の住民という位置づけのキャラクタである。そして、当該住民キャラクタの数が、城オブジェクトの育成（成長）と関連している。すなわち、ゲームを新規に開始した当初は、住民キャラクタは１人だけであり、プレイヤは、対戦プレイを繰り返すことで、住民キャラクタを集める（数を増やす）ことができる。そして、住民キャラクタの数(換言すれば、街の人口）が増えると、城オブジェクト２０３が成長する（具体的には、外観が変化していく）。城オブジェクト２０３の成長については後述する。
　次に、対戦プレイの勝敗判定に関して説明する。上記アクションゲームをプレイし、制限時間が来ることで、上記ステージでのプレイは終了し、図７に示すようなリザルト画面が表示される。図７では、画面上半分にプレイヤに関する情報が示され、下半分に対戦相手に関する情報が示される。具体的には、プレイヤに関する情報として、プレイヤ名、プレイヤに関する画像２３１Ａ、プレイヤが集めた住民キャラクタ２３３Ａ、プレイヤが集めたコイン枚数２３２Ａが表示される。また、簡易リプレイ領域２３４Ａも表示されている。この表示領域では、プレイヤのプレイ内容が簡易的にリプレイ表示される。また、対戦相手に関する具体的な情報としては、対戦相手に関する画像２３１Ｂ、対戦相手が集めた住民キャラクタ２３３Ｂ、対戦相手が集めたコイン枚数２３２Ｂが表示される。また、対戦相手のプレイ内容が簡易的にリプレイ表示される簡易リプレイ領域２３４Ｂも表示されている。なお、当該リザルト画面の表示に際して、そのときの対戦プレイの結果を示すデータがサーバ１０１にアップロードされるように構成しても良い。
　本ゲームでは、対戦の勝敗は、集めたコイン枚数の大小で決定される。図７の例では、プレイヤが６１枚、対戦相手は１０６枚のコインを集めたことが示される。そのため、この図の例では、対戦相手の勝利と判定される。そして、上記住民キャラクタに関しては、勝敗の結果に応じた次のような処理が行われる。まず、プレイヤが「勝利」した場合は、対戦相手が集めた住民キャラクタ２３３Ｂを獲得することができる。すなわち、自分の街の人口を増やすことができる。一方、プレイヤが「敗北」した場合は、そのプレイにおいてプレイヤが集めた住民キャラクタ２３３Ａの分だけ、現在の街の人口から減算される。つまり、対戦に勝てば、相手の集めた住民キャラクタを獲得でき、敗北すれば、そのプレイで自分が集めた分の住民キャラクタを失ってしまうことになる。そして、この住民キャラクタの数、すなわち街の人口が、上述したレートに相当するものである。つまり、対戦の勝敗結果に応じて増減するパラメータである。更に言うと、住民キャラクタの数は、プレイヤが敗北したときは、自分のプレイ結果（自分が集めた住民キャラクタ数）に基づいて減少し、勝利したときは、対戦相手のプレイ結果（対戦相手が集めた住民キャラクタ数）に基づいて増加するものといえる。すなわち、住民キャラクタは、自分と対戦相手のいずれか一方のプレイ結果に基づいて増減するパラメータともいえる。なお、他の実施形態では、住民キャラクタの増減については、自分のプレイ結果および対戦相手のプレイ結果の双方に基づいてその増減値を決定するようにしてもよい。
　なお、本実施形態では、上記住民キャラクタの増減は、プレイヤに対してのみ影響し、対戦相手には影響を与えないものとする。つまり、プレイヤが勝利し、対戦相手の住民キャラクタを獲得したとしても、その対戦相手のデータから住民キャラクタの数が減算されることはないものとする。逆に、プレイヤが敗北し、住民キャラクタの数が減ったとしても、その減った分が対戦相手の住民キャラクタに加算されることもないものとする。上記のように、本実施形態ではゴーストデータを用いた非同期方式の対戦であり、同じゴーストデータが多数のプレイヤにダウンロードされることも想定されることから、対戦相手のデータにまでは影響を及ぼさないようにしている。
　次に、城オブジェクト２０３（街）の成長に関して説明する。上記のように、対戦プレイの勝敗結果に応じて、住民キャラクタ２３３の数が増減する。そして、住民キャラクタの数が増えることで、城オブジェクト２０３が成長する。図８～図１０に、城オブジェクト２０３の成長の一例を示す。図８は、ゲームを新規に開始した直後の城オブジェクト２０３を示す。この状態の城オブジェクト２０３は、その規模がかなり小さな状態となっている。以下では、この状態の城オブジェクト２０３を「ランク１」の城と呼ぶ。
　「ランク１」の状態において、上記のような対戦を繰り返し、住民キャラクタを集めた結果、例えば住民キャラクタが１００人を越えたとき、図９に示すように、城オブジェクト２０３の外観が変化する。図９の例では、城オブジェクト２０３の規模が、図８のものよりも大きくなっている。なお、この外観の変化は、例えば住民キャラクタが１００人を越えた時点で自動的に変化する。換言すれば、プレイヤが例えば所定のポイントを消費して城オブジェクト２０３を成長させる、というようなものではなく、所定条件を満たした場合に、自動的に成長するものである。以下では、図９の状態の城オブジェクト２０３を「ランク２」の城と呼ぶ。
　更に、「ランク２」の状態において、上記のような対戦を繰り返し、住民キャラクタを集めた結果、例えば住民キャラクタが５００人を越えたとき、図１０に示すように、城オブジェクト２０３の外観が更に変化する。図１０の例では、城オブジェクト２０３の規模が、図９のものよりも更に大きなものとなっている。以下では、図１０の状態の城オブジェクト２０３を「ランク３」の城と呼ぶ。
　このように、住民キャラクタ２３３の数が増えていくことによって、城オブジェクト２０３が成長していくことになる。上記のように、住民キャラクタの数は上記レートの意義を有し、プレイヤのゲームの腕前や努力を示すという側面もある。そのため、ゲームが上手いプレイヤほど、城オブジェクト２０３の規模が大きなものとなり得る。このことは、換言すれば、対戦アクションゲームにおけるプレイヤのゲームの腕前・努力を、城オブジェクト２０３という形で視覚的に反映してプレイヤに提示するものともいえる。そのため、ゲームに対するプレイヤのモチベーションをより向上させることができる。また、プレイヤの腕前に応じたものとなるため、城オブジェクト２０３の成長度合いはプレイヤ毎に異なるものとなる。つまり、プレイヤ毎に異なる城オブジェクト２０３に成長することになる。なお、上記の例では、３段階の城オブジェクト２０３の成長例を示したが、成長の段階をより多く、細分化してもよいことは言うまでもない。
　なお、本実施形態では、一旦成長した城オブジェクト２０３は、前のランクの状態に戻ることはないものとする。上記のように、住民キャラクタの数は対戦の勝敗結果に応じて増減するため、一旦１００人となったものが、その後、９０人に減ってしまうこともあり得る。このような場合でも、例えば、住民キャラクタが１００人を越えたため、城オブジェクト２０３が上記「ランク２」の状態に一旦成長すれば、その後住民キャラクタ２３３が９０人まで減ったとしても、上記「ランク１」の状態に戻ることはなく、「ランク２」の状態が維持される。換言すれば、城オブジェクトの成長度合いと住民キャラクタの数とは、完全に連動（一体化）するものではない。仮に両者を完全に連動させると、住民キャラクタ２３３が減った（レートが下がった）ときに城オブジェクト２０３のランクも下がってしまい、プレイヤの対戦プレイに対するモチベーションを低下させてしまう。そのため、上記のように住民キャラクタが減ったとしても、城オブジェクト２０３の成長度合いは維持することで、プレイヤのモチベーションの維持を図るものである。
　次に、図１１～図１６を参照して、本実施形態におけるゲーム処理の詳細を説明する。
　図１１は、サーバ１０１のメインメモリ１２３に記憶されるプログラムおよび情報の一例を示している。サーバ１０１のメインメモリ１２３には、選出処理プログラム３０１、プレイヤデータベース３０２、対戦用ゴーストデータ３０３等が記憶されている
　選出処理プログラム３０１は、スマートデバイス１０２からの要求を受けて、対戦相手の選出を行うためのプログラムである。
　プレイヤデータベース３０２は、本ゲームをプレイしているプレイヤに関する情報が保存されているデータベースである。具体的には、各プレイヤを識別するためのＩＤ、住民キャラクタ数（すなわち、レート）や、現在の城ランク等のデータが、各プレイヤに対応づけられて記憶されている。
　対戦用ゴーストデータ３０３は、上記のような対戦プレイの際に用いられるゴーストデータであり、複数のプレイヤにかかるゴーストデータが記憶されている。当該対戦用ゴーストデータは、上記アクションゲームを一人でプレイしたときのプレイ内容に基づいて適宜生成され、サーバ１０１にアップロードされて記憶される。対戦用ゴーストデータ３０３には、例えば、当該ゴーストデータにかかるプレイヤのＩＤ、そのゲームステージの構成を示すデータ、獲得したコイン枚数、獲得した住民キャラクタ数等を示すデータが含まれている。
　図１２は、スマートデバイス１０２のメインメモリ１１３に格納されるプログラムおよび情報の一例を示している。メインメモリ１１３には、ゲーム処理プログラム３２１、操作データ３２２、住民キャラクタ数データ３２３、現在の城ランクデータ３２４、城オブジェクトデータ３２５、ランクアップ条件定義データ３２６、アクションステージ用データ３２７、対戦ワークデータ３２８等が格納される。
　ゲーム処理プログラム３２１は、上述したようなゲーム処理を実行するためのプログラムである。具体的には、後述する図１３のフローチャート処理を実行するためのプログラムである。
　操作データ３２２は、スマートデバイス１０２に対して行われた各種操作を示すデータである。本実施形態では、操作データ３２２には、ボタンデータやタッチパネルデータが含まれる。これらのデータは操作部１１５に対して行われた操作内容を示すデータであり、各種ボタンの押下状態やタッチパネルのタッチ座標やタッチ継続時間等を示すデータである。
　住民キャラクタ数データ３２３は、上述したような住民キャラクタの数（街の人口）を示すデータである。また、本データは、上述のレートとしての意義も有するものである。
　現在の城ランクデータ３２４は、上記城オブジェクト２０３の成長度合いを示すデータである。本実施形態では、上記のような「ランク」という概念で城オブジェクト２０３の成長度合いが示されるものとする。
　城オブジェクトデータ３２５は、城オブジェクト２０３を描画するために用いられる画像データやモデルデータである。当該城オブジェクトデータ３２５には、上記「ランク」に対応した城オブジェクト２０３の画像データ等が記憶されている。
　ランクアップ条件定義データ３２６は、城オブジェクト２０３を成長させる（ランクを上げる）ための条件を定義したデータである。例えば、「ランク１の状態で住民オブジェクト数が１００以上となったとき、ランク２に成長させる」等の条件が定義されているデータである。
　アクションステージ用データ３２７は、上述したようなアクションゲームにかかる仮想ゲーム空間を構築するための各種データである。すなわち、各種地形オブジェクトや敵キャラクタ、プレイヤキャラクタ等のモデルデータ等が含まれている。
　対戦ワークデータ３２８は、上記のような対戦ゲームを実行する際に一時的に生成されて用いられるデータである。対戦ワークデータ３２８には、獲得コイン数データ３２９、獲得住民数データ３３０、対戦相手ゴーストデータ３３１、ステージデータ３３２等が含まれる。獲得コイン数データ３２９は、上記のような対戦プレイ中にプレイヤが獲得したコイン数を示すデータである。獲得住民数データ３３０は、同様に対戦プレイ中にプレイヤが獲得した上記住民キャラクタ数を示すデータである。対戦相手ゴーストデータ３３１は、対戦相手にかかる上記対戦用ゴーストデータ３０３をサーバ１０１からダウンロードして記憶したデータである。その内容は、上記対戦用ゴーストデータ３０３と同内容である。ステージデータ３３２は、上記対戦相手ゴーストデータ３３１に基づいて生成される仮想ゲーム空間の構成を示すデータである。すなわち、地形オブジェクトや敵キャラクタ、コインや住民キャラクタの配置等を示すデータである。
　次に、図１３のフローチャートを参照して、スマートデバイス１０２のプロセッサ部１１１によって実行されるゲーム処理の流れを説明する。図１３は、当該ゲーム処理の詳細を示すフローチャートである。
　本ゲーム処理がプレイヤの起動指示操作に基づいて起動されると、まず、ステップＳ１で、プロセッサ部１１１は、初期処理を実行する。この処理では、各種データの初期化や、ログイン処理、ゲーム処理に必要なデータをサーバ１０１から取得する処理等が実行される。例えば、プレイヤデータベース３０２から、現在の住民キャラクタ数を取得して住民キャラクタ数データ３２３としてメインメモリ１１３に記憶したり、現在の城ランクを示すデータを取得して現在の城ランクデータ３２４としてメインメモリ１１３に記憶したりする処理等が実行される。
　次に、ステップＳ２で、プロセッサ部１１１は、街画面生成処理を実行する。すなわち、上記図４の街エリア２０１に表示すべき画像を生成するための処理が実行される。図１４は、当該街画面生成処理の詳細を示すフローチャートである。図１４において、まず、ステップＳ１１で、プロセッサ部１１１は、現在の城ランクデータ３２４をメインメモリ１１３から取得する。次に、ステップＳ１２で、プロセッサ部１１１は、住民キャラクタ数データ３２３をメインメモリ１１３から取得する。次に、ステップＳ１３で、プロセッサ部１１１は、ランクアップ条件定義データ３２６を参照し、城オブジェクト２０３を成長させるための条件、すなわちランクアップの条件が満たされたか否かを判定する。例えば、現在の城が「ランク１」でかつ住民キャラクタ数が１００人以上である場合、「ランク２」へのランクアップ条件が満たされたと判定されることになる。当該判定の結果、ランクアップ条件が満たされていたときは（ステップＳ１３でＹＥＳ）、ステップＳ１４で、プロセッサ部１１１は、現在の城ランクデータ３２４をランクアップ後のランクを示す内容に更新する（なお、ここで更新された現在の城ランクデータ３２４については、適宜サーバ１０１にも送信され、プレイヤデータベース３０２の内容も適宜更新される）。一方、ランクアップ条件が満たされていないときは（ステップＳ１３でＮＯ）、当該ステップＳ１４の処理はスキップされる。
　次に、ステップＳ１５で、プロセッサ部１１１は、現在の城ランクデータ３２４を再度取得し、その内容に対応する城オブジェクト２０３の画像データ等を、城オブジェクトデータ３２５から取得する。
　次に、ステップＳ１６で、プロセッサ部１１１は、上記取得した画像データ等に基づき、城オブジェクト２０３の画像を生成する。以上で、街画面生成処理が終了する。
　図１３に戻り、次に、ステップＳ３で、プロセッサ部１１１は、上記生成された城オブジェクト２０３の画像等に基づき、上記図４で示したようなホーム画面を生成して表示する。
　次に、ステップＳ４で、プロセッサ部１１１は、操作データ３２２を取得する。続くステップＳ５で、プロセッサ部１１１は、操作データ３２２に基づき、対戦バトルの開始が選択されたか否かを判定する。すなわち、上記図４の画面で、ボタン画像２０４Ｂがタップされたか否かが判定される。当該判定の結果、対戦バトルの開始が選択されたときは（ステップＳ５でＹＥＳ）、ステップＳ６で、プロセッサ部１１１は、対戦ゲーム処理を実行する。
　図１５は、上記対戦ゲーム処理の詳細を示すフローチャートである。図１５において、まず、ステップＳ２１で、プロセッサ部１１１は、対戦相手を探すための選出処理を実行する。具体的には、サーバ１０１に対して、プレイヤの住民キャラクタ数データ３２３（すなわち、レート）等の情報と共に、選出処理の依頼を送信する。これを受けて、サーバ１０１側で、プレイヤデータベース３０２が参照されて、住民キャラクタ数が近いプレイヤからランダムに５名抽出される。そして、当該抽出結果を示すデータがサーバ１０１からスマートデバイス１０２に送信される。当該データの受信完了をもって、当該選出処理は終了する。
　次に、ステップＳ２２で、プロセッサ部１１１は、上記サーバ１０１から受信した抽出結果を示すデータに基づき、上記図５で示したような対戦相手選択画面を生成し、表示する処理を実行する。そして、この画面に対し、プレイヤが所定の対戦相手を選択する操作を行うと、ステップＳ２３で、プロセッサ部１１１は、アクションゲーム処理を実行する。当該処理をより具体的に説明すると、まず、選択された対戦相手にかかる対戦用ゴーストデータ３０３をサーバ１０１から取得する処理が実行される。そして、当該対戦用ゴーストデータ３０３に基づいて仮想ゲーム空間（ゲームステージ）が生成され、プレイヤキャラクタ等の各種キャラクタも配置される。そして、ゲーム画面が表示され、プレイヤの操作に基づくアクションゲーム処理が適宜実行される。この処理において、獲得コイン数データ３２９や獲得住民数データ３３０の内容は適宜更新される。
　次に、予め設定されていた制限時間が経過することによってアクションゲーム処理が終了すると、ステップＳ２４で、プロセッサ部１１１は、リザルト処理を実行する。図１６は、当該リザルト処理の詳細を示すフローチャートである。図１６において、まず、ステップＳ３１で、プロセッサ部１１１は、獲得コイン数データ３２９と、対戦相手ゴーストデータ３３１に含まれる対戦相手の獲得コイン数のデータに基づいて、対戦の勝敗判定を行う。
　次に、ステップＳ３２で、プロセッサ部１１１は、勝敗判定の結果、プレイヤの勝利であるか否かを判定する。当該判定の結果、プレイヤの勝利であるときは（ステップＳ３２でＹＥＳ）、ステップＳ３３で、プロセッサ部１１１は、対戦相手ゴーストデータ３３１で示される対戦相手の獲得住民キャラクタ数を、住民キャラクタ数データ３２３に加算する。一方、プレイヤの敗北であるときは（ステップＳ３２でＮＯ）、ステップＳ３４で、プロセッサ部１１１は、獲得住民数データ３３０で示される数を住民キャラクタ数データ３２３から減算する（なお、ここで更新された住民キャラクタ数データ３２３については、適宜サーバ１０１にも送信され、プレイヤデータベース３０２の内容も適宜更新される）。
　次に、ステップＳ３５で、プロセッサ部１１１は、上記図７で示したようなリザルト画面を生成し、表示する。以上で、リザルト処理が終了する。
　図１５に戻り、リザルト処理が終了すれば、対戦ゲーム処理も終了する。
　図１３に戻り、上記ステップＳ５の判定の結果、対戦が選択されていなかったときは（ステップＳ５でＮＯ）、ステップＳ７で、プロセッサ部１１１は、操作データ３２２に基づいてその他のゲーム処理を適宜実行する。例えば、一人用のアクションゲーム処理の実行等が行われる。
　次に、ステップＳ８で、プロセッサ部１１１は、本ゲームを終了する条件が満たされたか否かを判定し、当該条件が満たされていないときは（ステップＳ８でＮＯ）、上記ステップＳ２に戻り、処理を繰り返す。当該条件が満たされていたときは（ステップＳ８でＹＥＳ）、本ゲーム処理を終了する。以上で、本実施形態にかかるゲーム処理の説明を終了する。
　このように、本実施形態のゲーム処理では、アクションゲームで対戦をプレイヤに楽しませると同時に、対戦結果に応じてレート（住民キャラクタ数）を増減させ、このレートを城オブジェクト２０３の成長に反映させている。これにより、プレイヤのゲームの腕前や実力や努力を示す指標（レート）に、成長要素の基準としての意義も持たせることで、対戦アクションゲームと城オブジェクト２０３の育成の双方に対するプレイへのモチベーションを相乗効果的に向上させることができる。また、上記のようなプレイヤの腕前を示す指標と、成長要素の基準となる要素とを「住民キャラクタ」として統一していることで、プレイヤに理解しやすい形で提示することができる。
　なお、上記の例では、「街」の育成例として城オブジェクト２０３が成長する例を示した。この他、「街」の育成の他の例として、例えば、住民キャラクタの人口が増加するに連れて、城オブジェクト２０３の周囲に所定の建物オブジェクトが段階的に配置できるようにしても良い。図１７に、このような場合の街エリア２０１の画像の一例を示す。図１７では、街エリア２０１の中央部分に城オブジェクト２０３が表示される中央領域２５１がある。そして、その周囲を囲むようにして、点線で示される１２個の四角形の領域（以下、周辺領域）２５２が示されている。城オブジェクト２０３の成長については、上記と同様に、住民キャラクタの数が増えるに連れて、その外観が自動的に変化していく。すなわち、上記現在の城ランクデータ３２４に応じた外観となる。これに加えて、例えば、城オブジェクト２０３が「ランク１」の状態から「ランク２」に成長したとき、上記１２の周辺領域２５２の中から任意の１つの領域について、プレイヤの操作に基づいて所定の建物オブジェクトが配置できるようにしてもよい（図１８参照）。例えば、プレイヤが１２の周辺領域２５２の中から任意の１つの領域をタップすることで、その領域に配置する建物オブジェクトを選択する画面が表示されるようにすればよい。そして、城オブジェクト２０３が「ランク２」の状態から「ランク３」に成長したときにも、更にもう１つの領域について、所定の建物オブジェクトが配置できるようにしてもよい（図１９参照）。あるいは、城オブジェクト２０３のランクとは関係なく、住民キャラクタ数が所定数を越えたときに、上記１２の周辺領域２５２の中から任意の１つの領域について、プレイヤの操作に基づいて所定の建物オブジェクトが配置できるようにしてもよい。例えば、住民キャラクタ数が５０人以上になったときに、任意の１つの領域について建物オブジェクトを配置可能とする。その後、住民キャラクタ数が１００人以上となったときに、更にもう一つの領域について建物オブジェクトを配置可能とするようにしてもよい。つまり、住民キャラクタ数の増加に連れて、１２の周辺領域２５２について１つずつ段階的に、プレイヤの操作に基づいて所定の建物オブジェクトが配置できるようにしてもよい。逆に言うと、住民キャラクタ数が増加したからといって、自動的に配置されるものではない。すなわち、城オブジェクト２０３については自動的に成長するが、周辺領域２５２に関してはプレイヤが手動で建物オブジェクトを設置する必要があるという構成となる。このように、育成対象としての「街」として、城オブジェクト２０３と、上記のような周辺領域２５２の配置可能な建物オブジェクトの２種類のオブジェクトを含めるようにしてもよい。このことは、城オブジェクト２０３の成長も、建物オブジェクトとの配置も「街」の育成の一環であるといえる。
　更に、上述したような「街」を構成する要素として、上記のような建物オブジェクトの他、例えば、花、池、畑、像、遊具等の、建物ではないオブジェクトを配置可能としてもよい。また、上記の例では、上記城オブジェクト２０３と周辺領域２５２に配置されるオブジェクトとは、別領域に配置される例となっていた。しかし、このような２種のオブジェクトについて別領域に配置される場合に限るものではなく、一方が他方の領域内に含まれるような配置形態としてもよい。例えば、城オブジェクト２０３の内部に「部屋」という領域を用意しておき、この「部屋」に他のオブジェクト（家具オブジェクト等）を配置可能な構成としてもよい。また、この場合は、城オブジェクト２０３が成長することで、城の内部の「部屋」の数が増えるようにしてもよい。
　また、このように周辺領域２５２を利用する場合、当該城オブジェクト２０３に関連するデータとして、上記図１２に示したデータに加え、例えば、図２０に示すように周辺領域データ３４１を更に持たせるようにすればよい。図２０の周辺領域データ３４１には、上記１２の周辺領域２５２に対応する第１領域データ３４２Ａ～第１２領域データ３４２Ｌが含まれている。各領域データ３４２には、その領域に建物オブジェクトが配置されているか否かを示す情報と、配置されている建物オブジェクト自身を示す情報等が含まれる。そして、当初は各領域データ３４２の変更はできない状態としておき、住民キャラクタ数の増加に伴って、１つずつ段階的に各領域データ３４２の変更を（ユーザの操作に基づいて）可能とするようにすればよい。そして、当該各領域データ３４２の内容に基づいて、対応する周辺領域２５２に、城オブジェクト２０３とは別の建物オブジェクトを追加表示するようにすればよい。これにより、街の育成に関して、より興趣性を高めることが可能となる。
　また、育成対象については、上記のような城オブジェクト２０３の他、例えばタワー型のオブジェクトであってもよい。タワー型オブジェクトを育成対象とする場合は、例えば、住民キャラクタの増加に伴い、タワーの高さが伸びていくようにすればよい。また、上記の例では育成対象の「街」として、単一の城オブジェクト２０３だけの場合と、城オブジェクト２０３に加えて上記周辺領域２５２に配置されるオブジェクトも含めた場合とを例示していた。この他、育成対象である「街」は、例えば、上記のような城オブジェクト２０３は存在せずに、複数の住宅オブジェクトや店オブジェクト等の建物オブジェクトの他、道路オブジェクトや乗り物オブジェクト等の様々な種類のオブジェクトから構成されるような街であってもよい。このような場合は、例えば、ゲーム開始当初は、街には建物オブジェクトが２～３個しかないという状態であり、住民キャラクタの増加に伴い、建物オブジェクトの数も自動的に増加していくようにすればよい。また、育成対象としては、「街」という形態に限らず、例えば、都市、村、島、部屋等の、所定の領域内に複数のオブジェクトが配置されるようなものであれば、どのような形態であってもよい。更には、その他の育成対象として、生き物をモチーフとしたオブジェクトを育成対象としてもよい。例えば、所定の動物オブジェクトや人物オブジェクトを育成対象として表示してもよい。
　また、その他、アクションゲームにおけるプレイの内容に応じて、成長の方向性が変化するようにしてもよい。例えば、上記住民キャラクタについて、いくつかのタイプを出現させるようにする。一例として、「タイプＡ住民」、「タイプＢ住民」、「タイプＣ住民」の３種類の住民キャラクタが定義されているとする。それぞれの住民キャラクタ数は、上述したような処理と同様に、対戦の勝敗結果に応じて増減する。そして、アクションゲームにおいてプレイヤが獲得した住民キャラクタにおけるタイプの比率に応じて、城オブジェクト２０３の成長内容を異ならせるようにしても良い。つまり、同じ「ランク２」の状態の城オブジェクト２０３であっても、住民キャラクタのタイプの比率によって、その外観を異ならせるようにしても良い。例えば、住民キャラクタが１００人いるとして、そのうち８０人が「タイプＡ住民」である場合と、同じく８０人が「タイプＢ住民」である場合とでは、「ランク２」状態の城オブジェクト２０３の外観を異なるものとしてもよい。
　また、例えば、城オブジェクト２０３に複数の成長パラメータを設定しておき、上記複数のタイプの住民キャラクタに応じて、当該成長パラメータに与える影響度を異ならせるようにしても良い。例えば、城オブジェクトの色に関するパラメータであるパラメータＡ、形に関するパラメータであるパラメータＢ、大きさに関するパラメータであるパラメータＣの３つのパラメータを、城オブジェクト２０３の外観に影響を及ぼすパラメータとして設定しておく。そして、個々のアクションゲームの終了時（リザルト画面時）に、そのときに獲得した各タイプの住民キャラクタ数に応じて、各パラメータの値を変更してもよい。例えば、タイプＡ住民の数をパラメータＡに加算し、タイプＢ住民の数をパラメータＢに加算し、タイプＣ住民の数をパラメータＣに加算する等である。そして、城オブジェクト２０３のランクアップ時に、当該３つのパラメータに基づいてランクアップ後の城オブジェクト２０３の外観を変化させるようにすればよい。これにより、プレイヤのアクションゲームにおけるプレイ内容に応じた、より個性的な城オブジェクト２０３を提示することができ、プレイヤのモチベーションを高めることが可能となる。また、上記のような複数のパラメータを用いる場合は、少なくともの一部のパラメータを上述したレート（住民キャラクタ数）以外の要素に基づいて変化させるようにしてもよい。例えば、ゲームのプレイ時間や、対戦ゲームにおける累計勝利数に基づいてパラメータを変化させるようにしてもよい。更には、一部のパラメータについては、その変化をランダムで変化させるようにしてもよい。例えば、城オブジェクト２０３の大きさに関する上記パラメータＣについては、住民キャラクタ数に基づいて変化するが、城オブジェクト２０３の色や形に関する上記パラメータＡ、Ｂに関してはランダムで変化させるようにしてもよい。
　また、上述のような複数種類の住民キャラクタを用いる場合は、上述したレートとして、これら複数種類の住民キャラクタの総人口をレートとして用いても良いし、各種類の住民キャラクタそれぞれの人口をレートとして用いてもよい（後者の場合は、複数種類のレートが用いられることになる）。
　また、アクションゲームの勝敗判定に関して、上記の例では獲得コイン枚数で勝敗を決めていたが、他の実施形態では、コインは用いずに、獲得した住民キャラクタの数で勝敗決定するようにしてもよい。
　また、上記の例では、レート（住民キャラクタ数）、すなわち、プレイヤの腕前を示す指標を数値で示す例を示したが、この他、例えば「Ａ＋」、「Ａ」、「Ｂ＋」、「Ｂ」等のように、数値以外で当該指標を示すようにしても良い。また、この場合における指標の「上昇」「増加」とは、より高い腕前であることを示す指標に変化することである（例えば、「Ｂ＋」が「Ａ」に変化する場合）。また、指標の「下降」「減少」とは、より低い腕前であることを示す指標に変化することである（例えば、「Ｂ＋」が「Ｂ」に変化する場合）。また、その他、例えば、「段位」のように、数字が小さいものほど高い実力を有することを示すような指標を用いてもよい。この場合は、指標の「上昇」「増加」は、「３段」から「２段」に変化する場合に該当する。また、指標の「下降」「減少」は、「３段」から「４段」に変化する場合に該当する。
　更に、他の実施形態では、上述のレート（住民キャラクタ数）が上がることに応じて、上記アクションゲームにおけるプレイヤキャラクタ２２１に関連づけられた所定のパラメータを変化させるようにしてもよい。例えば、住民キャラクタ数が増えることに応じて、プレイヤにとって有利な効果が得られるようにプレイヤキャラクタ２２１のパラメータを変化させても良い。例えば、プレイヤキャラクタ２２１のジャンプ力や移動速度を上昇させてもよい。あるいは、プレイヤキャラクタ２２１の体力や残機数を増やしても良い。あるいはゲームプレイの制限時間を初期値の時間から延長しても良い。また、その他、単純に、プレイヤキャラクタ２２１の外観を変化させるようにしてもよい（この場合は、必ずしも有利な効果を与えられるわけではないが、見た目上の変化を与えることができる）。より具体的には、次のような制御を行えば良い。まず、プレイヤキャラクタ２２１に関するデータとして上述したようなパラメータを用意しておく。そして、レート（住民キャラクタ数）が上がることに応じて、当該プレイヤキャラクタ２２１のパラメータを直接的に変更するという制御を行えば良い。また、他の制御例として、レート（住民キャラクタ数）が上がることに応じて、上記城オブジェクト２０３に関連づけられたパラメータが変化し、当該パラメータに基づいてプレイヤキャラクタ２２１のパラメータが変更されるような制御としてもよい。例えば、城オブジェクト２０３の「高さ」が所定値を超えることで、プレイヤキャラクタ２２１のジャンプ力が上昇する、というような制御としても良い。このような制御を行うことで、対戦ゲームにおいて有利となる効果が得られるため、対戦ゲームに対するプレイヤのモチベーションを上昇させることができる。更に、対戦ゲームについてのモチベーションと、城オブジェクト２０３を成長させたいというモチベーションとが１つのサイクルとして構築され、これら２つのモチベーションについて相乗効果的に上昇させることができ、ゲームの興趣性を更に高めることが可能となる。
　本実施例にかかるゲームプログラム等は、プレイヤのゲームの実力を示す指標を用いた新たなゲーム処理を提供することができ、携帯型のスマートデバイスや各種ゲーム装置等の用途に有用である。
　１０１　サーバ
　１０２　スマートデバイス
　１１１　　プロセッサ部
　１１２　　内部記憶装置
　１１３　　メインメモリ
　１１４　　通信部
　１１５　　操作部
　１１６　　表示部
　１２１　　プロセッサ部
　１２２　　内部記憶装置
　１２３　　メインメモリ
　１２４　　通信部

Claims (20)

  1. 　他のプレイヤとの対戦を行う対戦ゲームと、所定の育成対象を育成させる育成ゲームとを含むゲーム処理を実行するゲームシステムであって、
    　他のプレイヤとの対戦ゲーム処理を実行する対戦ゲーム処理手段と、
    　前記対戦ゲーム処理手段による対戦ゲームにおけるプレイヤの勝敗結果に基づいて変動する指標データを記憶する指標データ記憶手段と、
    　前記対戦ゲーム処理手段による対戦ゲームにおける前記プレイヤの勝敗結果に基づいて前記指標データを更新する指標更新手段と、
    　前記指標データが所定の条件を満たしたか否かを判定する判定手段と、
    　所定の条件を満たしたと判定した場合、前記所定の育成対象に含まれる第１オブジェクトに関連づけられた第１パラメータを変更する第１パラメータ変更手段と、
    　前記変更された第１パラメータが反映された前記第１オブジェクトの画像をプレイヤに提示する提示手段とを備える、ゲームシステム。
  2. 　前記ゲームシステムは、前記対戦ゲームと前記育成ゲームとを選択的に実行するゲーム選択手段を更に備える、請求項１に記載のゲームシステム。
  3. 　前記指標データは、前記プレイヤのゲームの実力を所定の値で示すレートである、請求項１または２に記載のゲームシステム。
  4. 　前記指標更新手段は、前記対戦ゲームの結果前記プレイヤが勝利したことに基づいて前記指標データの値の上昇または下降のうちのいずれか一方を行い、当該対戦ゲームの結果当該プレイヤが敗北したことに基づいて前記指標データの値の上昇または下降のうちの他方を行う、請求項１ないし３のいずれかに記載のゲームシステム。
  5. 　前記指標データの値は、前記対戦ゲームにおける前記プレイヤの勝敗結果に基づいて増加または減少する値であり、
    　前記指標更新手段は、前記対戦ゲームの結果前記プレイヤが勝利したときは前記指標データの値を増加させ、敗北したときは当該指標データの値を減少させる、請求項４に記載のゲームシステム。
  6. 　前記ゲームシステムは、前記プレイヤの指標データと近い値を有する他のプレイヤを前記対戦ゲーム処理における対戦相手として選出する選出手段を更に備える、請求項１ないし５のいずれかに記載のゲームシステム。
  7. 　前記選出手段は、複数の前記対戦相手を対戦候補として選出し、
    　前記ゲームシステムは、
    　　前記複数の対戦候補のうちのいずれかをプレイヤが選択可能なように当該複数の対戦候補を表示する候補表示手段と、
    　　前記プレイヤの操作に基づいて前記複数の対戦候補のうちのいずれかを選択する対戦相手選択手段を更に備える、請求項６に記載のゲームシステム。
  8. 　前記判定手段は、前記指標データの値が所定の閾値を超えたときに、前記所定の条件を満たしたと判定する、請求項１ないし７のいずれかに記載のゲームシステム。
  9. 　前記第１パラメータ変更手段は、前記指標データが前記所定の条件を満たしたと判定されたとき、前記第１パラメータをプレイヤの操作を要することなく変更する、請求項１ないし８のいずれかに記載のゲームシステム。
  10. 　前記提示手段は、前記第１パラメータの変更に基づいて前記第１オブジェクトの外観を変更して提示する、請求項１ないし９のいずれかに記載のゲームシステム。
  11. 　前記ゲームシステムは、前記所定の育成対象に含まれる第２オブジェクトに関連づけられるパラメータであって、前記第１のパラメータとは異なるパラメータである第２のパラメータをプレイヤの操作に基づいて変更する第２パラメータ変更手段を更に備え、
    　前記提示手段は、前記第２パラメータ変更手段によって変更された第２のパラメータに基づいた第２のオブジェクトの画像を更にプレイヤに提示する、請求項１ないし１０のいずれかに記載のゲームシステム。
  12. 　前記指標データが前記所定の条件を満たしたと判定されたときに、前記第２パラメータ変更手段による前記プレイヤの操作に基づいた前記第２のパラメータの変更が可能となる、請求項１１に記載のゲームシステム。
  13. 　前記第１パラメータの値は、一旦指標データが前記所定の条件を満たした後、当該指標データの変動によって当該所定の条件を満たさなくなっても、前記第１パラメータ変更手段による変更前の値には戻らない、請求項１ないし１２のいずれかに記載のゲームシステム。
  14. 　前記対戦ゲーム処理手段は、前記対戦ゲームにおける前記プレイヤと対戦相手とのスコアを比較することで前記勝敗の決定を行い、
    　前記指標更新手段は、前記指標データの変動量を前記プレイヤのスコアに基づいて決定する、請求項１ないし１３のいずれかに記載のゲームシステム。
  15. 　前記対戦ゲーム処理手段は、前記対戦ゲームにおける前記プレイヤと対戦相手とのスコアを比較することで前記勝敗の決定を行い、
    　前記指標更新手段は、前記指標データの変動量を前記対戦相手のスコアに基づいて決定する、請求項１ないし１４のいずれかに記載のゲームシステム。
  16. 　前記ゲームシステムは、前記第１パラメータ変更手段によって変更された前記第１パラメータに基づいて、前記対戦ゲーム処理において用いられる対戦ゲーム用パラメータを変化させる対戦用パラメータ変化手段を更に備える、請求項１ないし１５のいずれかに記載のゲームシステム。
  17. 　前記所定の育成対象は、複数のオブジェクトから構成される街であり、
    　前記第１オブジェクトは、前記街に配置可能な前記オブジェクトである、請求項１ないし１６のいずれかに記載のゲームシステム。
  18. 　他のプレイヤとの対戦を行う対戦ゲームと、所定の育成対象を育成させる育成ゲームとを含むゲーム処理を実行するゲームシステムのコンピュータを制御するためのゲーム処理方法であって、
    　他のプレイヤとの対戦ゲーム処理を実行する対戦ゲーム処理ステップと、
    　前記対戦ゲーム処理手段による対戦ゲームにおける前記プレイヤの勝敗結果に基づいて変動する指標データを記憶する指標データ記憶ステップと、
    　前記対戦ゲーム処理手段による対戦ゲームにおける前記プレイヤの勝敗結果に基づいて前記指標データを更新する指標更新ステップと、
    　前記指標データが所定の条件を満たしたか否かを判定する判定ステップと、
    　所定の条件を満たしたと判定した場合、前記所定の育成対象に含まれる第１オブジェクトに関連づけられた第１パラメータを変更する第１パラメータ変更ステップと、
    　前記変更されたパラメータが反映された前記第１オブジェクトの画像をプレイヤに提示する提示ステップとを前記コンピュータに実行させる、ゲーム処理方法。
  19. 　他のプレイヤとの対戦を行う対戦ゲームと、所定の育成対象を育成させる育成ゲームとを含むゲーム処理を実行するゲームシステムのコンピュータに実行させるゲームプログラムであって、
    　前記コンピュータを、
    　　他のプレイヤとの対戦ゲーム処理を実行する対戦ゲーム処理手段と、
    　　前記対戦ゲーム処理手段による対戦ゲームにおける前記プレイヤの勝敗結果に基づいて変動する指標データを記憶する指標データ記憶手段と、
    　　前記対戦ゲーム処理手段による対戦ゲームにおける前記プレイヤの勝敗結果に基づいて前記指標データを更新する指標更新手段と、
    　　前記指標データが所定の条件を満たしたか否かを判定する判定手段と、
    　　所定の条件を満たしたと判定した場合、前記所定の育成対象に含まれる第１オブジェクトに関連づけられた第１パラメータを変更する第１パラメータ変更手段と、
    　　前記変更されたパラメータが反映された前記第１オブジェクトの画像をプレイヤに提示する提示手段として機能させる、ゲームプログラム。
  20. 　他のプレイヤとの対戦を行う対戦ゲームと、所定の育成対象を育成させる育成ゲームとを含むゲーム処理を実行するゲーム装置であって、
    　他のプレイヤとの対戦ゲーム処理を実行する対戦ゲーム処理手段と、
    　前記対戦ゲーム処理手段による対戦ゲームにおける前記プレイヤの勝敗結果に基づいて変動する指標データを記憶する指標データ記憶手段と、
    　前記対戦ゲーム処理手段による対戦ゲームにおける前記プレイヤの勝敗結果に基づいて前記指標データを更新する指標更新手段と、
    　前記指標データが所定の条件を満たしたか否かを判定する判定手段と、
    　所定の条件を満たしたと判定した場合、前記所定の育成対象に含まれる第１オブジェクトに関連づけられた第１パラメータを変更する第１パラメータ変更手段と、
    　前記変更されたパラメータが反映された前記第１オブジェクトの画像をプレイヤに提示する提示手段とを備える、ゲーム装置。
PCT/JP2016/004003 2016-09-01 2016-09-01 ゲームシステム、ゲーム処理方法、ゲームプログラム、およびゲーム装置 Ceased WO2018042468A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2017534762A JP6442061B2 (ja) 2016-09-01 2016-09-01 ゲームシステム、ゲーム処理方法、ゲームプログラム、およびゲーム装置
PCT/JP2016/004003 WO2018042468A1 (ja) 2016-09-01 2016-09-01 ゲームシステム、ゲーム処理方法、ゲームプログラム、およびゲーム装置
US15/668,860 US10729982B2 (en) 2016-09-01 2017-08-04 Game system, game processing method, computer-readable non-transitory storage medium having stored therein game program, and game apparatus
US16/913,622 US11298620B2 (en) 2016-09-01 2020-06-26 Game system, game processing method, computer-readable non-transitory storage medium having stored therein game program, and game apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2016/004003 WO2018042468A1 (ja) 2016-09-01 2016-09-01 ゲームシステム、ゲーム処理方法、ゲームプログラム、およびゲーム装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/668,860 Continuation US10729982B2 (en) 2016-09-01 2017-08-04 Game system, game processing method, computer-readable non-transitory storage medium having stored therein game program, and game apparatus

Publications (1)

Publication Number Publication Date
WO2018042468A1 true WO2018042468A1 (ja) 2018-03-08

Family

ID=61241269

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/004003 Ceased WO2018042468A1 (ja) 2016-09-01 2016-09-01 ゲームシステム、ゲーム処理方法、ゲームプログラム、およびゲーム装置

Country Status (3)

Country Link
US (2) US10729982B2 (ja)
JP (1) JP6442061B2 (ja)
WO (1) WO2018042468A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023069745A (ja) * 2021-11-08 2023-05-18 任天堂株式会社 情報処理システム、情報処理装置、情報処理プログラムおよび情報処理方法
JP2023138279A (ja) * 2022-03-16 2023-10-02 カバー株式会社 プログラム、仮想空間提供方法、及び仮想空間提供システム
US12186671B2 (en) 2021-08-04 2025-01-07 Nintendo Co., Ltd. Computer-readable non-transitory storage medium having game program stored therein, game apparatus, game processing method, and game system
JP7702032B1 (ja) 2024-11-05 2025-07-02 株式会社コロプラ プログラムおよび情報処理システム

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018042468A1 (ja) 2016-09-01 2018-03-08 任天堂株式会社 ゲームシステム、ゲーム処理方法、ゲームプログラム、およびゲーム装置
JP6989338B2 (ja) * 2017-10-13 2022-01-05 株式会社バンダイナムコエンターテインメント プログラム、情報処理装置、及びゲームシステム

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016107051A (ja) * 2015-06-23 2016-06-20 株式会社 ディー・エヌ・エー 情報処理装置、及び、ゲームプログラム

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US215768A (en) * 1879-05-27 Improvement in machines for forging horseshoe-nails
US354900A (en) * 1886-12-28 Feeder for bagasse roller-mills
JP2006333916A (ja) * 2005-05-31 2006-12-14 Itochu Techno-Science Corp オンラインゲーム提供システムおよびコンピュータプログラム
JP5068237B2 (ja) * 2008-10-31 2012-11-07 株式会社スクウェア・エニックス ビデオゲーム処理装置、ビデオゲーム処理方法、およびビデオゲーム処理プログラム
JP5174209B2 (ja) * 2011-05-11 2013-04-03 株式会社コナミデジタルエンタテインメント ゲーム運用装置、ゲーム運用方法、及びゲーム運用プログラム
JP5945174B2 (ja) * 2012-06-29 2016-07-05 株式会社コナミデジタルエンタテインメント ゲームシステム、端末装置、ゲーム制御方法およびプログラム
CN105474254A (zh) * 2013-09-02 2016-04-06 索尼电脑娱乐公司 信息处理设备
JP5875619B2 (ja) 2014-04-02 2016-03-02 株式会社タイトー マッチングプログラム、マッチングサーバ、ゲームシステム及びレーティング算出方法
WO2018042468A1 (ja) 2016-09-01 2018-03-08 任天堂株式会社 ゲームシステム、ゲーム処理方法、ゲームプログラム、およびゲーム装置

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016107051A (ja) * 2015-06-23 2016-06-20 株式会社 ディー・エヌ・エー 情報処理装置、及び、ゲームプログラム

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"Kurarowa Koryaku] Imakara Hajimeru 'Clash* Royale", KURAROWA KORYAKU] IMAKARA HAJIMERU 'CLASH* ROYALE, 10 March 2016 (2016-03-10), Retrieved from the Internet <URL:http://app.famitsu.com/20160307667679> *
KURAROWA KORYAKU' SUBETE NO ARENA NO SHURUI TO HITSUYO TROPHY-SU!, 5 July 2016 (2016-07-05), Retrieved from the Internet <URL:http://claclakoneta.net/cr-arena-s> *
KURAROWA KORYAKU] 'KURAROWA' NO YOKU ARU SHITSUMON TO KAITO MATOME (FAQ, 11 March 2016 (2016-03-11), Retrieved from the Internet <URL:https://gamy.jp/clashroyale/kurarowa-faq> *
SHIRO DORA KORYAKU] TSUYO-P.UMA-P.SAGE-P 'P'TTE NAANI?, 26 May 2016 (2016-05-26), Retrieved from the Internet <URL:http://shirodora.co/%E5%88%9D%E5%BF%83%E8%80%85%E6%94%BB%E7%95%A5/%E3%80%90%E5%9F%8E%E3%83%89%E3%83%A9%E6%94%BB%E7%95%A5%E3%80%91%E3%81%A4%E3%82%88%EF%BD%90%E3%83%BB%E3%81%86%E3%81%BE%EF%BD%90%E3%83%BB%E3%81%95%E3%81%92%EF%BD%90%E3%80%8C%EF%BD%90%E3%80%8D%E3%81%A3-2470> *
SHIRO DORA: TSUYOKU NARU TAMENI ZETTAI NI SHITTEOKITAI ''JOKAMACHI'' O KANZEN KAIBO, 16 February 2015 (2015-02-16), Retrieved from the Internet <URL:http://weekly.ascii.jp/elem/000/000/304/304566> *

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12186671B2 (en) 2021-08-04 2025-01-07 Nintendo Co., Ltd. Computer-readable non-transitory storage medium having game program stored therein, game apparatus, game processing method, and game system
JP2023069745A (ja) * 2021-11-08 2023-05-18 任天堂株式会社 情報処理システム、情報処理装置、情報処理プログラムおよび情報処理方法
JP7315640B2 (ja) 2021-11-08 2023-07-26 任天堂株式会社 情報処理システム、情報処理装置、情報処理プログラムおよび情報処理方法
EP4226986A1 (en) * 2021-11-08 2023-08-16 Nintendo Co., Ltd. Information processing system, information processing apparatus, information processing program and information processing method
JP2023134634A (ja) * 2021-11-08 2023-09-27 任天堂株式会社 情報処理システム、情報処理装置、情報処理プログラムおよび情報処理方法
JP7882813B2 (ja) 2021-11-08 2026-06-30 任天堂株式会社 情報処理システム、情報処理装置、情報処理プログラムおよび情報処理方法
JP2023138279A (ja) * 2022-03-16 2023-10-02 カバー株式会社 プログラム、仮想空間提供方法、及び仮想空間提供システム
JP7702032B1 (ja) 2024-11-05 2025-07-02 株式会社コロプラ プログラムおよび情報処理システム
JP2026081732A (ja) * 2024-11-05 2026-05-19 株式会社コロプラ プログラムおよび情報処理システム

Also Published As

Publication number Publication date
JP6442061B2 (ja) 2018-12-19
US11298620B2 (en) 2022-04-12
US20180056196A1 (en) 2018-03-01
US20200324209A1 (en) 2020-10-15
US10729982B2 (en) 2020-08-04
JPWO2018042468A1 (ja) 2018-08-30

Similar Documents

Publication Publication Date Title
JP6442061B2 (ja) ゲームシステム、ゲーム処理方法、ゲームプログラム、およびゲーム装置
US12427401B2 (en) Game program, method for controlling computer, and computer
JP5676676B2 (ja) ビデオゲーム処理装置、及びビデオゲーム処理プログラム
US20140080559A1 (en) Method for implementing a computer game
JP2018171181A (ja) 情報処理装置およびゲームプログラム
JP7299942B2 (ja) 情報処理プログラム、情報処理装置、情報処理システム、および情報処理方法
US10335686B2 (en) Program, control method, and information processing apparatus
JP2018171427A (ja) 情報処理装置およびゲームプログラム
JP2021087504A (ja) 情報処理システム、情報処理装置、情報処理プログラム、および、情報処理方法
JP2019180720A (ja) 情報処理システム、情報処理方法、情報処理装置、および情報処理プログラム
JP5628218B2 (ja) ゲーム装置、ゲームプログラム及び記録媒体。
JP2019217216A (ja) ゲームプログラム、方法、および情報処理装置
JP2019217213A (ja) ゲームプログラム、方法、および情報処理装置
JP7034879B2 (ja) ゲーム装置、ゲームプログラム、ゲームシステム、および、ゲーム処理方法
JP2020014518A (ja) 情報処理装置、ゲームプログラム、及び、情報処理方法
JP2014113271A (ja) ゲームシステム、ゲーム制御装置、ゲーム制御方法、及びプログラム
JP2019025300A (ja) 制御プログラム、制御方法及びコンピュータ
JP2022071383A (ja) 情報処理システム、情報処理プログラム、情報処理装置、および情報処理方法
JP6530430B2 (ja) ゲームプログラム及びゲームシステム
JP2020014826A (ja) 情報処理装置、ゲームプログラム、及び、情報処理方法
JP7831861B2 (ja) 制御プログラム、制御方法、及び端末装置
JP7657103B2 (ja) プログラム
JP7619543B2 (ja) 情報処理システム、ゲームプログラム、情報処理装置、および、ゲーム処理方法
JP7257121B2 (ja) 情報処理装置、ゲームプログラム、及び、情報処理方法
JP2019025039A (ja) 制御プログラム、制御方法及びコンピュータ

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2017534762

Country of ref document: JP

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16915029

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16915029

Country of ref document: EP

Kind code of ref document: A1