U.S. Pat. No. 10,729,982

DETAILED DESCRIPTION OF NON-LIMITING EXAMPLE EMBODIMENTS

Hereinafter, an exemplary embodiment will be described.

FIG. 1is a schematic diagram showing the overview of a game system according to the present embodiment. The game system100of the present embodiment includes a server101and a plurality of portable smart devices102(hereinafter, referred to merely as smart devices) each of which is an example of an information processing apparatus. Each smart device102is, for example, a smartphone, a tablet, or the like. The server101and each smart device102are configured to be able to communicate with each other via the internet.

Next, the configuration of each hardware in the above system will be described.FIG. 2is a functional block diagram of the smart device102. InFIG. 2, the smart device102includes a processor section111, an internal storage device112, a main memory113, a communication section114, an operation section115, and a display section116. The processor section111executes later-described information processing and executes a system program (not shown) for controlling overall operation of the smart device102, thereby controlling operation of the smart device102. The processor section111may include a single processor or a plurality of processors. The internal storage device112stores therein various programs to be executed by the processor section111, and various kinds of data to be used in the programs. The internal storage device112is, for example, a flash EEPROM or a hard disk device. The main memory113temporarily stores therein computer programs and information. The communication section114establishes a connection to a network by wired or wireless communication and transmits/receives predetermined data to/from the server101. The operation section115is, for example, an input device for receiving an operation from a user. The display section116is typically a liquid crystal display unit. In processing according to the present embodiment, a touch panel integrated with a liquid crystal screen is assumed as the operation section115and the display section116. In another embodiment, a predetermined pointing device other than a touch panel may be used as the operation section115.

Next, the configuration of the server101will be described.FIG. 3is a functional block diagram of the server101. The server101includes at least a processor section121, an internal storage device122, a main memory123, and a communication section124. The processor section121executes various programs for controlling the server101. Various programs to be executed by the processor section121and various data to be used by the processor section121are stored in the internal storage device122. The main memory123temporarily stores a computer program and information. The communication section124establishes a connection to a network by wired or wireless communication and transmits/receives predetermined data to/from the smart devices102or another server (not shown).

Next, an operation outline of game processing according to the present embodiment will be described. The game processing according to the present embodiment is game processing having two different game factors of a versus action game and a construction and management simulation (developing) game in which a predetermined development target is developed. In this game, it is possible to selectively execute the versus action game and the developing game. In this game, in the versus action game, a player plays against another player, and a value called “rate” is increased or decreased in accordance of a win/loss result of the play. Then, a development process for the predetermined development target is performed on the basis of this rate. That is, this game is a game in which the rate is reflected in the degree of development of the development target.

Here, the rate in the present embodiment will be additionally described. The rate in the present embodiment is a value representing the skill or ability of the player at the game. That is, the rate is a value that is an index for the skill or ability of the player. For example, the rate is assumed to be indicated at 10 levels of 1 to 10. In addition, an initial rate at the time of new start of the game is assumed to be “5”. Then, when a player performs match-up play, if the player wins, the rate is increased by 1, and if the player loses, the rate is decreased by 1. Therefore, if the player consecutively wins, the rate finally becomes “10”, and if the player consecutively loses, the rate finally becomes “1”. That is, if the player has a rate of “10”, the rate is an index indicating that the player has a high skill at the game, and if the player has a rate of “1”, the rate is an index indicating that the player has a low skill at the game. As described above, the rate in the present embodiment is a value that increases or decreases in accordance with a win/loss result in the versus game, and is a value having a meaning as an index for the skill of the player at the game. In the present embodiment, the rate is indicated as the number of later-described resident characters (the population of a town).

Next, general flow of this game will be further described with reference to the drawings.FIG. 4shows an example of a game screen in the game processing according to the present embodiment. This screen corresponds to a so-called “home screen” in this game. InFIG. 4, the screen includes two display areas, that is, a town area201and a menu area202. In the town area201, a castle object203is displayed. In the present embodiment, the term “town” has a meaning as to seem like a player's “kingdom”. In the present embodiment, the “town” is set as a development target. More specifically, the castle object203is set as the development target (an idea of growth of castle object=growth of town is adopted). In the menu area202, two button images204A and204B are displayed. The button image204A is a button image for solely playing the above-described action game. The button image204B is a button image for playing the action game with another player in a match-up form. That is, it is possible to selectively execute the versus action game from the home screen. In the present embodiment, the case of playing the action game in a match-up form will be described. In the present embodiment, match-up play is performed in one-on-one form using a horizontal scroll-type jumping action game. In the horizontal scroll-type jumping action game, a player who acquires more coins, which are arranged within a stage, within a time limit wins. The present embodiment shows an example of the horizontal scroll-type jumping action game, but any game may be used as long as the game is a versus game. In another embodiment, for example, a racing game or a versus fighting game may be used, or a game other than an action game, for example, a table game such as a card game, or a quiz game, may be used.

Hereinafter, the above-described action game will be described with reference to the drawings. When the player taps the button image204B inFIG. 4, an instruction indicating a request for match-up play is transmitted to the server101. Accordingly, in the server101, an opponent selection process (matching process) is performed. Then, the result of the selection process is transmitted from the server101, and an opponent selection screen is displayed as shown inFIG. 5on the basis of the result. Here, the selection is made by using the rate as described above. Specifically, a process of randomly selecting other players having rates close to that of the player is performed in the server101. That is, the selection is made such that players having skills close to each other to some extent will be matched against each other.

In the opponent selection screen inFIG. 5, information of the player is displayed at the upper left side of the screen, and a list of opponent candidate information of five players is shown at the right side of the screen. As the information of each candidate, the name of the player, an image related to the player (e.g., a portrait image), and a rate are shown. By taping any opponent among the opponent candidates, the player can start match-up play against the opponent.

In another embodiment, selection of a plurality of opponent candidates as described above may not be made, and only one opponent candidate may be selected. In this case, the opponent selection screen may not be displayed, and when the opponent is selected, information of the opponent may be displayed and match-up play may be started.

Here, the match-up in the present embodiment is not a match-up in a real time form, and is an asynchronous-type match-up. Specifically, the match-up in the present embodiment is in form of playing against so-called “ghost data”. When any candidate is tapped in the opponent selection screen, ghost data of the candidate player is downloaded from the server101. The ghost data includes information indicating the configuration of a played stage, information indicating the contents of the play (operations performed by the opponent), information indicating the number of coins acquired by the player, and information indicating the number of later-described resident characters. Then, in the smart device102, a game stage (virtual game space) is generated on the basis of the ghost data, and the player plays the stage. That is, the player competes asynchronously in the number of coins acquired within the same time limit in the downloaded stage which is the same as that of the opponent. The above ghost data is generated as appropriate on the basis of the contents of play performed when the action game is played solely, and is uploaded to the server101. In addition, in another embodiment, a real time-form versus game in which ghost data as described above is not used may be used.

FIG. 6shows an example of a play screen of the action game (versus game). As described above, the action game is a horizontal scroll-type jumping action game. In the game screen shown inFIG. 6, a player character221and coins222are shown. In addition, enemy characters are also present, although the enemy characters are not shown. The player can advance the game stage while collecting coins222within a time limit by operating the player character221.

Meanwhile, in the present embodiment, in the course of advancing the stage, besides the coins, “resident characters” can be acquired by, for example, satisfying a predetermined condition. The resident characters are characters that are residents of the above-described castle object203. The number of the resident characters is related to development (growth) of the castle object. That is, only one resident character is present at new start of the game, and the player can collect resident characters (increase the number of resident characters) by repeating match-up play. When the number of the resident characters (in other words, the population of the town) increases, the castle object203grows (specifically, the appearance thereof changes). Growth of the castle object203will be described later.

Next, determination as to a win/loss in match-up play will be described. When the action game is played and the time limit comes, play in the above stage ends, and a result screen is displayed as shown inFIG. 7. InFIG. 7, information regarding the player is shown in the upper half of the screen, and information regarding the opponent is shown in the lower half of the screen. Specifically, as the information regarding the player, the name of the player, an image231A regarding the player, resident characters233A collected by the player, and the number of coins232A collected by the player are displayed. In addition, a simplified replay area234A is displayed. In this display area, the contents of the play of the player are replayed and displayed in a simplified manner. Moreover, as specific information regarding the opponent, an image231B regarding the opponent, resident characters233B collected by the opponent, and the number of coins232B collected by the opponent are displayed. Furthermore, a simplified replay area234B is displayed in which the contents of the play of the opponent are replayed and displayed in a simplified manner. When the result screen is displayed, data indicating the result of the match-up play at this time may be uploaded to the server101.

In this game, a win or a loss in a match-up is determined on the basis of the number of coins collected. The example ofFIG. 7indicates that the player has collected 61 coins and the opponent has collected 106 coins. Thus, in the example ofFIG. 7, a win for the opponent is determined. Then, regarding the resident characters, the following process is performed in accordance with the win/loss result. First, when the player “wins”, the player can acquire the resident characters233B collected by the opponent. That is, the population of the town of the player can be increased. On the other hand, when the player “loses”, the current population of the town is decreased by the number of the resident characters233A collected by the player in the play. That is, when the player wins in the match-up, the player can acquire the resident characters collected by the opponent, and when the player loses in the match-up, the resident character collected by the player in the play are lost. The number of the resident characters, that is, the population of the town, corresponds to the above-described rate. That is, the number of the resident characters is a parameter that increases or decreases in accordance with the win/loss result of the match-up. Furthermore, the number of the resident characters is considered to increase on the basis of the play result of the player (the number of the resident characters collected by the player) when the player loses and to increase on the basis of the play result of the opponent (the number of the resident characters collected by the opponent) when the player wins. That is, the number of the resident characters is also considered as a parameter that increases or decreases on the basis of the play result of either the player or the opponent. In another embodiment, regarding an increase or decrease in the resident characters, a value of the increase or decrease may be determined on the basis of both the player result of the player and the play result of the opponent.

In the present embodiment, the above increase or decrease in the resident characters has an effect on only the player and does not have an effect on the opponent. That is, even when the player wins and acquires the resident characters of the opponent, the number of the resident characters in the data of the opponent is not decreased. On the other hand, even when the player loses and the number of the resident characters of the player decreases, the number by which the number of the resident characters of the player decreases is not added to the number of the resident characters of the opponent. As described above, in the present embodiment, a match-up is held in an asynchronous manner using ghost data, and the same ghost data is supposed to be downloaded by many players. Thus, no effect is exerted on the data of the opponent.

Next, growth of the castle object203(town) will be described. As described above, the number of resident characters233increases or decreases in accordance of the win/loss result of the match-up play. As the number of the resident characters increases, the castle object203grows.FIGS. 8 to 10show an example of growth of the castle object203.FIG. 8shows the castle object203immediately after new start of the game. The castle object203in this state is in a state where the scale thereof is very small. Hereinafter, the castle object203in this state is referred to as “rank1” castle.

When the number of the resident characters exceeds, for example, 100 as a result of repeating a match-up as described above and collecting resident characters in the “rank1” state, the appearance of the castle object203changes as shown inFIG. 9. In the example ofFIG. 9, the scale of the castle object203is larger than that inFIG. 8. For example, the appearance automatically changes at the time when the number of the resident characters exceeds 100. In other words, for example, the player does not consume predetermined points to cause the castle object203to grow, but the castle object203automatically grows when a predetermined condition has been satisfied. Hereinafter, the castle object203in the state inFIG. 9is referred to as “rank2” castle.

Furthermore, when the number of the resident characters exceeds, for example, 500 as a result of repeating a match-up as described above and collecting resident characters in the “rank2” state, the appearance of the castle object203further changes as shown inFIG. 10. In the example ofFIG. 10, the scale of the castle object203is larger than that inFIG. 9. Hereinafter, the castle object203in the state inFIG. 10is referred to as “rank3” castle.

As described above, as the number of the resident characters233increases, the castle object203grows. As described above, the number of the resident characters has a meaning as the above rate, and there is also an aspect that the number of the resident characters indicates the skill or effort of the player at the game. Thus, the better the player is at the game, the larger the scale of the castle object203can be. In other words, it is considered that the skill or ability of the player at the versus action game is visually reflected in the form of the castle object203and presented to the player. Thus, the motivation of the player for the game can be enhanced. In addition, the degree of growth of the castle object203corresponds to the skill of the player and thus is different for each player. That is, the castle object203grows differently for each player. In the above example, three stages of growth of the castle object203are shown, but it is needless to say that more stages of growth may be provided.

In the present embodiment, the castle object203that has grown does not return to the previous rank state. As described above, the number of the resident characters increases or decreases in accordance with the win/loss result of the match-up. Thus, the number of the resident characters that has reached 100 may decrease to 90 later. Even in such a case, for example, when the castle object203grows to the above “rank2” state since the number of the resident characters exceeds 100, even if the number of the resident characters233decreases to 90 later, the castle object203does not return to the above “rank1” state, and the “rank2” state is maintained. In other words, the degree of growth of the castle object and the number of the resident characters are not completely linked to each other (changed together). If both are completely linked to each other, when the number of the resident characters233decreases (the rate decreases), the rank of the castle object203decreases, which decreases the motivation of the player for match-up play. Thus, by maintaining the degree of growth of the castle object203even when the number of the resident characters decreases as described above, the motivation of the player is maintained.

Next, the game processing according to the present embodiment will be described in detail with reference toFIGS. 11 to 16.

FIG. 11shows an example of programs and information stored in the main memory123of the server101. In the main memory123of the server101, a selection process program301, a player database302, match-up ghost data303, etc. are stored.

The selection process program301is a program for making opponent selection upon reception of a request from the smart device102.

The player database302is a database in which information regarding players who have played this game is stored. Specifically, ID for identifying each player and data of the number of resident characters (i.e., a rate), a current castle rank, etc. are stored so as to be associated with each player.

The match-up ghost data303is ghost data to be used in match-up play as described above, and ghost data regarding a plurality of players is stored therein. The match-up ghost data is generated as appropriate on the basis of the contents of play performed when the above action game is played solely, and is uploaded and stored in the server101. The match-up ghost data303includes, for example, ID of the player for the ghost data, data indicating the configuration of the game stage of the ghost data, and data indicating the number of coins acquired, the number of resident characters acquired, etc.

FIG. 12shows an example of programs and information stored in the main memory113of the smart device102. In the main memory113, a game processing program321, operation data322, resident character number data323, current castle rank data324, castle object data325, rank-up condition definition data326, action stage data327, match-up work data328, etc., are stored.

The game processing program321is a program for performing the game processing as described above. Specifically, the game processing program321is a program for performing later-described processing of a flowchart inFIG. 13.

The operation data322is data indicating various operations performed on the smart device102. In the present embodiment, the operation data322includes button data and touch panel data. These data are data indicating the contents of operations performed on the operation section115, and are data indicating pressed states of various buttons, a touch coordinate of a touch panel, touch duration, etc.

The resident character number data323is data indicating the number of resident characters (the population of the town) as described above. In addition, the data has a meaning as the above-described rate.

The current castle rank data324is data indicating the degree of growth of the castle object203. In the present embodiment, the degree of growth of the castle object203is indicated as a concept of the “rank” as described above.

The castle object data325is image data and model data to be used for rendering the castle object203. In the castle object data325, image data and the like of the castle object203corresponding to the “rank” are stored.

The rank-up condition definition data326is data that defines a condition for causing the castle object203to grow (raising the rank). The rank-up condition definition data326is, for example, data that defines a condition of, for example, “causing the castle object203to grow to rank2when the number of resident objects becomes equal to or larger than 100 in the rank1state”.

The action stage data327is various data for constructing a virtual game space for the action game as described above. That is, the action stage data327includes model data for various terrain objects, enemy characters, player characters, etc.

The match-up work data328is data that is temporarily generated and used in executing the versus game as described above. The match-up work data328includes acquired coin number data329, acquired resident number data330, opponent ghost data331, stage data332, etc. The acquired coin number data329is data indicating the number of coins acquired by the player in the match-up play as described above. The acquired resident number data330is similarly data indicating the number of resident characters acquired by the player in the match-up play. The opponent ghost data331is data obtained by downloading and storing the match-up ghost data303for the opponent from the server101. The contents of the opponent ghost data331are the same as those of the match-up ghost data303. The stage data332is data indicating the configuration of the virtual game space generated on the basis of the opponent ghost data331. That is, the stage data332is data indicating arrangement of terrain objects, enemy characters, coins, and resident characters, etc.

Next, flow of game processing executed by the processor section111of the smart device102will be described with reference to the flowchart inFIG. 13.FIG. 13is a flowchart showing the details of the game processing.

When the game processing is activated on the basis of an activation instruction operation of the player, the processor section111initially performs an initialization process in step S1. In this process, initialization of various data, a login process, a process of acquiring, from the server101, data required for the game processing, etc., are performed. For example, a process of acquiring the current number of resident characters from the player database302and storing the current number of resident characters as the resident character number data323in the main memory113, and acquiring, from the player database302, data indicating the current castle rank and storing the data as the current castle rank data324in the main memory113, etc., are performed.

Next, the processor section111performs a town screen generation process in step S2. That is, a process for generating an image to be displayed in the town area201inFIG. 4is performed.FIG. 14is a flowchart showing the details of the town screen generation process. InFIG. 14, first, in step S11, the processor section111acquires the current castle rank data324from the main memory113. Next, in step S12, the processor section111acquires the resident character number data323from the main memory113. Next, in step S13, the processor section111refers to the rank-up condition definition data326and determines whether a condition for causing the castle object203to grow, that is, a condition for raising the rank, has been satisfied. For example, when the current castle rank is “rank1” and the number of the resident characters is equal to or larger than 100, it is determined that the condition for raising the rank to “rank2” has been satisfied. As a result of the determination, when the rank-up condition has been satisfied (YES in step S13), the processor section111updates, in step S14, the current castle rank data324with a content indicating the rank after raising of the rank (the current castle rank data324updated here is transmitted to the server101as appropriate and the contents of the player database302are also updated as appropriate). On the other hand, when the rank-up condition has not been satisfied (NO in step S13), the process in step S14is skipped.

Next, in step S15, the processor section111acquires the current castle rank data324again and acquires, from the castle object data325, image data and the like of the castle object203corresponding to the contents of the current castle rank data324.

Next, in step S16, the processor section111generates an image of the castle object203on the basis of the acquired image data and the like. This is the end of the town screen generation process.

Referring back toFIG. 13, next, in step S3, the processor section111generates the home screen as shown inFIG. 4on the basis of the generated image of the castle object203and the like, and displays the home screen.

Next, in step S4, the processor section111acquires the operation data322. Subsequently, in step S5, the processor section111determines whether start of a match-up battle has been selected, on the basis of the operation data322. That is, it is determined whether the button image204B in the screen inFIG. 4has been tapped. As a result of the determination, when start of a match-up battle has been selected (YES in step S5), the processor section111performs a versus game process in step S6.

FIG. 15is a flowchart showing the details of the versus game process. InFIG. 15, first, in step S21, the processor section111performs a selection process for searching for an opponent. Specifically, the processor section111transmits a request for the selection process together with information such as the resident character number data323(i.e., the rate) of the player to the server101. Upon reception of the request and the information, the server101refers to the player database302and randomly extracts five players from among players having a close number of resident characters. Then, the server101transmits data indicating the result of the extraction, to the smart device102. When reception of the data is completed, the selection process ends.

Next, in step S22, the processor section111performs a process of generating the opponent selection screen as shown inFIG. 5, on the basis of the result of the extraction received from the server101, and displaying the opponent selection screen. Then, when the player performs an operation of selecting a certain opponent on the screen, the processor section111performs an action game process in step S23. This process will be described more specifically. First, a process of acquiring the match-up ghost data303for the selected opponent from the server101is performed. Then, a virtual game space (game stage) is generated on the basis of the match-up ghost data303, and various characters such as a player character are also located. Then, a game screen is displayed, and an action game process based on an operation of the player is performed as appropriate. In this process, the contents of the acquired coin number data329and the acquired resident number data330are updated as appropriate.

Next, when the action game process ends as a result of elapse of a preset time limit, the processor section111performs a result process in step S24.FIG. 16is a flowchart showing the details of the result process. InFIG. 16, first, in step S31, the processor section111performs a win/loss determination for a match-up on the basis of the acquired coin number data329and data of the number of coins acquired by the opponent which data is included in the opponent ghost data331.

Next, in step S32, the processor section111determines whether the player has won, as a result of the win/loss determination. As a result of the determination, when the player has won (YES in step S32), the processor section111adds the number of resident characters acquired by the opponent which number is indicated by the opponent ghost data331, to the resident character number data323in step S33. On the other hand, when the player has lost (NO in step S32), the processor section111subtracts the number indicated by the acquired resident number data330from the resident character number data323in step S34(the resident character number data323updated here is transmitted to the server101as appropriate and the contents of the player database302are also updated as appropriate).

Next, in step S35, the processor section111generates and displays the result screen as shown inFIG. 7. This is the end of the result process.

Referring back toFIG. 15, when the result process ends, the versus game process also ends.

Referring back toFIG. 13, as a result of the determination in step S5, when a match-up has not been selected (NO in step S5), the processor section111performs another game process on the basis of the operation data322as appropriate in step S7. For example, an action game process for single play or the like is performed.

Next, in step S8, the processor section111determines whether a condition for ending this game has been satisfied. When the condition has not been satisfied (NO in step S8), the processor section111returns to step S2and repeats the process. When the condition has been satisfied (YES in step S8), the processor section111ends the game processing. This is the end of the description of the game processing according to the present embodiment.

As described above, in the game processing of the present embodiment, the player is allowed to enjoy a match-up in the action game, and at the same time, the rate (the number of the resident characters) is increased or decreased in accordance with the result of the match-up and reflected in growth of the castle object203. Accordingly, since the index (rate) indicating the skill, ability, or effort of the player at the game is caused to have a meaning as a reference for a growth element, motivations for play for both the versus action game and development of the castle object203can be synergistically enhanced. In addition, both the index indicating the skill of the player and an element that is a reference for a growth element are based on “resident characters”, and thus can be presented to the player in an easy-to-understand form.

In the above example, the example in which the castle object203grows is shown as an example of development of the “town”. As another example of development of the “town”, predetermined building objects may be able to be arranged around the castle object203stepwise as the population of the resident characters increases.FIG. 17shows an example of an image of the town area201in such case. InFIG. 17, a center area251in which the castle object203is displayed is present at a center portion of the town area201. Twelve square areas (hereinafter, referred to as surrounding areas)252are shown by dotted lines so as to surround the center area251. Regarding growth of the castle object203, similarly to the above, the appearance of the castle object203automatically changes as the number of the resident characters increases. That is, the appearance of the castle object203becomes an appearance corresponding to the current castle rank data324. In addition, for example, when the castle object203grows from the “rank1” state to “rank2”, a predetermined building object may be able to be arranged in any one of the twelve surrounding areas252on the basis of an operation of the player (seeFIG. 18). For example, by the player tapping any one of the twelve surrounding areas252, a screen for selecting a building object to be arranged in the tapped area may be displayed. Also when the castle object203grows from the “rank2” state to “rank3”, a predetermined building object may be able to be arranged further in another area (seeFIG. 19). Alternatively, regardless of the rank of the castle object203, when the number of the resident characters exceeds a predetermined number, a predetermined building object may be able to be arranged in any one of the twelve surrounding areas252on the basis of an operation of the player. For example, when the number of the resident characters reaches 50 or more, it is made possible to arrange a building object in any one area. Thereafter, when the number of the resident characters reaches 100 or more, it may be made possible to further arrange a building object in another area. That is, as the number of the resident characters increases, predetermined building objects may be able to be arranged one by one stepwise in the twelve surrounding areas252on the basis of an operation of the player. In other words, even when the number of the resident characters increases, a predetermined building object is not automatically arranged. That is, the castle object203automatically grows, but the player needs to manually install building objects in the surrounding areas252. As described above, as the “town” which is a development target, two types of objects, that is, the castle object203and building objects that can be arranged in the surrounding areas252as described above, may be included. Because of this, both growth of the castle object203and arrangement of building objects are considered as part of development of the “town”.

As the elements forming the “town” as described above, in addition to the building objects as described above, objects other than buildings, such as flowers, ponds, farms, statues, and playground equipment, may be able to be arranged. In addition, in the above example, the castle object203and the objects to be arranged in the surrounding areas252are arranged in different areas. However, the embodiment is not limited to the case where such two types of objects are arranged in different areas, and one of the two types of objects may be included in an area for the other of the two types of objects. For example, an area that is a “room” is prepared within the castle object203, and another object (a furniture object, etc.) may be able to be arranged in the “room”. Moreover, in this case, the number of “rooms” within the castle may be increased as the castle object203grows.

In the case where the surrounding areas252are used as described above, in addition to the data shown inFIG. 12, for example, surrounding area data341may be further provided as shown inFIG. 20as data related to the castle object203. The surrounding area data341inFIG. 20includes first area data342A to twelfth area data342L corresponding to the twelve surrounding areas252, respectively. Each area data342includes information indicating whether a building object is arranged in the corresponding area, information indicating the arranged building object itself, etc. Each area data342may be initially set to a state where the area data342cannot be changed, and change of each area data342(based on an operation of the user) may be made possible one by one stepwise as the number of the resident characters increases. Then, on the basis of the contents of the area data342, a building object different from the castle object203may be additionally displayed in the corresponding surrounding area252. Accordingly, regarding development of the town, the entertaining features can be further enhanced.

The development target may be, for example, a tower type object, in addition to the castle object203as described above. In the case where the development target is a tower type object, for example, the height of the tower may be increased as the number of the resident characters increases. Moreover, in the above example, as the “town” which is the development target, the case of the single castle object203and the case where the objects to be arranged in the surrounding areas252are also included in addition to the castle object203, have been described. In addition to these cases, the “town” which is the development target may be, for example, a town in which the castle object203as described above is not present and which includes building objects such as a plurality of house objects and shop objects, and various types of objects such as road objects and vehicle objects. In such a case, for example, only two or three building objects may be present in the town at start of the game, and the number of building objects may be automatically increased as the number of resident characters increases. Furthermore, the development target is not limited to the “town”, and may be in any form as long as a plurality of objects are arranged in a predetermined area such as a city, a village, an island, or a room. Moreover, as another development target, an object representing a creature may be set. For example, a predetermined animal object or human object may be displayed as a development target.

In accordance with the contents of play in the action game, the course of growth may be changed. For example, as the resident characters, several types of resident characters are caused to appear. As an example, three types of resident characters, that is, “type A resident”, “type B resident”, and “type C resident”, are assumed to be defined. The number of each type of the resident characters increases or decreases in accordance with a win/loss result of a match-up, similarly to the processing as described above. Then, the contents of growth of the castle object203may be made different in accordance with the proportion of each type of the resident characters acquired by the player in the action game. That is, even for the castle object203in the same “rank2” state, the appearance of the castle object203may be made different depending on the proportion of each type of the resident characters. For example, it is assumed that 100 resident characters are present, and the appearance of the castle object203in the “rank2” state may be made different between when 80 out of the 100 resident characters are “type A residents” and when 80 out of the 100 resident characters are “type B residents”.

For example, a plurality of growth parameters may be previously set for the castle object203, and degrees of influence to be provided to the growth parameters may be made different in accordance with the plurality of types of resident characters. For example, three parameters, that is, a parameter A that is a parameter regarding the color of the castle object, a parameter B that is a parameter regarding the shape of the castle object, and a parameter C that is a parameter regarding the size of the castle object, are previously set as parameters that influence the appearance of the castle object203. At each end of the action game (in the result screen), the value of each parameter may be changed in accordance with the number of each type of resident characters acquired at this time. For example, the number of the type A residents is added to the parameter A, the number of the type B residents is added to the parameter B, and the number of the type C residents is added to the parameter C. Then, at the time of raising the rank of the castle object203, the appearance of the castle object203after the raising of the rank may be changed on the basis of the three parameters. Accordingly, a more unique castle object203corresponding to the contents of play in the action game by the player can be presented, and it becomes possible to enhance the motivation of the player. In addition, in the case where the plurality of parameters as described above are used, at least part of the parameters may be changed on the basis of an element other than the above-described rate (the number of the resident characters). For example, the parameter may be changed on the basis of a time period for which the game is played, or a cumulative number of wins in the versus game. Furthermore, part of the parameters may be changed in a random manner. For example, the parameter C regarding the size of the castle object203may be changed on the basis of the number of the resident characters, but the parameters A and B regarding the color and the shape of the castle object203may be changed in a random manner.

In the case where the plurality of types of resident characters as described above are used, the total population of the plurality of types of resident characters may be used as the above-described rate, or the population of each type of resident characters may be used as the rate (in the latter case, a plurality of types of rates are used).

Regarding the win/loss determination for the action game, a win or a loss is determined on the basis of the number of the acquired coins in the above example. However, in another embodiment, a win or a loss may be determined on the basis of the number of the acquired resident characters, without using coins.

In the above example, the rate (the number of the resident characters), that is, the index indicating the skill of the player, is indicated by a value. However, the index may be indicated other than value, such as “A+”, “A”, “B+”, and “B”. In addition, in this case, “rise” or “increase” of the index means that the index changes to an index indicating a higher skill (e.g., the case where “B+” changes to “A”). Moreover, “fall” or “decrease” of the index means that the index changes to an index indicating a lower skill (e.g., the case where “B+” changes to “B”). Furthermore, for example, an index a higher value of which indicates a higher ability, such as dan, may be used. In this case, “rise” or “increase” of the index corresponds to the case where the index changes from a “third-degree dan” to a “second-degree dan”. In addition, “fall” or “decrease” of the index corresponds to the case where the index changes from a “third-degree dan” to a “fourth-degree dan”.

In another embodiment, a predetermined parameter associated with the player character221in the action game may be changed in accordance with the above-described rate (the number of the resident characters) increasing. For example, in accordance with the number of the resident characters increasing, the parameter of the player character221may be changed such that an advantageous effect for the player is achieved. For example, jumping power or a moving speed of the player character221may be increased. Alternatively, the power or the remaining character number of the player character221may be increased. Still alternatively, the time limit for game play may be extended from an initial time value. Still alternatively, the appearance of the player character221may be merely changed (in this case, an advantageous effect is not necessarily imparted but a change in appearance can be imparted). More specifically, the following control may be performed. First, the parameter as described above is prepared as data regarding the player character221. Then, control may be performed in which the parameter of the player character221is directly changed in accordance with the rate (the number of the resident characters) increasing. In addition, as another control example, the parameter associated with the castle object203may be changed in accordance with the rate (the number of the resident characters) increasing, and the parameter of the player character221may be changed on the basis of the parameter. For example, control may be performed in which the jumping power of the player character221is increased when the “height” of the castle object203exceeds a predetermined value. By performing such control, an effect that is advantageous in the versus game is achieved, and thus the motivation of the player for the versus game can be enhanced. Furthermore, a motivation for the versus game and a motivation to cause the castle object203to grow are constructed as one cycle, and these two motivations can be synergistically enhanced, so that the entertaining features of the game can be further enhanced.

The game program, etc. according to the present embodiment can provide new game processing using an index that indicates the ability of a player at a game, and are useful for application to a portable smart device, various game apparatuses, etc.