JP6145662B2 - GAME CONTROL DEVICE, PROGRAM, GAME SYSTEM - Google Patents

Description

  The present invention relates to a technique for controlling the progress of a game by each user in accordance with each operation of a plurality of users.

  In recent years, a so-called social game (Social) executed by a game application created on the basis of an operating environment such as an API (Application Programming Interface) that operates on a web browser in a social networking service (SNS) by a specific service provider. Game) is popular. It can be said that the social game is a kind of online game that is played while communicating among an unspecified number of users. If a user can connect to the Internet and has a communication terminal equipped with a web browser, the user can enjoy a social game regardless of time and place.

  One of the features of the above-described social game is that it has a richer communication function for interacting with users than conventional online games. In social games, for example, in addition to cooperative play with other users (friends), information exchange by communicating with friends such as greetings and contacts with friends, gifts of items on the game with friends or items An exchange has been made. As an example of such a social game, a digital card game (Dragon Collection (registered trademark)) described in Non-Patent Document 1 below is known.

  A very large number of users register for social games, and each user plays the game at his or her own convenience. Therefore, a battle (battle) between users in a social game is performed asynchronously. For example, when a user who is accessing the game plays against another user (an opponent), it is performed using an opponent parameter or a character parameter associated with the opponent. The opponent is not involved in the match in real time.

Application STYLE Vol.5 (East Press, issued on November 1, 2011), pages 7-8

  In conventional social games, the number of cards as objects used by the user for the battle is a fixed value, or the upper limit of the sum of specific parameters of the cards used for the battle is limited. As a result, the number of cards used for the battle is practically limited. In this case, in order to advance the battle advantageously, a card having a large value of a parameter related to the battle, such as an attack power or a defense power, is automatically selected from the cards held by the user as a card used for the battle, or Often selected in response to user input. Therefore, although the number of cards held by the user itself is large, the number of cards that the user uses for the battle is limited, and there are many cards that are not used for the battle.

  The present invention has been made in view of the above-described viewpoint, and when performing a battle between users, a game control device capable of realizing a mechanism that can effectively use an object associated with the user in the battle, It is an object to provide a game control method, a program, and a game system.

A first aspect of the present invention is a game control device that controls execution of a battle between users using an object.
This game control device
Associating means (51) for associating an object associated with the information about the area occupied in the game space and the first parameter with the user;
Arrangement means (52) for arranging an object used for the battle among objects associated with the user in a predetermined field in the game space;
Based on user input information, a second object that is associated with the user and is not placed in the field is placed on top of any one of the objects placed in the field. Superimposing means (53);
A change means (55) for changing a first parameter associated with any object used by the opponent of the user based on an object of one user in a battle between users;
An erasure means (56) for erasing the object from the field when a parameter associated with the object satisfies a predetermined erasure condition;
Is provided.

The game control device according to the present invention may be a stand-alone game machine used by a user alone, or wirelessly or wiredly with the communication terminal in order to display a game on the user's communication terminal. It may be an information processing apparatus such as a server that can establish communication.
In the present invention, the “object” includes, for example, characters and items on the game. The character is, for example, a virtual person or creature on the game, a monster, or the like, and includes characters displayed on a card.

  In a battle game between users realized by this game control device, an object associated with the user is placed in the field for use in the battle. At this time, the objects are configured to be able to be placed one on top of the other. If the first parameter of the object of the other user (the opponent) satisfies the disappearance condition due to the attack of the object of one user during the battle between the users, for example, the attacked object disappears from the field. Therefore, the user is motivated to increase the sum of the first parameters by the objects on the field by arranging the objects associated with the objects in an overlapping manner in order to advance the battle advantageously. In other words, if an object associated with a user includes an object with a low usage frequency on the game, it can be motivated to place the object on another field and use it on the field. Therefore, the card | curd which a user uses for a battle | competition is restricted, and the situation where there are many cards which are not used for a battle | competition can be avoided. In addition, when a plurality of cards are arranged in an overlapping manner, for example, an object that has been attacked disappears, so that the use result of the cards arranged in an overlapping manner can be presented to the user in an easy-to-understand manner. As described above, according to this game control device, it is possible to realize a mechanism that can effectively use an object associated with a user in a battle when performing a battle between users.

In the game control device, when the plurality of objects are arranged so as to overlap with each other, the changing means (55) selects an object for which the first parameter is changed among the plurality of objects at random or in a predetermined manner. You may decide according to a rule.
In this configuration, the progress of the battle or the battle time can be adjusted, and the degree of freedom of game setting increases. For example, by limiting the number of objects to be changed in the first parameter, it is possible to set the progress of the battle and / or the battle time to an appropriate one.
Further, in the above configuration, for example, when a plurality of objects with different attributes are arranged in an overlapping manner, it is difficult for the user to predict the object to be changed in the first parameter among the plurality of objects. The user's attention can be more attracted to the disappearing object among the plurality of objects that have been set. In addition, when an object to be changed in the first parameter is determined according to a predetermined rule, for example, it is possible to realize a highly strategic battle game that allows the user to consider the order in which a plurality of objects having different attributes are stacked. .

In the above-described game control device, when the plurality of objects are arranged in an overlapping manner, the changing means (55) arranges the object for which the first parameter is changed among the plurality of objects at the top. It may be an object.
Note that the vertical relationship between a plurality of objects arranged in an overlapping manner means the arrangement order of the objects. That is, the object arranged at the bottom is the object arranged first, and the object arranged at the top is the object arranged last. This vertical relationship does not necessarily coincide with the vertical positional relationship in the game image of the plurality of objects.
In this configuration, for example, when a plurality of objects having different attributes are to be placed on top of each other, the user is considered to determine the order of objects to be lost among the plurality of objects. A high competitive game can be realized. For example, during a match, the top object among the multiple objects placed in a layer disappears in order, so by determining the order in which the multiple objects are stacked, the user can use it at the beginning of the battle, for example You can use different objects to be used and objects to be used at the end of the match.

In the game control device, each object is associated with information about an attribute,
The superimposing means (53) may arrange an object having the same attribute as that of the object on the object arranged on the field.
In this configuration, since a plurality of objects having the same attribute are arranged so as to overlap each other, for example, by looking at the topmost object or the display content thereof, the user can attribute the plurality of objects arranged so as to overlap each other. Can be recognized immediately. In addition, for example, when the first parameter of the object having the same attribute is the same level, the lost object indicates that the user is attacked by a plurality of overlapping objects during the battle. Can be recognized.

In the game control apparatus, the superimposing means (53) may limit the number of objects that can be placed on the object placed on the field to a predetermined number or less.
In this configuration, since the number of objects that can be placed on top of each other is limited, in order to guide the battle advantageously, the user should consider selecting objects to be placed on top of the objects associated with the user. Therefore, it is possible to realize a highly competitive battle game.

In the game control device, each object is associated with a second parameter,
Limiting means for limiting the sum of the second parameter of the object associated with the user and disposed on the field and the object disposed on the object to be a predetermined value or less ( 58).
In this configuration, the number of objects placed in an overlapping manner is substantially limited based on the sum of the second parameters of the user's objects existing in the field. The user is allowed to consider which object is to be placed in an overlapping manner, and a highly competitive battle game can be realized.

A second aspect of the present invention is a game control device that controls the execution of a battle between users using an object, as in the first aspect.
An association means (51) for associating an object associated with information relating to an area in the game space and information relating to the first parameter and the attribute to the user;
Arrangement means (52) for arranging an object used for the battle among objects associated with the user in a predetermined field in the game space;
Based on user input information, a second object that is associated with the user and is not placed in the field is placed on top of any one of the objects placed in the field. Superimposing means (53);
A change means (55) for changing a first parameter associated with any object used by the opponent of the user based on an object of one user in a battle between users;
An erasure means (56) for erasing the object from the field when a parameter associated with the object satisfies a predetermined erasure condition;
Is provided. The superimposing means (53) arranges an object having the same attribute as that of the object on the object arranged on the field based on the user input information.

A third aspect of the present invention is a game control method for controlling execution of a battle between users using an object.
This game control method
Associating a user with an object associated with information relating to an area occupied in the game space and the first parameter;
Placing an object used for the battle among objects associated with the user in a predetermined field in the game space;
Based on user input information, a second object that is associated with the user and is not placed in the field is placed on top of any one of the objects placed in the field. Steps,
In a match between users, based on an object of one user, changing a first parameter associated with any object used by the opponent of the user;
Erasing the object from the field when a parameter associated with the object satisfies a predetermined erasure condition;
Is provided.

According to a fourth aspect of the present invention, in order to control execution of a battle between users using an object,
A function for associating a user with an object associated with information relating to an area in the game space and the first parameter;
A function of arranging an object used for the battle among objects associated with the user in a predetermined field in the game space;
Based on user input information, a second object that is associated with the user and is not placed in the field is placed on top of any one of the objects placed in the field. function,
In a battle between users, based on an object of one user, a function for changing a first parameter associated with any object used by the opponent of the user, and
A function for erasing an object from the field when a parameter associated with the object satisfies a predetermined erasure condition;
It is a program for realizing.

  The computer may be a network server, a large computer, or the like, for example. Further, this program may be stored in a computer-readable information storage medium such as a DVD-ROM or a CD-ROM.

A fifth aspect of the present invention includes a communication terminal (10) and a server (20) accessed from the communication terminal (10), and a game that controls execution of a battle between users using an object System.
This game system
An associating means (51) for associating a user with an object associated with information relating to an area in the game space and the first parameter;
Arrangement means (52) for arranging an object used for the battle among objects associated with the user in a predetermined field in the game space;
Based on user input information, a second object that is associated with the user and is not placed in the field is placed on top of any one of the objects placed in the field. Superimposing means (53),
A change means (55) for changing a first parameter associated with any object used by the opponent of the user based on the object of the one user in a battle between users; and
An erasure means (56) for erasing the object from the field when a parameter associated with the object satisfies a predetermined erasure condition;
Either one of the communication terminal (10) and the server (20) includes these means.

  The communication terminal (10) may be, for example, a mobile terminal, a smartphone, a PDA (Personal Digital Assistant), a personal computer, a television receiver having a bidirectional communication function, a game device with a communication function, or the like.

  In the above, in order to facilitate the understanding of the present invention, the reference numerals shown in the drawings are appropriately described in parentheses, but this restricts the game control device and the like according to the present invention to the illustrated embodiment. It is not a thing.

  According to the game control device, the game control method, the program, and the game system of the present invention, when performing a battle between users, a mechanism that can effectively use an object associated with the user in the battle is realized. it can.

The figure which shows the basic composition of the game system of embodiment. The figure which shows the example of the external appearance of the communication terminal of embodiment. The figure which shows the example of the external appearance of the communication terminal of embodiment. The block diagram which shows the structure of the communication terminal of embodiment. The block diagram which shows the structure of the game server of embodiment. The block diagram which shows the structure of the database server of embodiment. The figure which shows the structural example of a user database. The figure which shows the structural example of a card database. The figure for demonstrating the battle field of the game of embodiment. The figure which shows an example of arrangement | positioning of the card | curd in the battle field of the game of embodiment. The figure which shows the example of a series of web pages displayed on a communication terminal when a battle between users is performed in the game of embodiment. The figure which shows the example of a series of web pages displayed on a communication terminal when a battle between users is performed in the game of embodiment. The figure which shows the example of a series of web pages displayed on a communication terminal when a battle between users is performed in the game of embodiment. The figure which shows the example of a series of web pages displayed on a communication terminal when a battle between users is performed in the game of embodiment. The figure which shows the example of a series of web pages displayed on a communication terminal when a battle between users is performed in the game of embodiment. The figure which shows the example of a series of web pages displayed on a communication terminal when a battle between users is performed in the game of embodiment. The figure for demonstrating the front movement of the card | curd in a battle. The figure for demonstrating the horizontal movement of the card | curd in a battle. The figure which shows in order an example of the movement aspect of each card | curd from the start to the end of a battle. The figure which shows in order an example of the movement aspect of each card | curd from the start to the end of a battle. The figure which shows in order an example of the movement aspect of each card | curd from the start to the end of a battle. The functional block diagram of the game control apparatus of embodiment. The figure which shows an example of a data structure of battle use card data. The flowchart which shows an example of the whole process of the battle game of embodiment. The flowchart which shows an example of a card arrangement | positioning process. The flowchart which shows an example of attack processing. The flowchart which shows an example of a card | curd forward movement process. The flowchart which shows an example of the horizontal movement process of a battle other party's card | curd. The flowchart which shows an example of the horizontal movement process of a user's card | curd. The figure which shows the example of a display of the loss | disappearance aspect of a card | curd. The figure which shows the example of a display of the disappearance aspect of a card | curd. The functional block diagram of the game control apparatus which concerns on the modification of embodiment. The figure for demonstrating the horizontal movement method of a modification. The figure which shows in order an example of the movement aspect of each card | curd from the start of a battle to the end in a modification. The figure which shows in order an example of the movement aspect of each card | curd from the start of a battle to the end in a modification. The figure which shows in order an example of the movement aspect of each card | curd from the start of a battle to the end in a modification. The figure which shows in order an example of the movement aspect of each card | curd from the start of a battle to the end in a modification. The flowchart which shows the modification of the horizontal movement process of a battle other party's card | curd in a modification. The flowchart which shows the modification of the horizontal movement process of a user's card | curd in a modification. The figure which shows the example of assignment between a communication terminal, a game server, and a database server about each function of the game control apparatus of embodiment. The figure which shows the example of assignment between a communication terminal, a game server, and a database server about each function of the game control apparatus of embodiment.

Hereinafter, an embodiment of the game system of the present invention will be described.
(1) Configuration of Game System FIG. 1 shows a system configuration example of a game system according to the embodiment. As shown in FIG. 1, the game system includes communication terminals 10a, 10b, 10c,... That can be connected to a communication network NW (network) such as the Internet, a game server 20 connected to the communication network NW, The database server 30 is configured. Each of the communication terminals 10a, 10b, 10c,... Is a terminal operated by an individual user, for example, a mobile terminal, a smartphone, a PDA (Personal Digital Assistant), a personal computer, a television having a bidirectional communication function. A communication terminal such as a John receiver (including a so-called multi-function smart TV). In the following description, when referring to the communication terminals 10a, 10b, 10c,.
In this game system, the game server 20 is configured to be able to communicate with the communication terminal 10 that is a client, and provides a gaming service to the communication terminal 10. The game server 20 is mounted with an application operable on a web browser as a game application. The database server 30 stores various information to be described later in executing the game, and is connected to the game server 20 by, for example, a wire for reading and writing the information.
The communication terminal 10 includes a web browser capable of displaying a web page provided by the game server 20, and the user operates the communication terminal 10 on the web page to execute a game.

  Although not shown in FIG. 1, an authentication server for authenticating the user of each communication terminal 10 may be provided separately from the game server 20. Further, when a plurality of game servers 20 are provided in order to accept access from many communication terminals 10, a load balancer for adjusting a load between the plurality of game servers 20 may be provided. The game server 20 may be configured as a single server device, but may be configured as a plurality of server devices having distributed functions.

(2) Configuration of Communication Terminal The communication terminal 10 will be described with reference to FIGS. 2A, 2B, and 3.
2A and 2B are diagrams each showing an example of the external appearance of the communication terminal 10. FIG. 2A illustrates a button input type communication terminal such as a foldable mobile terminal (mobile phone). FIG. 2B illustrates a communication terminal of a touch panel input method such as a smartphone. FIG. 3 is a block diagram showing an internal configuration of the communication terminal 10.
As shown in FIG. 3, the communication terminal 10 includes a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, a RAM (Random Access Memory) 13, an image processing unit 14, an instruction input unit 15, a display unit 16, A communication interface unit 17 as a signal transmission / reception unit is provided, and a bus 18 for transmitting a control signal or a data signal between the units is provided.

  The CPU 11 loads the web browser in the ROM 12 into the RAM 13 and executes it. And CPU11 is based on the appropriate designation | designated of URL (Uniform Resource Locator) input to a user by the instruction | indication input part 15 grade | etc., Data for displaying a web page from the game server 20 via the communication interface part 17, That is, data of an object such as an HTML (HyperText Markup Language) document and an image associated with the document (hereinafter collectively referred to as “HTML data” as appropriate) is acquired via the communication interface unit 17. Run a web browser to interpret the HTML data. The communication terminal 10 may be mounted with various plug-ins for extending the browser function of the web browser. An example of such a plug-in is a flash player by Adobe Systems Inc. (USA), which plays a SWF format file. Alternatively, the HTML data in this embodiment may be in the HTML5 format having a moving image and audio playback function.

  The web browser performs communication with the game server 20 in accordance with HTTP (HyperText Transfer Protocol). When the URL (Uniform Resource Locator) or menu on the web page is selected by the user operating the instruction input unit 15, the web browser sends an HTTP request including the selection result to the game server 20 for updating the web page. Send to. The web browser acquires HTML data from the game server 20 as an HTTP response, interprets it, and displays the web page on the display unit 16 via the image processing unit 14.

  The image processing unit 14 displays a web page on the display unit 16 based on display image data provided from the CPU 11 as an analysis result of HTML data. The display unit 16 is, for example, an LCD (Liquid Cristal Display) monitor including thin film transistors arranged in a pixel unit in a matrix, and drives the thin film transistors based on the display image data to display the image of the web page on the display screen 16a. To display.

  When the communication terminal 10 is a button input type communication terminal (FIG. 2A), the instruction input unit 15 includes a button group 15a including a plurality of instruction input buttons such as a direction instruction button and a decision button for accepting a user operation input. And a button group 15b including a plurality of instruction input buttons such as a numeric keypad, and includes an interface circuit for recognizing a pressing (operation) input of each button and outputting it to the CPU 11. For example, the direction instruction button is provided to instruct the CPU 11 to scroll and display the web page displayed on the display unit 16. The determination button is provided for instructing the CPU 11 to select the URL or menu that is actively displayed (for example, highlighted) when a plurality of URLs or menus are displayed on the web page, for example. It is done. When the communication terminal 10 is configured by a small portable terminal, these buttons are provided on the front surface of the communication terminal 10 so that the user can easily operate (click) with the thumb while holding the communication terminal 10 with one hand. It is preferable to arrange | position. In the example shown in FIG. 2A, the button group 15b is arranged below the button group 15a and includes a plurality of instruction input buttons on which “0” to “9”, “*”, and “#” (tenkeys) are written. .

  When the communication terminal 10 is a touch panel input type communication terminal (FIG. 2B), the instruction input unit 15 mainly accepts touch panel type input by touching the display screen 16a with a fingertip or a pen. The touch panel input method may be a known method such as a capacitance method. As illustrated in FIG. 2B, the button group 15a may be provided even when the communication terminal 10 is a touch panel input method.

  For example, when the communication terminal 10 is a portable terminal, the menu selection operation on the web page displayed on the communication terminal 10 is selected by pressing the direction instruction button and selecting by pressing the enter button. This is done by confirming the selected menu. Further, for example, when the communication terminal 10 is a touch panel input method, the selection operation is performed by instructing (touch operation) a menu position on the display screen 16a on which the web page is displayed with a finger or a pen.

(3) Configuration of Game Server The configuration of the game server 20 will be described with reference to FIG.
The game server 20 manages a game website including a plurality of hierarchical web pages, for example, and provides a game web service to the communication terminal 10. As shown in FIG. 4, the game server 20 includes a CPU 21, a ROM 22, a RAM 23, a database (DB) access unit 24, and a communication interface unit 25, for transmitting control signals or data signals between the units. A bus 26 is provided. In addition, the game server 20 can take the same structure as a general-purpose web server regarding hardware.

The ROM 22 stores an application program that provides a service for displaying an object such as an HTML document or an image (displaying a web page) to the web browser of the communication terminal 10 that is a client. The ROM 22 stores various data referred to by the CPU 21 in addition to the application program.
The CPU 21 loads the game program in the ROM 22 to the RAM 23 and executes it, and performs various processes via the communication interface unit 25.

For example, the CPU 21 performs communication according to HTTP with the web browser of the game server 20 via the communication interface unit 25. For example, the CPU 21 is predetermined based on an HTTP request received from the communication terminal 10 via the communication interface unit 25 (for example, as described above, including the user's URL or menu selection result on the web page). Data processing and arithmetic processing are performed, and an HTTP response including the processing result is returned to the web browser of the game server 20. The HTTP response includes HTML data for updating the web page. When the game server 20 performs an authentication process for the user of the communication terminal 10, the CPU 21 performs the authentication process.
The database access unit 24 is an interface when the CPU 21 reads / writes data from / to the database server 30.

(4) Configuration of Database Server The database server 30 (storage device) can be realized by a general-purpose storage such as a large-capacity hard disk device or a device such as a RAID (Redundant Array of Inexpensive Disks). Each database in the database server 30 is configured to be able to read and write data from the CPU 21 via the database access unit 24 of the game server 20.
FIG. 5 shows an example of the configuration of the database server 30. As shown in FIG. 5, the database server 30 includes a user database 31 and a game database 32.

  As an example of a game realized by the game server 20 of the present embodiment, a monster card (hereinafter referred to as a virtual monster card) virtually held on a game between users or between a user and a CPU according to a user's operation on the communication terminal 10. In this case, a battle game in which a battle using simply “card”) is performed is taken up. Hereinafter, this battle game is simply referred to as “game” or “game of the present embodiment” as appropriate.

  FIG. 6 shows an example of the user database 31 applied in the game of the present embodiment. In this example, the user database 31 includes information on each item of a user name, a user image, a game level, an available cost, and a possessed card for each user ID (user identification information). Information included in the user database 31 can be updated sequentially by the game server 20.

In the following description, the user ID included in the user database 31 or data for each user name (to be described later) specifying the user is generically referred to as user data. The data of each item constituting the user data is as follows.
-User name A user name is a user name displayed in order to identify the user of the communication terminal 10 at the time of execution of a game. The user name is, for example, a text having a predetermined length or less designated in advance by the user. The user name is a name that identifies the user on the network environment (or game community) provided by the game server 20.
-User image A user image is an image displayed in order to specify the user of the communication terminal 10 at the time of execution of a game, for example, may be an avatar image previously selected by the user.
-Game level It is the data which shows the progress degree in a user's game, and is a value which increases as a user progresses the game. For example, the game level is a level value in a range from Lv1 (level 1) to Lv100 (level 100), for example. The game level increases according to a rule defined in advance in the game of the present embodiment. The game level may increase, for example, as the number of wins by the user in the battle or the winning percentage in the battle increases.
-Usable Cost As will be described later, in the game of the present embodiment, a cost is associated with each card. The usable cost is an upper limit value of the sum of the costs of cards that can be used by the user in one battle. That is, the user may be required to select a card to be used in the battle so that the total cost of each card is equal to or lower than the usable cost in one battle. The available cost may be set to a larger value as the game level increases, for example.
It is not indispensable to set the usable cost, that is, to set the upper limit value of the total cost of the cards that the user can use in one battle.
-Owned card The owned card is a card that the user holds in the game. The information about the possessed card includes a card ID (C084 or the like) that is information for identifying the retained card, and the number of each card (the number of possessions).

Returning to FIG. 5, the game database 32 stores and updates information related to the progress of the game executed by the game server 20 based on the access from the game server 20. Information relating to the progress of the game may include various information depending on the nature of the game. Taking the case of the game of this embodiment as an example, the information related to the progress of the game includes the results of battles between different users. The game database 32 further stores a card database.
FIG. 7 shows a configuration example of the card database. As shown in FIG. 7, the card database includes information on characters, HP (Hit Points), attack power, defense power, attack range, attack frequency, size, cost, and character images for each card ID. The contents of each information are as follows.

The character corresponding to the character card is information about the name of the monster character (M3, M8, etc.) displayed on the card. A character is an example of information related to an attribute.
・ HP
The HP of the card is a parameter indicating the initial physical strength of the card in the battle. If the HP of a card becomes zero due to an attack from an enemy card during the battle, that card will disappear in the battle.
-Attack power The attack power of the card is a parameter indicating the attack power of the card in the battle. As the value of the attack power of the card is larger, the HP of the attack target enemy card can be reduced more in the battle.
-Defense power The defense power of a card | curd is a parameter which shows the defense power with respect to the attack of the enemy card in a battle. The higher the defense power of the card, the more difficult it is for the battle to reduce its HP against enemy attacks.
-Attack range The attack range of a card is a parameter indicating the range of the attack of the card. The higher the attack range value, the more attacks can be made against enemy cards that are farther in the battle.
-Attack frequency The card's attack frequency is a parameter indicating the frequency with which the card attacks (that is, the number of attacks per fixed time). A larger attack frequency value means more frequent attacks.
-Size The card size is a value indicating the size of a cell occupied by the card when the card is placed in a battle field described later. As will be described later with reference to FIG. 8, cards are arranged in a battle field in which a matrix of cells is formed in the battle. The values of X and Y of the card size are respectively determined in the row direction and the column direction. Indicates the number of cells occupied. The card size of the same monster character is the same.
Cost The cost of a card is a parameter that is referred to when the user considers whether or not the card is a card used for battle (hereinafter also referred to as “battle use card” as appropriate). In the game of the present embodiment, the total cost of battle use cards may be limited to a usable cost or less. In addition, although the cost of a card | curd may be set large, so that attack power is large, it is not restricted to it.
Image The card image is a character image displayed on the card in the game image. The JPG format is merely an example of a card image file format, and other image file formats may be used.

(5) Game of this embodiment Hereinafter, the game of this embodiment is demonstrated, referring FIGS. 8-9, 10A-10F, FIGS. 11-12, and FIGS. 13A-13C.

(5-1) Arrangement of Battle Field and Card In the game of the present embodiment, a battle field is provided in the game space, and a card group of each user who performs a battle is arranged on the battle field. Battles with cards are performed in the battle field.
In the game of this embodiment, the battle between users is performed asynchronously. That is, when a user accessing the game executes a battle with another user, the game is performed using the parameters of the card associated with the battle opponent (other user), and the battle opponent is in the battle. Not involved in real time. In the following description, in a battle between users, a user who accesses a game and starts executing a battle is referred to as an “execution user”. On the other hand, a user who becomes a battle partner of the execution user is referred to as an “enemy user”.
Note that the enemy user may not be an actual user, and may be, for example, a virtual enemy user (that is, a computer).

  First, the battle field will be described with reference to FIG. FIG. 8 is a diagram for explaining an example of the battle field BF of the game according to the present embodiment. As shown in FIG. 8, the battle field BF includes a user area UAa for arranging the execution user's card group and a user area UAb for arranging the enemy user's card group. In the example of FIG. 8, the user area UAa is formed of a matrix of 3 × 6 cells Ca (m, n) (m: an integer of 1 to 3, n: an integer of 1 to 6). The user area UAb is formed in a matrix of 3 × 6 cells Cb (m, n) (m: an integer of 1 to 3, n: an integer of 1 to 6). The card groups of the user area UAa and the user area UAb are arranged to face each other with the reference line L0 interposed therebetween. As shown in FIG. 8, m corresponds to a row when the reference line L0 is used as a reference, and n corresponds to a column when the left end is used as a reference. The first row of the user area UAa of the execution user and the user area UAb of the enemy user are examples of the first reference row and the second reference row, respectively. During the battle, each card of the executing user moves in the user area UAa and each card of the enemy user moves in the user area UAb, but does not move beyond the reference line L0.

In FIG. 8, each user area UAa, BFb is configured by a matrix of 3 × 6 cells is merely an example, and each area may be formed by a matrix of an arbitrary size.
You may change the magnitude | size of a user area | region according to a user's game level. For example, the user area may be set wider as the game level increases. Accordingly, the user can place more cards in his / her user area as the game level increases, which is advantageous for the battle.
In the battle between users, the size of the user area in the battle field may be adjusted based on both game levels. For example, when a user with a relatively high game level battles with a user with a relatively low game level, the user area is made smaller. For example, in FIG. 8, when the game level of the executing user is higher than that of the enemy user, the reference line L0 may be moved downward in the drawing. As a result, the card group of the user having a relatively high game level faces the enemy user's card group with a smaller number of cards, and the user having a relatively high game level is disadvantageous. That is, a user with a high game level can place only a smaller number of cards. Therefore, an antagonistic battle can be expected even in a battle between users with different game levels.

  Although FIG. 8 shows a case where the size of each card arranged in the battle field BF is 1 × 1 as an example, the present invention is not limited to this case. For example, as shown in FIG. 9, cards of different sizes can be arranged in the battle field BF. FIG. 9 is a diagram illustrating another example of the arrangement of cards in the battle field of the game according to the present embodiment. In FIG. 9, in addition to the 1 × 1 size card, two 2 × 2 size cards are arranged in the user area UAa of the execution user, and the 1 × 3 size card is placed in the user area UAb of the enemy user. An example in which two cards are arranged is shown.

(5-2) Progress of Battle FIGS. 10A to 10F are diagrams illustrating examples of a series of web pages displayed on the communication terminal 10 when a battle between users is performed in the game of the present embodiment.
Hereinafter, a case where the execution user is a user whose user name is “KNM” (hereinafter referred to as user KNM) will be described as an example.
In the following description, menus, marks and the like displayed on the web page displayed on the communication terminal 10 are arranged at desired positions on the web page, and are menus visually recognized on the communication terminal 10. The position on the display screen of the mark and the like can be changed by scrolling the web page by the user's direction instruction button or touch panel operation.

The web page P0 in FIG. 10A is an example of the top page of the game of the present embodiment, and is configured according to individual user IDs. 10A includes a user image display area 101, a user data display area 102, and a menu display area 103.
The user image display area 101 is an area in which a user image included in the user data of the execution user KNM is displayed.
The user data display area 102 is an area in which “game level” (simply “level” in the figure) and “card count” data of the execution user KNM are displayed. The “card number” is the total number of cards owned by the user. As illustrated in FIG. 10A, when “number of cards” is written as “40/60”, the user has 40 cards and the maximum number of cards that can be held is 60. Indicates. The maximum number of cards that can be held may be set according to the game level of the user, or may not be set in particular.
The menu display area 103 is an area in which a basic menu provided in the game of the present embodiment is displayed, and an example in which a menu m1 (“battle”) is provided on the web page P0 in FIG. 10A is shown. Although not shown, another menu for executing a game other than the battle may be provided.

  When there is an operation input for the menu m1 on the web page P0, the web page is updated as indicated by P1. In the web page P1, a menu m2 (“place automatically”) is used as a menu for placing a card (hereinafter referred to as “battle use card”) used by the execution user in the user area UAa in the battle field on the web page P1. And a menu m3 ("place yourself"). The menu m2 (“automatically arrange”) is a menu for automatically selecting and using a battle use card from the user's possessed cards. The menu m3 ("place by yourself") is a menu for the user to select and place a battle use card from the user's possessed cards by a user operation.

When there is an operation input for the menu m3 (“place yourself”) on the web page P1, the web page is updated as shown in P2. On the web page P2, a matrix 201 composed of a plurality of cells corresponding to each cell in the user area UAa in the game space is displayed. When any cell in the matrix 201 performs a selection operation, the user KNM can designate a cell in the user area UAa where a card is to be placed. That is, the card arrangement with respect to the matrix 201 is reflected in the card arrangement in the user area UAa in the game space. Here, for example, it is assumed that the cell 201a in the matrix 201 is selected and operated. In this case, the web page is updated as shown in P3. The web page P3 is configured to display a list of cards owned by the user KNM and select any one of cards to be arranged from the list. For example, when the monster M3 card is selected in the web page P3, the web page is updated as shown in P4. In the web page P4, the matrix 201 is displayed in a state where the card selected on the web page P3 is arranged on the cell 201a.
At this time, as shown on the web page P4, the total cost of the arranged cards (referred to as “total cost”) may be displayed. When the total cost of cards placed by the executing user in the user area UAa is limited to a predetermined value or less, the user can perform card placement processing while paying attention to the displayed total cost value. .

As shown in FIG. 10A, the web page P4 includes a menu m4 (“place more”), a menu m5 (“change placed card”), a menu m6 (“cancel placed card”), and a menu. m7 ("Battle with current arrangement") may be provided.
The menu m4 (“place more”) is a menu for additionally placing cards in unplaced cells on the matrix 201. The menu m5 (“change arranged card”) is a menu for changing a card already arranged on the matrix 201 to another card. The menu m6 (“cancel arranged cards”) is a menu for canceling the arrangement of cards already arranged on the matrix 201. The menu m7 (“Battle with Current Arrangement”) is a menu for completing the card arrangement process and proceeding to the next step (that is, a menu for issuing an arrangement end instruction).

In the web page P4, when there is an operation input for the menu m4 (“more arranged”), the web page is updated in the same manner as P2. In this example, since a card has already been placed in the cell 201a, a cell other than the cell 201a can be selected. By repeatedly updating the web page of P 2 → P 3 → P 4 → P 2 →..., The user can sequentially arrange the cards in the matrix 201.
In the web page P4, when there is an operation input to the menu m5 (“change the arranged card”) with any card arranged in the matrix 201 selected, the web page is updated in the same manner as P3. . As a result, it is possible to select another card to replace the selected placed card.
In the web page P4, when there is an operation input to the menu m6 (“Cancel placed card”) while any card placed in the matrix 201 is selected, the selected card is deleted from the matrix 201. .
In the web page P4, when there is an operation input for the menu m7 (“battle with current layout”), the card layout process is terminated, and the web page is updated as indicated by P5 in FIG. 10D.

  In the present embodiment, a plurality of cards can be stacked on one cell (hereinafter also referred to as “stack” as appropriate). For example, in the web page P2a of FIG. 10B, it is assumed that a card is already arranged in the cell 201a. In this case, when the user selects the cell 201a again, another card can be placed on the already placed card. When the cell 201a is selected and operated on the web page P2a, a list of possessed cards is displayed as in P3 of FIG. 10A. Here, when the card of the monster M3 is selected, the web page is updated as shown in P4a. In the web page P4a, the matrix 201 is displayed in a state where two cards are overlapped in the cell 201a. In this embodiment, as shown in FIG. 10B, an example is shown in which cards with the same attribute (that is, cards of the same monster M3) are stacked. However, when a plurality of cards are stacked in the same cell. The plurality of cards may not necessarily have the same attribute.

  The web page P4x in FIG. 10C is an example of a web page similar to P4 and P4a, but shows a display example when the arrangement of cards by the user is completed. In the matrix 201 exemplified in the web page P4x, three cards (monster M3 cards) are placed on the cell 201a so as to overlap (that is, stacked), and two cards (monster M5 cards) are placed in the cell 201b. Are displayed in a state where one card (monster is not shown) is arranged in other cells.

  In the present embodiment, the vertical relationship between a plurality of cards arranged in an overlapping manner means the arrangement order of the cards. That is, the card arranged at the bottom is the card arranged first, and the card arranged at the top is the card arranged last. This vertical relationship does not necessarily need to coincide with the vertical positional relationship in the game image of a plurality of cards arranged in an overlapping manner. For example, a plurality of cards stacked in the cells 201a and 201b of the web page P4x are displayed upright in the game space as will be described later with reference to FIG. The vertical relationship between the stacks) and the vertical positional relationship in the game image do not match.

  After a plurality of cards are stacked on one cell, an operation input to the menu m5 (“change the arranged card”) or the menu m6 (“cancel the arranged card”) is performed with the selected cell. If so, all of the stacked cards may be subject to change or cancellation, or the user can select a card to be changed or canceled from among the stacked cards. The page may be updated.

  As shown in FIG. 10D, after the card placement process is completed (that is, after an operation input of the menu m7), a web page P5 including a list of other users who are battle opponents is displayed. When any user is selected as a battle opponent (that is, an enemy user) from this list, the web page is updated as shown in P6. In this example, an example in which a battle is performed between the user KNM and the user ABC is shown. In the web page P6, when there is an operation input for the menu m10 (“battle start”), a battle is started between the user KNM and the user ABC.

  10E and 10F show web pages of P7 illustrating the display state at the start of the battle, P8 and P9 illustrating the display state during the battle, and P10 illustrating the display state at the end of the battle. The web page from the start to the end of the battle may be reproduced by animation. As shown in the web page P7, for example, when a battle is executed, an image obtained by viewing the battle field BF from a diagonally upper viewpoint in the game space is displayed.

  In addition, in web page P7 of FIG. 10E, the battle use card | curd is arrange | positioned as shown to the matrix 201 of web page P4x of FIG. 10C in the battle start time. That is, three cards and two cards are stacked in the cells Ca (1, 1) and Ca (1, 6) of the user area UAa of the battle field BF, respectively. The cell Ca (1, 1) is a cell on the battle field BF corresponding to the cell 201a of the web page P4x, and the cell Ca (1, 6) is a cell on the battle field BF corresponding to the cell 201b of the web page P4x. is there. In FIG. 10E and FIG. 10F, the monster characters of the cards stacked at the start of the battle are displayed, and the characters of the other cards (that is, only one card placed in the same cell at the start of the battle) are displayed. Is omitted. In each web page of FIG. 10E and FIG. 10F, the card | curd arrange | positioned at each cell in the battle field BF is displayed upright on the cell, and it is comprised so that a user may recognize the character of each card | curd easily.

As shown on the web page P8, during the battle, from the attacking card to the attack target card so that the executing user can recognize that the attack by the executing user and the enemy user's card is being performed. For example, it is preferable to display an attack mode such as irradiation of a beam or release of flying objects. If the HP of an attacked card becomes zero during the battle, that card disappears from the battle field.
In addition, when a plurality of cards are stacked in one cell of the execution user at the start of the battle, when the plurality of cards are attacked by the enemy user's card as the battle progresses, It disappears in order from the card placed at the top. In the example of the battle progress shown on the web pages P7 to P8, the three cards stacked in the cell Ca (1,1) are reduced to two cards and stacked in the cell Ca (1,6). Two cards have been reduced to one card.

The web page P9 shows a state in which more time has passed than when the web page P8 is displayed, and the number of cards on the battle field is smaller than that of the web page P8.
As shown in the web page P10, for example, the battle ends when all the cards of either the executing user or the enemy user disappear. In the example of the web page P10, since the two cards of the execution user remain and all the cards of the enemy user have disappeared, the execution user wins. In addition, it is not necessarily limited to the case where winning or losing is determined when all the cards of one user have disappeared, and may be the victory of a user who has a large number of cards remaining in the battle field after a predetermined battle time.

(5-3) Card Movement Method During Battle As described above, each card moves in the battle field during the battle. This card movement is performed based on a movement method according to a predetermined rule. In the following, a case where all the cards arranged in each cell on the battle field are one will be described, but the card moving method is the same even when a plurality of cards are stacked.
Hereinafter, the card moving method will be described with reference to FIG. 11 and FIG. FIG. 11 is a diagram for explaining the forward movement of the card in the battle. FIG. 12 is a diagram for explaining the lateral movement of the card in the battle. FIG. 11 and FIG. 12 are diagrams each showing a card arrangement on each cell of the battle field when the game space is viewed in plan view in order to explain the movement mode of the cards in the battle.
As for the movement of the card during the battle, the forward movement is performed with priority over the lateral movement.

-Forward movement of card In the battle of this embodiment, since the card arranged in the first row of the user area UAa of the executing user and the user area UAb of the enemy user is closest to the opponent's card, Tends to drop faster and disappear. So, in the battle of this embodiment, when the card in the first row disappears, the rear card in the same column as that card is moved forward. Thereby, during the battle, each card sequentially moves forward to the front.
A specific example of the forward movement of the card will be described with reference to FIG. Here, the arrangement state of the card shown in step S1 is assumed. In this arrangement state, when a card on the cell Ca (1, 3) in the user area UAa of the execution user disappears due to an attack (step S2), the cell Ca (2, 3) behind the card The upper card moves forward to the first line (step S3). Although not shown, if there is a card on the cell Ca (3, 3) at the time of step S1, the card is similarly moved to the cell Ca (2, 3) ahead. Become.

-Horizontal movement of cards In the following explanation, the column on the matrix indicating the center position of the card group of the entire field is called "all card center position (CL_all)", on the matrix indicating the center position of the enemy user's card group The column is called “enemy card center position (CL_opp)”.
The center position of all cards means a column at the center position between the column of the leftmost cell where the card is arranged and the column of the rightmost cell where the card is arranged in the battle field. When the center position between the columns becomes the center between the cells, the column on the right side of the center position is set as the center position of all cards. When the center position between the columns is the center between the cells, the column on the left side of the center position may be the center position of all cards.
The enemy card center position means the column of the center position between the column of the leftmost cell in which the card is arranged and the column of the rightmost cell in which the card is arranged in the user area UAb of the enemy user. To do. When the center position between the columns becomes the center between the cells, the column on the left side of the center position is set as the enemy card center position. If the center position between the columns is the center between the cells, the column on the right side of the center position may be the enemy card center position.

[Horizontal movement step M1]
In an example of the battle of this embodiment, when a card is moved laterally, it is first performed from the card group of the enemy user. In the enemy user's card group, all the cards in the first row on the center position of all cards and the cards in the first row on the right side of the center position of all cards are moved laterally to the left cell. If there is another card in the destination cell, it will not be moved. When the card in the first row is moved laterally, other cards on the back in the same column as the card are also moved laterally in conjunction with the cards in the first row.
[Horizontal movement step M2]
Next, all the cards in the first row on the left side of the center position of all the cards of the enemy user are laterally moved to the right cell. If there is another card in the destination cell, it will not be moved. When the card in the first row is moved laterally, other cards on the back in the same column as the card are also moved laterally in conjunction with the cards in the first row.
[Horizontal movement step M3]
When the lateral movement of the enemy user's card is completed, the lateral movement of the executing user's card group is performed. In the execution user's card group, all the cards in the first row on the enemy card center position and the cards in the first row on the left side of the enemy card center position are moved horizontally to the right cell. If there is another card in the destination cell, it will not be moved. When the card in the first row is moved laterally, other cards on the back in the same column as the card are also moved laterally in conjunction with the cards in the first row.
[Horizontal movement step M4]
Next, among the executing user's cards, the first line card on the right side of the enemy card center position is moved laterally to the left cell. If there is another card in the destination cell, it will not be moved. When the card in the first row is moved laterally, other cards on the back in the same column as the card are also moved laterally in conjunction with the cards in the first row.

In the game of the present embodiment, the attack by the card group of the executing user and the attack by the card group of the enemy user are alternately performed, and each time the attack is performed, the lateral movement process of the cards in the above steps M1 to M4 is sequentially performed. Done. Since the cards are sequentially attacked and disappear during the battle, the center position of all cards and the center position of the enemy cards change each time.
As described above, when the center position between the leftmost cell column in which the card is arranged and the rightmost cell column in which the card is arranged is the center between the cells, By reversing the method for determining the center position of all cards and the center position of enemy cards relative to the center position (that is, one column on the left side and the other on the right column across the center position) The enemy user's card on the center position of all cards and the executing user's card on the enemy user center position move so as to cross in opposite directions. Therefore, it becomes easy for the execution user and the enemy user's card group to face each other during the battle in the lateral movement described above.

  Next, a specific example of the lateral movement of the card will be described with reference to FIG. Here, the arrangement state of the card shown in step S4 is assumed. In the example of the arrangement state, the center position CL_all of all cards is the fourth column. Therefore, as described in step M1 above, all the cards in the first row of the enemy user in the fourth to sixth columns are moved laterally to the left cell together with the cards behind the card (step S5). In step S5 of FIG. 12, the moving direction of the three cards is indicated by arrows. Since the card on the cell Cb (1, 3) on the left side of the center position CL_all of all cards cannot be moved to the right side, the above step M2 is not substantially performed in this example. In the arrangement state of step S5 (the state after the movement of three cards), the enemy card center position CL_opp is in the fourth row. Then, as described in step M3 above, all the cards in the first row of the execution user in the first to fourth columns are moved laterally to the right cell together with the cards behind the card (step S6). ). In step S5 of FIG. 12, the moving direction of the three cards is indicated by arrows. Since there is no executing user's card on the right side of the enemy card center position CL_opp, the above step M4 is not substantially performed in this example.

  As described above, in each card group of the executing user and the enemy user, each time the first row card disappears, the backward card sequentially moves forward so that the cards in the same row move forward without leaving a gap. Shift. In addition, in each card group of the executing user and the enemy user, when all the cards in any row disappear, the cards arranged in the row adjacent to the row so as to fill the gap in the row are in the horizontal direction. Moving. By such forward movement and lateral movement, the card groups of the executing user and the enemy user move in the battle field so that the cards are adjacent to each other during the battle. That is, since each user's card group performs an integral movement operation during the battle, the executing user can feel the presence of the battle.

(5-4) Example of Battle Card Movement Next, in the game of the present embodiment, specific examples of the movement mode of each card of the executing user and the enemy user from the start of the battle to the end of the battle will be described with reference to FIGS. Will be described with reference to FIG. FIGS. 13A to 13C are diagrams illustrating a card arrangement on each cell in the battle field when the game space is viewed in a plan view in order to explain how the cards move from the start to the end of the battle. In each figure, the movement of the card is indicated by an arrow.
In the battle of this embodiment, for example, as described above, the attack of the card group of the executing user and the enemy user is performed in order. After each user's attack is performed, the card is moved forward and the card is moved in order.

In the battle shown in FIGS. 13A to 13C, as shown in step S10 of FIG. 13A, the user area UAa of the executing user and the user area UAb of the enemy user are each configured by 2 × 6 cells, and the size of each card is all An example of 1 × 1 (that is, an example in which each user has 12 battle use cards) is shown.
In the battle of this embodiment, each user's attack is performed alternately, and each process of a forward movement and a lateral movement is performed after each attack. At the beginning of the battle, each user's card placed in the first line at the start of the battle is lost due to the attack. For example, as shown in step S11, the card moves forward. Is called. Step S11 shows a case where five cards have moved from the second row to the first row of cells.

When the battle progresses and there is a case where no card exists in any column of each user's area as shown in step S12, lateral movement is performed. In step S12, no card exists in the fifth column of the user area UAa of the execution user and the second column of the user area UAb of the enemy user. In the example of step S12, since the center position CL_all of all cards is in the fourth column, the enemy user's two cards (cells Cb (1,1), Cb (1,2) in the first to third columns are on the line. Card) to the right cell. In step S12, the enemy user's cards in the fourth to sixth columns cannot be moved to the left.
The enemy card center position CL_opp after the two cards of the enemy user have moved to the right cell is the fourth column as shown in step S13. Therefore, in step S13, the two cards (cards on the cells Ca (1, 6) and Ca (2, 6)) of the execution user in the fifth to sixth columns are moved to the left cell. In step S13, the execution user's card in the first to fourth columns cannot be moved to the right.

As a result of the progress of the battle from step S13, it is assumed that the card in the first row disappears and the card is moved forward, and the card is placed in step S14. In the example of step S14, the center position CL_all of all cards is the fourth column. Therefore, in step S15, one card (card on the cell Cb (1, 6)) of the enemy user in the fourth to sixth columns is moved to the left cell. In step S15, the enemy user's cards in the second and third columns cannot be moved to the right.
The enemy card center position CL_opp after one card of the enemy user moves to the left cell is the third column as shown in step S15. Therefore, in step S15, the three cards (cards on the cells Ca (1,1), Ca (1,2), Ca (2,2)) of the executing user who were in the first to third rows in step S14 are obtained. Move to the right cell. Thereafter, the execution user's card in the fourth to fifth columns cannot be moved to the left side.

As a result of the progress of the battle from step S15, it is assumed that the card in the first row disappears and the card is moved forward, and the card is placed in step S16. In the example of step S16, the center position CL_all of all cards is the fourth column. Therefore, in step S17, one card (card on the cell Cb (1, 5)) of the enemy user in the fourth to sixth rows in step S16 is moved to the left cell. After that, the enemy user's card in the second to third columns cannot be moved to the right side.
The enemy card center position CL_opp after one card of the enemy user moves to the left cell is the third column as shown in step S17. In this case, none of the executing user's cards can be moved.

As a result of the battle proceeding from step S17, the card on the execution user's cell Ca (1,4) and the card on the enemy user's cell Cb (1,3) disappear, and the card is placed in step S18. Assuming that In the example of step S18, the center position CL_all of all cards is the fourth column. Therefore, in step S19, one card (card on the cell Cb (1, 4)) of the enemy user in the fourth row in step S18 is moved to the left cell. In step S19, the enemy user's card in the second row cannot be moved to the right after that.
The enemy card center position CL_opp after one card of the enemy user moves to the left cell is in the second column as shown in step S19. In this case, in step S19, the two cards (cards on the cells Ca (1,3) and Ca (1,5)) of the executing user that were in the second to sixth columns in step S18 are moved to the left cell. Let

Assume that none of the cards are lost in the attack after the movement of the three cards in step S19. In that case, the center position CL_all of all cards is the third column. At this time, as shown in step S20, the enemy user's card in the third row cannot be moved to the left, and the enemy user's card in the second row cannot be moved to the right. On the other hand, since the enemy card center position CL_opp is in the second column, as shown in step S20, one card of the executing user that was in the fourth column in step S19 (card on cell Ca (1, 4)) To the left cell.
In step S21, it is assumed that the two cards in the first row of the enemy user's area in step S20 have disappeared. In this case, since the enemy user's cards have all disappeared, the execution user wins.

  As shown in the example of the battles in FIGS. 13A to 13C, in the battle according to the present embodiment, the card groups of the executing user and the enemy user in the battle are moved in the battle field so that the cards are adjacent to each other. Also, in the lateral movement of each card group of the executing user and the enemy user, the enemy user's card group is first laterally moved toward the center position of all cards, and then the executing user's card group is laterally moved toward the enemy card center position. Move. Therefore, for each attack turn of each user, the card position is adjusted so that the card group of the executing user and the enemy user face each other. Therefore, each user's card group always faces each other from the start of the battle to the end of the battle, and the realism of the battle is more felt from the executing user, and the direction of attack by each card is mainly set in front of the card. If this is the case, an attack can be effectively applied to the opponent's card placed opposite to the card, so there is also an advantage that the battle wins or loses can be determined quickly.

(6) Overview of Functions Provided by Game Control Device Next, functions provided by the game control device in order to realize the above-described game of the present embodiment will be described.
In the present embodiment, the game server 20 and the database server 30 constitute a game control device. Below, the function implement | achieved with the game control apparatus of this embodiment is demonstrated with reference to FIG. 14 for the case where the game of embodiment mentioned above is applied as an example. FIG. 14 is a functional block diagram for explaining functions that play a main role in the game control apparatus of the present embodiment. In the functional block diagram shown in FIG. 14, the moving means 57 is not an essential component, but a more preferable battle game is realized by providing the moving means 57.

The association unit 51 has a function of associating a card as an object with a user. In the present embodiment, as shown in the card database in FIG. 7, the size (that is, information related to the size of the cell occupied by the card) and the HP in the battle are associated with each card. The size of the card is an example of “information relating to the area occupied in the game space” of the present invention. HP is an example of the first parameter of the present invention.
In the present embodiment, a method for acquiring a user's card is not described in detail, but various methods can be adopted. For example, a card may be provided to the user in exchange for a predetermined amount of points or virtual currency on the game held by the user. Alternatively, a card may be given to the user with a predetermined or random probability when the user executes a game element other than the battle, such as a quest. When a card granting opportunity occurs, the CPU 21 of the game server 20 determines a card to be given to the user by lottery from the cards recorded in the card database, and uses the determined card as the user's possessed card, for example, the user Record it in the data.

  The arrangement means 52 has a function of arranging a battle use card (card used for the battle) among the cards (user possession cards) associated with the user in the user area (predetermined field) of the battle field in the game space. Prepare.

The function of the arrangement means 52 can be realized as follows, for example, with reference to FIG. FIG. 15 is a diagram illustrating an example of a data configuration of battle use card data. The battle use card data includes each data of the initial position on the battle field, the current position in the battle, and the remaining HP (indicating “the remaining amount of HP”) in association with each battle use card. It is created each time the current position of the battle use card changes or any battle use card disappears. In addition, when displaying remaining HP of each card | curd during a battle, you may produce battle use card data, whenever remaining HP changes.
Even when a plurality of battle use cards are stacked at the same position, data is described for each card. For example, the battle use card data shown in FIG. 15 shows a case where three cards (cards C002, C120, C135) are stacked in the cell Ca (1, 1) at the start of the battle. Moreover, the case where two cards (cards C006 and C046) are stacked on the cell Ca (1,2) at the time of starting the battle is shown.

The initial position data of each card in the battle use card data is not changed during the battle once it is determined. A series of battle use cards created for a specific battle is basic data for creating a playback file from the start to the end of the battle. The created battle use card data is stored in the RAM 23 of the game server 20.
When the CPU 21 of the game server 20 obtains an HTTP request including the operation input of the execution user via the communication interface unit 25, the CPU 21 performs processing according to the operation input, generates HTML data including the processing result, and performs user communication. Transmit to the terminal 10. Thereby, the web page is displayed on the user's communication terminal 10 or the web page displayed on the communication terminal 10 is updated.

(I-1) New Arrangement of Card When the execution user input information is information on the new arrangement of the card, the CPU 21 writes data in the initial arrangement column in the battle use card data based on the input information. This input information includes a card to be newly used as a battle use card among the possession cards of the executing user and a selection result of a cell in which the card is placed. CPU21 will determine whether the card | curd selected by the execution user can be arrange | positioned to the selected cell with reference to battle use card | curd data, if input information is acquired. If the card can be placed in the selected cell, the CPU 21 writes data in the card ID and initial position fields of the card.
The execution user's input regarding the new placement of the card corresponds to, for example, an operation input to the menu m3 (“place yourself”) of the web page P1 or an operation input to the menu m4 (“place more”) of the web page P4. To do.

(I-2) Change of Card Arrangement When the input information of the execution user is information about the change of the card arrangement, the CPU 21 updates the battle use card data based on the input information. This input information includes a selection result of a battle use card arranged by the execution user and a new possessed card replacing the card. When acquiring the input information, the CPU 21 refers to the battle use card data and determines whether or not the card newly selected by the execution user can be placed instead of the placed battle use card. When the placement is possible, the CPU 21 writes the card ID of the newly selected execution user's possessed card instead of the card ID of the already placed card.
The execution user input regarding the change of the card arrangement is, for example, an operation input to the menu m5 (“change the arranged card”) in a state where any card arranged in the matrix 201 is selected on the web page P4. Equivalent to.

(I-3) Canceling Card Arrangement When the execution user input information is information about card arrangement cancellation, the CPU 21 updates the battle use card data based on the input information. This input information includes information on the execution user's battle use card that is to be canceled. CPU21 will erase the battle use card from battle use card data, if the execution user's battle use card used as the candidate for arrangement cancellation is acquired.
The execution user's input relating to card arrangement cancellation corresponds to, for example, a selection input for any card already arranged in the matrix 201 on the web page P4 and an operation input for the menu m6 (“cancel arranged card”).

(I-4) Automatic Card Placement When the CPU 21 obtains an operation input for the menu m2 (“place automatically”) of the web page P1, the battle use card is selected from the execution user's possessed cards and used for battle. Write to card data. For example, the following methods can be adopted as a method for selecting a battle use card and an arrangement method for a battle use card. The CPU 21 refers to the card database so as to sequentially arrange the cards in the order in which the sum of the attack power and the defense power is large, and in a predetermined arrangement order of the cells in the matrix, from among the cards owned by the executing user. (That is, write data in the card ID and initial position fields of the battle card data). Alternatively, the CPU 21 refers to the card database and arranges the cards in the first row of the matrix in the descending order of the sum of the attack power and the defense power among the 1 × 1 small size cards, and relatively large size (for example, 2 × 2). Etc.) may be arranged in the second and subsequent cells in descending order of the sum of the attack power and the defense power.

The superimposing means 53 is associated with the user and is not arranged in the battle field on any card (first object) among the cards arranged in the user area of the battle field based on the user input information. A function of arranging (ie, stacking) other cards (second objects) in an overlapping manner is provided.
In the present embodiment, the cards can be stacked when there is no card that can be placed in the user area by the placement means 52 among the cards associated with the user. In the present embodiment, a case will be described in which cards of the same monster character (that is, cards associated with information on the same attribute) can be stacked.

  The function of the superimposing means 53 can be realized in the same manner as the arranging means 52. That is, when the execution user's input information is information about a new card arrangement, the CPU 21 of the game server 20 writes it in the initial arrangement column in the battle use card data based on the input information. The execution user's input related to the new placement of the card corresponds to, for example, an operation input to the menu m4 (“place more”) of the web page P4. This input information includes a card to be newly used as a battle use card among the possession cards of the executing user and a selection result of a cell in which the card is placed.

  When the CPU 21 acquires the input information, the CPU 21 refers to the battle use card data and determines whether or not the card selected by the execution user can be placed on top of other cards in the selected cell (that is, whether or not stacking is possible). )to decide. In the present embodiment, the cards can be stacked when there is no card that can be placed in the user area. Therefore, it is determined whether there is a card that can be placed in the user area, and whether the card already placed in the selected cell and the selected card are of the same monster character. The The “card that can be arranged in the user area” means a card having a size that can be arranged in an area occupied by one or a plurality of cells in which no card is arranged on the user area of the battle field.

If the card can be placed on the selected cell, the CPU 21 writes data in the card ID and initial position fields of the card. In the battle use card data shown in FIG. 15, the card C002 is placed on the battle field in the cell Ca (1,1), and the two cards C120 and C135 are stacked in this order on the card. An example is shown.
Processing of the CPU 21 in this stack example will be described below. The CPU 21 includes, in the input information acquired from the user communication terminal 10, the selection result of the card C120 as a card to be newly placed and the selection result of the cell Ca (1, 1) as a cell to be placed on the card. If it is, it is determined whether or not the selected card can be placed in the cell Ca (1, 1). Here, the CPU 21 first refers to the battle use card data, and (i) one or a plurality of cells in which the card data is written in all the cells in the initial arrangement item or the card data is not written. It is determined whether or not there is a possessed card that can be placed on the card. Next, the CPU 21 refers to the card database and (ii) determines whether or not the selected card C120 is a card of the same monster character as the card C002 already arranged. When both the conditions (i) and (ii) are satisfied, the CPU 21 determines that the selected card C120 can be placed in the cell Ca (1, 1) (that is, can be stacked).
If it is determined that the stacking is possible, the CPU 21 provides a new card ID: C120 row under the card ID: C002 row in the battle use card data. The CPU 21 writes (1, 1) as the initial position and current position of the line with the card ID: C120, and writes the HP of the card C120 as the remaining HP.
Similarly, in the case of stacking the card C135 on the card 120, a new card ID: C135 line is provided under the card ID: C120 line in the battle use card data.

The battle advancing means 54 has a function of advancing a battle between the executing user and the enemy user.
In the example of the battle progress method of this embodiment, an attack is alternately performed between an execution user and an enemy user. In the attack turn of each user, each battle use card attacks the opponent user's card at a timing based on the value of the attack frequency in the card database (FIG. 7). Therefore, in one attack turn, there are cards that perform an attack and cards that do not perform an attack in each user's card group. When a card performs an attack, the opponent's card to be attacked is determined based on the range value of the card database. Although the attack direction of a card can be set arbitrarily, it is preferably set to the front or near the front with respect to the cell in which the card is placed at the time of attack. For example, a card attack is performed on a battle opponent's card in the same column as the cell in which the card is placed, or a battle opponent's card in a row adjacent to the row.
Although FIG. 7 shows an example in which the attack frequency is set for each card, the attack frequency may be the same value for all cards. For example, you may set so that all the cards may attack at the attack turn of each user.
Although the card attack direction has been described above, the distance from the attacking card to the attack target card may be set from the following viewpoint. That is, when one of the user's cards attacks, a card that is within the range of the card database and is in front of the opponent's card (for example, a card that attacks, such as a card in the first row) Cards closer to each other may be preferentially attacked. In this case, when the attack target card disappears, the card behind the card is urged to move forward, so that the movement of moving the entire card forward is promoted, and the battle becomes more dynamic.
Further, the execution user may be able to specify the attack direction of the card and the priority of the row of the attack target card.

In the implementation example of the function of the battle advancing means 54 of the present embodiment, after the execution user and the enemy user are instructed to start the battle, the execution user does not need to perform any operation and is created by the CPU 21 of the game server 20. The reproduced file is reproduced on the communication terminal 10 of the executing user. The file format of the playback file is not limited, but is, for example, the SWF format.
When the CPU 21 receives an instruction to start a battle by the executing user (for example, when an HTTP request including the selection result of the menu m10 in FIG. 10D is acquired), the attack processing and HP update processing of the battle use cards of the executing user and the enemy user are performed. By executing the movement process and the like, as described above, a series of battle use card data that forms the basis of the reproduction file from the start to the end of the battle is created. CPU21 will produce | generate the HTML data containing the reproduction | regeneration file and will transmit to the execution user's communication terminal 10, if a reproduction | regeneration file is produced based on the produced series of battle use card | curd data.
When the CPU 11 of the communication terminal 10 acquires the HTML data from the game server 20, the CPU 11 executes the reproduction file by the web browser and displays the battle on the display unit 16.

When the execution user's card arrangement is completed, the CPU 21 of the game server 20 loads the data on the card database of each battle use card of the execution user and the enemy user into the RAM 23, and then executes the attack turn of the execution user and the attack of the enemy user. The attack process on the turn is performed as follows.
The CPU 21 executes the execution process of the execution user in the execution turn of the execution user. In the execution process of the execution user, it is determined whether or not the attack timing has been reached for each card of the execution user. If it is determined that the attack timing of the card has not been reached, the CPU 21 does not perform the attack processing with the card. When it is determined that the attack timing of the card has been reached, the CPU 21 performs an attack process using the card.
In the attack process using a card, the CPU 21 determines an enemy user's card to be attacked by that card. The card of the enemy user to be attacked may be all the cards within the range of the range of the card with reference to the cell in which the attacking card is arranged. In that case, the CPU 21 refers to the enemy user's battle use card data, and identifies the enemy user's card at the current position within the range of the range as viewed from the reference cell. The CPU 21 may target all the specified enemy user's cards, or select and select a part of the specified enemy user's cards according to a predetermined condition or randomly. The card may be determined as an attack target. Preferably, the CPU 21 has a range within the range of the distance from the reference cell, out of the enemy user's cards arranged in the row of cells where the attacking card is arranged and the row adjacent to the row. Identify the enemy user's card at the current location.

  In the present embodiment, when a plurality of stacked cards exist within the range of the range, they are set as attack targets in order from the card arranged at the top of the plurality of cards. For example, when the cards C001, C002, and C003 are stacked in this order at the start of the battle, the card C003 arranged at the top becomes the attack target card first, and when the card C003 disappears, the card C002 is It becomes the next attack target card.

  Since the enemy user's attack process in the enemy user's attack turn is the same as the execution process of the executing user described above, a duplicate description is omitted.

In the battle between the executing user (first user) and the enemy user (second user), the changing means 55 is based on the battle use card (object) of any user and is at least one of the card groups of the enemy user. The function of changing the HP of the card is provided. In the present embodiment, the HP of the card is an example of a parameter associated with the object.
The function of the change means 55 is realizable as follows. CPU21 of the game server 20 will perform the process which reduces HP of the specified card | curd, if the card of the enemy user used as the attack object of each card | curd of an execution user is identified in an execution user's attack turn. The HP reduction amount ΔHP of the enemy user's card that has been attacked is determined, for example, as follows based on the defense power of the card and the attack power of the card that made the attack.
ΔHP = Pa × k
Pa: Attack power of the attacked card k: Coefficient determined according to the defense power of the enemy user's card under attack The value of the coefficient k decreases as the defense power of the enemy user's card increases. Set to The coefficient k is, for example, a value in the range of 0.6 to 1.0.
CPU21 calculates remaining HP of each card | curd at the time of producing battle use card | curd data.

Note that the above-described method for calculating the amount of decrease in HP is merely an example, and any method may be used based on the attack power of the card that made the attack and the defense power of the card that received the attack. For example, the ΔHP may be the sum of the attack power and the defense power of the attacked card.
Although the case of the execution user's attack turn has been described, the attack process can be executed in the same manner also in the case of the enemy user's attack turn.

  In the attack processing of the present embodiment, when a plurality of stacked cards are within the range of the range, the CPU 21 refers to the battle use card data and is arranged at the top of the plurality of cards. Although the case where the attack target card is specified in order from the card has been described, when the HP decrease amount ΔHP based on the attack power of the card that has attacked is equal to or greater than the remaining HP of the card arranged at the top Any of the following treatments (i) to (iii) can be performed. By adopting either process, the progress of the battle game or the battle time can be adjusted, and the degree of freedom of game setting increases.

(i) Processing to affect a plurality of stacked cards according to one attack power If the attack power of the attacked card is large, the value of ΔHP calculated by the attack power Accordingly, the processing may be performed so that the plurality of stacked cards have a remaining HP of zero in order from the top. For example, if ΔHP is 7000 and the stacked cards have a remaining HP of 4000, 2000, 2000 in order from the top, the CPU 21 sets the remaining HPs of the top two cards to zero and starts from the top. A process of setting the remaining HP of the third card to 1000 is performed. In this process, since a plurality of cards are affected by one attack, the time from the start to the end of the battle can be shortened.
(ii) Processing to affect only one card with one attack power If the attack power of the card that attacked is large, the card affected by the attack power is placed at the top, for example You may limit to the card which is done. For example, when ΔHP is 7000 and the plurality of stacked cards have a remaining HP of 4000, 2000, 2000 in order from the top, the CPU 21 performs a process of setting the remaining HP of the top card to zero, The remaining HP of the second and third cards from the top is not changed. In this process, only one card is affected by one attack, so the time from the start to the end of the battle becomes longer, but the characters of each of the stacked cards disappear while being displayed. Therefore, there is an advantage that the target being attacked is easily recognized by the user.
(iii) Processing to limit the number of cards that are affected among a plurality of cards stacked according to one attack power For example, when the upper limit of the number of cards affected by an attack is limited to two, ΔHP is When the remaining HP of the stacked cards is 4000, 2000, 2000 in order from the upper card, the CPU 21 sets the remaining HP of the upper two cards to zero, and the upper three cards The remaining HP of the eye card may not be changed.

  The attack power and defense power during the battle when a plurality of cards are stacked may be the sum of the attack power and defense power of each card. In this case, during the battle, each time the number of stacked cards decreases due to the disappearance of the cards, the attack power and defense power of the stacked cards fluctuate (decrease). On the other hand, a single card with attack power and defense strength equivalent to the sum of attack power and defense power at the beginning of the battle of multiple stacked cards attacks from the start of the battle to the end of the battle. Since the power and defense power do not fluctuate, it is advantageous in battle over a plurality of stacked cards.

The erasure means 56 has a function of erasing the card from the battle field when the HP of the card satisfies a predetermined erasure condition.
The function of the erasure | elimination means 56 is realizable as follows. When the CPU 21 of the game server 20 creates a series of battle use card data from the start to the end of the battle based on the HTTP request acquired from the communication terminal 10 of the executing user, the CPU 21 of the game server 20 is based on the created series of battle use card data. To create a playback file. At this time, when the remaining HP of the card becomes zero (that is, when the disappearance condition is satisfied), the CPU 21 creates the battle use card data so that the data at the current position of the card is invalidated. As a result, the card disappears when it is played back as a playback file from when the remaining HP of the card becomes zero. The CPU 21 transmits HTML data including the created reproduction file to the communication terminal 10 of the executing user.

The moving means 57 has a function of moving each user's card group within the battle field so that the cards included in each user are adjacent to each other in the battle between the executing user and the enemy user.
In the present embodiment, when the cards are moved by the moving means 57, when the cards are lost during the battle by the erasing means 56, the card groups of the executing user and the enemy user that are not lost are adjacent to each other. To move in the battle field. Although the movement mode is not limited, in this embodiment, as an example, the card group moves so that the cards are adjacent to each other, and the forward movement and the lateral movement are performed. At this time, the forward movement is preferably performed with priority over the lateral movement.
In the following, (II-1) forward movement processing and (II-2) lateral movement processing when one card is placed in each cell will be described in order. Is the same as the case of one card.

(II-1) Forward movement process When the CPU 21 determines that the card in the first row in the card group of the executing user and the enemy user has disappeared, the CPU 21 selects the rear card in the same column as that card. Create battle card data to move forward. That is, the CPU 21 creates the battle use card data so that the data on the current position of the card to be moved forward is updated.

(II-2) Horizontal movement processing [Enemy user's card horizontal movement processing]
The CPU 21 determines the center position (CL_all) of all cards, which is a column on the matrix indicating the center position of the card group in the entire field. Here, the center position of all cards is a column at the center position between the column of the leftmost cell where the card is arranged and the column of the rightmost cell where the card is arranged in the battle field. When the center position between the columns is the center between the cells, the column on the right side of the center position is the center position of all cards.
When the CPU 21 determines the center position of all cards, the CPU 21 determines the processing order of each card in the enemy user's card group. This processing order is the following priority order (a-1) to (a-4).

(a-1) In the first row, the order of cards arranged from left to right with respect to the center position of all cards
(a-2) In each line other than the first line, the order of cards arranged from left to right with respect to the center position of all cards
(a-3) In the first row, for the cards on the left side of the center position of all cards, the order of the cards arranged from right to left
(a-4) In each line other than the first line, for the cards on the left side of the center position of all cards, the order of the cards arranged from right to left

The CPU 21 creates battle use card data by horizontally moving to the left cell in the order of the cards shown in (a-1). That is, the CPU 21 creates battle use card data so that the current position data of the card to be moved laterally is updated. At this time, if there is another card in the destination cell, it is not moved.
When the CPU 21 executes the horizontal movement process of each card in the order of the cards shown in (a-2), the movement result of each card in the order of the cards shown in (a-1) in the same column. Create battle use card data by moving it in conjunction with. That is, the CPU 21 creates battle use card data so that the current position data of the card to be moved is updated.
The CPU 21 creates battle use card data by horizontally moving to the right cell in the order of the cards shown in (a-3). That is, the CPU 21 creates battle use card data so that the current position data of the card to be moved laterally is updated. At this time, if there is another card in the destination cell, it is not moved.
When the CPU 21 executes the horizontal movement process of each card in the order of the cards shown in (a-4), the movement result of each card in the order of the cards shown in (a-3) in the same column. Create battle use card data by moving it in conjunction with. That is, the CPU 21 creates battle use card data so that the current position data of the card to be moved is updated.

[Transfer processing of executing user's card]
When the lateral movement process of the enemy user's card is completed, the CPU 21 next executes the lateral movement process of the executing user's card group.
The CPU 21 determines an enemy card center position (CL_opp) which is a column on the matrix indicating the center position of the enemy user's card group. Here, the enemy card center position is the column of the center position between the column of the leftmost cell where the card is arranged and the column of the rightmost cell where the card is arranged in the user area of the enemy user. It is. When the center position between the columns is the center between the cells, the column on the left side of the center position is the enemy card center position.
When the CPU 21 determines the center position of the enemy card, the CPU 21 determines the processing order of each card in the executing user's card group. This processing order is the following priority order (b-1) to (b-4).

(b-1) In the first row, the order of cards arranged from right to left with reference to the enemy card center position
(b-2) In each line except the first line, the order of the cards arranged from right to left based on the enemy card center position
(b-3) In the first line, for the cards on the right side of the enemy card center position, the order of the cards arranged from left to right
(b-4) In each line other than the first line, for the cards on the right side of the enemy card center position, the order of the cards arranged from left to right

The CPU 21 creates battle use card data by horizontally moving to the right cell in the order of the cards shown in (b-1). That is, the CPU 21 creates battle use card data so that the current position data of the card to be moved laterally is updated. At this time, if there is another card in the destination cell, it is not moved.
When the CPU 21 executes the horizontal movement process of each card in the order of the cards shown in (b-2), the movement result of each card in the order of the cards shown in (b-1) in the same column. Create battle use card data by moving it in conjunction with. That is, the CPU 21 creates battle use card data so that the current position data of the card to be moved is updated.
The CPU 21 creates battle use card data by horizontally moving to the left cell in the order of the cards shown in (b-3). That is, the CPU 21 creates battle use card data so that the current position data of the card to be moved laterally is updated. At this time, if there is another card in the destination cell, it is not moved.
When the CPU 21 executes the horizontal movement process of each card in the order of the cards shown in (b-4), the movement result of each card in the order of the cards shown in (b-3) in the same column. Create battle use card data by moving it in conjunction with. That is, the CPU 21 creates battle use card data so that the current position data of the card to be moved is updated.

(7) Flow of Battle Process of this Embodiment Next, an example of the flow of the battle process of this embodiment will be described with reference to the flowcharts of FIGS. FIG. 16 is a flowchart showing an example of the entire process of the battle game of the present embodiment. FIG. 17 is a flowchart illustrating an example of the card placement process. FIG. 18 is a flowchart illustrating an example of attack processing. FIG. 19 is a flowchart illustrating an example of a card forward movement process. FIG. 20 is a flowchart illustrating an example of a lateral movement process of an enemy user's card. FIG. 21 is a flowchart illustrating an example of the lateral movement process of the executing user's card.

(7-1) Overall process of battle game (FIG. 16)
In FIG. 16, when the CPU 21 of the game server 20 receives an instruction to start a battle by the executing user (step S30: YES), the CPU 21 performs the processing after step S32, and when the instruction to start the battle is not received (step S30). S32: NO), the process ends. In addition, CPU21 recognizes the instruction | indication of a battle start, for example by acquiring the HTTP request containing the selection result of menu m10 of FIG. 10D.

After executing the card placement process (step S32; FIG. 17) of the executing user and the enemy user, the CPU 21 proceeds to step S34. In the battle game of the present embodiment, attack processing is performed by alternately performing attacks by the executing user and the enemy user's card. Therefore, if the CPU 21 determines that it is an execution user's attack turn (step S34: YES), it executes an execution user's attack process (step S36; FIG. 18). When the CPU 21 determines that it is an attack turn of the enemy user (step S34: NO), the CPU 21 performs an attack process of the enemy user (step S38; FIG. 18).
After performing the attack process of either the execution user or the enemy user, the CPU 21 performs a card movement process between the enemy user and the execution user. That is, the CPU 21 moves the enemy user's card forward (Step S40; FIG. 19), executes the user's card forward (Step S42; FIG. 19), and moves the enemy user's card laterally (Step S44; FIG. 20). ), The execution user's card horizontal movement process (step S46; FIG. 21) is sequentially executed. These processes will be described later with reference to FIGS.

When the CPU 21 determines that all the cards of the executing user or the enemy user have disappeared (that is, the remaining HP values of all the cards have become zero) after the processing of steps S40 to S46 (step S48: YES). After the battle end process (step S50), the process ends. The battle end processing includes creation of a reproduction file based on a series of battle use card data created by the CPU 21, creation of HTML data including the reproduction file, transmission of HTML data to the communication terminal 10 of the executing user, and the like. .
CPU21 returns to step S34 and continues a battle process, when it is judged after the process of step S40-S46 that all the cards of an execution user or an enemy user are not lose | disappeared (step S48: NO).

In the flowchart of FIG. 16, the execution process of the executing user (step S36) and the attacking process of the enemy user (step S38) are alternately performed, and the case where the card movement process is performed after each attack process is illustrated. However, this is not the case. Step S36 and step S38 may be executed in succession, and thereafter the card movement process may be executed.
Moreover, although the case where a card arrangement | positioning process is performed after receiving the instruction | indication of the battle start by an execution user (step S30: YES) is illustrated in the flowchart of FIG. 16, it is not restricted to this case. The card placement process may be executed independently of the battle process. For example, when a user provides a menu for editing and registering a battle use card in the menu display area 103 of the web page P0 in FIG. 10A and the battle start card data is registered when the instruction to start the battle is recognized. You may make it perform a battle by reading.

(7-2) Card placement processing (FIG. 17)
In the card placement process, first, the menu selected by the executing user is determined (step S100). For example, when the CPU 21 of the game server 20 obtains an HTTP request including the selection result of the menu of the web page P4 in FIG. 10A, the CPU 21 executes processing based on the selection result.
When the CPU 21 obtains an HTTP request including the selection result of the menu m3 (“place yourself”) of the web page P1 (see FIG. 10) or the selection result of the menu m4 (“place more”) of the web page P4. (Step S100: m3, m4), HTML data for the web page P2 is transmitted to the user's communication terminal 10. When an HTTP request including the selection result of any unplaced cell is acquired on the matrix 201 of the web page P2 (step S102: YES), the CPU 21 presents the user's list of possessed cards to the user (step S104). That is, the CPU 21 transmits HTML data including a list of possessed cards to the user communication terminal 10. Thereby, for example, the web page P3 is displayed on the user's communication terminal 10.

  Note that, in step S100 of FIG. 17, the menu m2 (“place automatically”) option is not illustrated, but when the menu m2 is selected, the CPU 21 determines the user's basis based on a predetermined criterion. The cards used are arranged from the possessed card to the matrix 201, and the card used for the card and the initial position are written to update the battle use card data (step S112).

  When the HTTP request including the selection result of any possessed card is acquired on the web page P3 (step S106: YES), the CPU 21 determines whether or not the selected card can be arranged in the matrix 201 (step S108). ).

The determination in step S108 may be made from various viewpoints as described below.
In step S108, if no card is placed in the selected cell and there is no area where the card selected in step S106 can be placed on the matrix 201 (that is, there is not enough free space), The CPU 21 determines that the card cannot be placed. For example, if there is only a 1 × 2 area as a free area on the matrix with the selected cell as a reference, the size of the selected card requires an area larger than the free area. If it is 2, it is determined that the card cannot be placed.
In step S108, if a card is already placed in the selected cell, it is determined whether or not the card selected in step S106 can be stacked on the card already placed. In this embodiment, (i) a condition that there is no card that can be placed in an area where no card is placed on the matrix 201, and (ii) a card that is already placed in the selected cell is selected. If the card satisfies the condition that it is the same monster character card, it is determined that the selected card can be placed, and if either of the conditions (i) or (ii) is not met It is determined that the selected card cannot be placed.

  If it is determined that the selected card cannot be placed (step S108: NO), the CPU 21 does not permit the placement of the card selected in step S106 and includes text indicating that the selected card cannot be placed. The HTML data is transmitted to the user communication terminal 10. That is, it is notified that the selected card cannot be placed (step S110), and the process returns to the card selection process again (that is, step S106). On the other hand, if it is determined that the selected card can be placed (step S108: YES), the CPU 21 writes data in the card ID and initial position fields of the card selected in step S106, thereby using the battle use card. Data is updated (step S112).

Next, the CPU 21 determines whether or not a card placement end instruction has been issued, that is, whether or not an HTTP request including the selection result of the menu m7 (“Battle with current placement”) has been acquired (step S114). If the card placement end instruction is given (step S114: YES), the flow returns to the flow of FIG. When the card placement end instruction is not issued (step S114: NO), that is, when an HTTP request including the selection result of any of the menus m4 to m6 is acquired on the web page P4 (FIG. 10A), for example. The CPU 21 returns to step S100 to execute the processing of the selected menu.
Note that the process of step S108 for limiting the total cost of the user's card is not essential. That is, when a card is selected in step S106, the battle use card data update process in step S112 may be executed based on the selected card.

  When the CPU 21 obtains an HTTP request including the selection result of the menu m5 (“change the arranged card”; see FIG. 10A) on the web page P4 (step S100: m5), any of the cards already arranged on the matrix 201 is displayed. If any cell is selected (step S116: YES), the process proceeds to step S104. The processing after step S104 is as already described. When a cell in which a plurality of cards are stacked is selected, all of the plurality of cards may be changed, or a card to be changed is selected from a plurality of stacked cards by the user. May be selected.

  When the CPU 21 obtains an HTTP request including the selection result of the menu m6 (“cancel placed card”) on the web page P4 (step S100: m6), any cell to which the card is placed is to be canceled. If it is selected (step S118: YES), the card used in the selected cell is erased from the battle use card data and the battle use card data is updated (step S112). Thereafter, as already described, the determination process of step S114 is performed. In addition, when a cell in which a plurality of cards are stacked is selected, all of the plurality of cards may be cancelled, or a card to be canceled is selected from a plurality of stacked cards by the user. May be selected.

  In the flowchart of FIG. 17, whether or not a card can be placed in the selected cell is determined in step S108, but may be determined in step S104. In that case, in the card list presented to the user in step S104, whether a card that does not have sufficient free space and cannot be placed is hidden or is displayed in a manner different from the placeable card (for example, darkened). Alternatively, it may be displayed so that it cannot be selected.

(7-3) Attack processing (FIG. 18)
Hereinafter, the attack turn of the executing user (step S36 in FIG. 16) will be described, but the same applies to the attack turn of the enemy user (step S38 in FIG. 16).
In the execution turn of the execution user, the CPU 21 of the game server 20 specifies the processing target cards in order for each of the execution user's battle use cards, and executes the processes of steps S120 to S126. First, the CPU 21 determines whether or not the attack timing has been reached for the processing target card (step S120). If it is determined that the attack timing of the card has not been reached (step S120: NO), the CPU 21 proceeds to step S129 without performing the attack processing with the card. If the processing has not been completed for all the cards of the executing user (step S129: NO), the process returns to step S120 for processing of the next card.

  If it is determined that the attack timing of the card has been reached (step S120: YES), the CPU 21 performs the processing after step S122. Note that the CPU 21 refers to the attack frequency data in the card database (FIG. 7) in making the determination in step S120. It is determined that the greater the attack frequency value, the greater the frequency of attacks. For example, for a card with an attack frequency value of “2”, an attack is always executed during the attack turn of the execution user, and for a card with an attack frequency value of “1”, the execution user is For example, an attack is executed in any of the attack turns.

Next, the CPU 21 determines whether there is an enemy user's card within the range of the processing target card (step S122). That is, the CPU 21 determines whether there is an enemy user's card arranged in a cell within the range of the range of the card with reference to the cell in which the processing target card is arranged. When there is an enemy user's card within the range of the processing target card (step S120: YES), the CPU 21 determines the attack target card (step S124). If there is no enemy user's card within the range of the processing target card (step S122: NO), the process proceeds to step S129. If the processing has not been completed for all the cards of the executing user (step S129: NO), the process returns to step S120.
In step S124, the CPU 21 refers to the battle use card data when the plurality of stacked cards are within the range of the range, and the card arranged at the top of the plurality of cards. The attack target cards are identified in order.

  In step S124, all of the enemy user's cards within the range of the range of the processing target card may be determined as the attack target cards, or predetermined among the cards of the enemy user within the range of the range of the target. It is also possible to select some cards according to the above conditions or at random, and determine the selected cards as attack target cards. Preferably, the CPU 21 selects the enemy user cards arranged in the column of cells in which the cards to be processed are arranged and the column adjacent to the column from among the cards of enemy users within the range of the range. The card may be determined as the attack target card.

Next, the CPU 21 performs processing for reducing the HP of the attack target card. As described above, the CPU 21 calculates the amount of decrease in HP of the attack target card based on, for example, the attack power of the processing target card and the defense power of the attack target card. The attack power and defense power during the battle when a plurality of cards are stacked may be the sum of the attack power and defense power of each card. In other words, each time the number of stacked cards decreases due to the disappearance of the cards during the battle, the attack power and defense power of the stacked cards may decrease.
The CPU 21 updates the HP of the attack target card based on the calculated HP decrease amount (step S126). If the CPU 21 determines that the remaining HP of the attack target card has become zero (step S127: YES), it creates battle use card data so that the data at the current position of the attack target card is invalidated. (Step S128). If the CPU 21 determines that the remaining HP of the attack target card is greater than zero (step S127: NO), the CPU 21 proceeds to step S129.
When the processing is completed for all the cards of the executing user (step S129: YES), the executing user's attack turn ends.

(7-4) Card forward movement process (FIG. 19)
In the following description, the execution user card forward movement process will be described, but the same applies to the enemy user card forward movement process. Hereinafter, the forward movement process when one card is arranged in each cell will be described. However, the forward movement process when a plurality of cards are stacked on the cell is the same as the case of one card. The same. That is, when a plurality of cards are stacked in the cell, the current position data of all the plurality of cards are updated in conjunction with each other.
CPU21 of the game server 20 performs the process shown in FIG. 19 about each card | curd of an execution user. First, the CPU 21 determines whether or not the processing target card is in the first row (step S130). If the card to be processed is in the first line (step S130: YES), the process proceeds to step S136 because forward movement is not possible. If the processing has not been completed for all the cards of the executing user (step S136: NO), the process returns to step S130 for processing the next card.

If the card to be processed is not on the first line (step S130: NO), the process proceeds to step S132. When there is no other card of the execution user in the cell immediately before the cell in which the processing target card is arranged (step S132: NO), the CPU 21 determines to advance the processing target card (step S132: NO). Step S134). At this time, the CPU 21 creates the battle use card data so that the data of the current position of the card to be advanced is updated. When there is another card of the execution user in the cell immediately preceding the cell where the processing target card is arranged (step S132: YES), the CPU 21 cannot advance the processing target card. The process of S134 is not performed.
When the processing is completed for all the cards of the executing user (step S136: YES), the forward moving process of the executing user's card is ended.

(7-5) Enemy user card lateral movement process (FIG. 20)
In the following, the lateral movement process of the enemy user's card when one card is arranged in each cell will be described, but the lateral movement process when a plurality of cards are stacked on the cell is one sheet. It is the same as the case of the card. That is, when a plurality of cards are stacked in the cell, the current position data of all the plurality of cards are updated in conjunction with each other.
The CPU 21 of the game server 20 determines an all card center position (CL_all), which is a column on the matrix indicating the center position of the card group of the entire field (step S140). As described above, the center position of all cards is the center position column between the column of the leftmost cell where the card is arranged and the column of the rightmost cell where the card is arranged in the battle field. . When the center position between the columns is the center between the cells, the column on the right side of the center position is the center position of all cards.
CPU21 will determine the processing order of each card | curd of an enemy user's card group, if the center position of all the cards is determined (step S142). As described above, this processing order is the priority order shown in the following (a-1) to (a-4). When the processing order of each card is determined, the processes of steps S144 to S154 are performed for each card according to the processing order.

(a-1) In the first row, the order of cards arranged from left to right with respect to the center position of all cards
(a-2) In each line other than the first line, the order of cards arranged from left to right with respect to the center position of all cards
(a-3) In the first row, for the cards on the left side of the center position of all cards, the order of the cards arranged from right to left
(a-4) In each line other than the first line, for the cards on the left side of the center position of all cards, the order of the cards arranged from right to left

  While the processing target card satisfies the above (a-1), the processing target card is in the first row (step S144: YES) and is in all the card center positions CL_all, or all the card center positions. Since it is on the right side of CL_all (step S146: YES), the CPU 21 performs a process of moving the processing target card to the left cell (step S148). If there is another card in the destination cell, it is not moved. In step S148, the CPU 21 creates battle use card data so that the current position data of the card to be moved is updated. When the process of step S148 is completed, if the process has not been completed for all the cards of the enemy user (step S154: NO), the process returns to step S144 for the next card process.

  While the processing target card is a card satisfying the above (a-2), there is no processing target card in the first line (step S144: NO), so that one previous on the battle field at the start of the processing of FIG. A process of moving the processing target card is performed in the same manner as the card in the cell (that is, in conjunction with the card) (step S152). That is, when the processing target card is a card in the second and subsequent cells, the movement is performed in the same manner as the movement mode already performed for the card satisfying the above (a-1). In step S152, the CPU 21 creates battle use card data so that the current position data of the card to be moved is updated. When the process of step S152 is completed, if the process has not been completed for all the cards of the enemy user (step S154: NO), the process returns to step S144 for the next card process.

  While the processing target card is a card that satisfies the above (a-3), the processing target card is in the first row (step S144: YES), and is on the left side from the center position CL_all of all cards (step S146: NO), the CPU 21 performs a process of moving the processing target card to the right cell (step S150). If there is another card in the destination cell, it is not moved. In step S150, the CPU 21 creates battle use card data so that the current position data of the card to be moved is updated. When the process of step S150 is completed, if the process has not been completed for all the cards of the enemy user (step S154: NO), the process returns to step S144 for the next card process.

Since the processing target card is not in the first row while the processing target card satisfies the above (a-4) (step S144: NO), the previous card on the battle field at the start of the processing of FIG. A process of moving the processing target card is performed in the same manner as the card in the cell (that is, in conjunction with the card) (step S152). That is, when the card to be processed is a card in the second and subsequent cells, the movement is performed in the same manner as the movement mode already performed for the card satisfying the above (a-3). In step S152, the CPU 21 creates battle use card data so that the current position data of the card to be moved is updated. When the process of step S152 is completed, if the process has not been completed for all the cards of the enemy user (step S154: NO), the process returns to step S144 for the next card process.
When the processing for the last card among the processing target cards satisfying the above (a-4) is completed, the lateral movement processing for all enemy user cards is completed (step S154: YES).

(7-6) Lateral movement process of the executing user's card (FIG. 21)
The following describes the execution user's horizontal movement process when one card is placed in each cell, but the horizontal movement process when multiple cards are stacked on the cell is one sheet. It is the same as the case of the card. That is, when a plurality of cards are stacked in the cell, the current position data of all the plurality of cards are updated in conjunction with each other.
The CPU 21 of the game server 20 determines the enemy card center position (CL_opp), which is a column on the matrix indicating the center position of the enemy user's card group (step S160). As described above, the enemy card center position is the center position between the leftmost cell column in which the card is arranged and the rightmost cell column in which the card is arranged in the user area of the enemy user. It is a column. When the center position between the columns is the center between the cells, the column on the left side of the center position is the enemy card center position.
CPU21 will determine the processing order of each card | curd of an executing user's card group, if the enemy card center position is determined (step S162). As described above, this processing order is the priority order shown in the following (b-1) to (b-4). When the processing order of each card is determined, the processing of steps S164 to S174 is performed for each card according to the processing order.

(b-1) In the first row, the order of cards arranged from right to left with reference to the enemy card center position
(b-2) In each line except the first line, the order of the cards arranged from right to left based on the enemy card center position
(b-3) In the first line, for the cards on the right side of the enemy card center position, the order of the cards arranged from left to right
(b-4) In each line other than the first line, for the cards on the right side of the enemy card center position, the order of the cards arranged from left to right

  While the processing target card satisfies the above (b-1), the processing target card is in the first line (step S164: YES) and is at the enemy card center position CL_opp, or the enemy card center position Since it is on the left side of CL_opp (step S166: YES), the CPU 21 performs a process of moving the processing target card to the right cell (step S168). If there is another card in the destination cell, it is not moved. In step S168, the CPU 21 creates battle use card data so that the current position data of the card to be moved is updated. When the process of step S168 is completed, if the process has not been completed for all the cards of the executing user (step S174: NO), the process returns to step S164 for the next card process.

  Since the processing target card is not in the first row while the processing target card satisfies the above (b-2) (step S164: NO), the previous card on the battle field at the start of the processing of FIG. The process of moving the processing target card is performed in the same manner as the card in the cell (that is, linked) (step S172). That is, when the processing target card is a card in the second and subsequent cells, the movement is performed in the same manner as the movement mode already performed for the card satisfying the above (b-1). In step S172, the CPU 21 creates battle use card data so that the data of the current position of the card to be moved is updated. When the process of step S172 is completed, if the process has not been completed for all cards of the executing user (step S174: NO), the process returns to step S164 for the next card process.

  While the processing target card is a card satisfying the above (b-3), the processing target card is in the first line (step S164: YES) and is on the right side of the enemy card center position (step S166: NO) ) The CPU 21 performs processing for moving the processing target card to the left cell (step S170). If there is another card in the destination cell, it is not moved. In step S170, the CPU 21 creates battle use card data so that the data of the current position of the card to be moved is updated. When the process of step S170 is completed, if the process has not been completed for all cards of the executing user (step S174: NO), the process returns to step S164 for the next card process.

Since the processing target card is not in the first row while the processing target card satisfies the above (b-4) (step S164: NO), the previous card on the battle field at the start of the processing of FIG. The process of moving the processing target card is performed in the same manner as the card in the cell (that is, in conjunction with the cell) (step S172). That is, when the processing target card is a card in the second and subsequent cells, the movement is performed in the same manner as the movement mode already performed for the card satisfying the above (b-3). In step S172, the CPU 21 creates battle use card data so that the data of the current position of the card to be moved is updated. When the process of step S172 is completed, if the process has not been completed for all cards of the executing user (step S174: NO), the process returns to step S164 for the next card process.
When the processing for the last card among the processing target cards satisfying the above (b-4) is completed, the lateral movement processing for all the executing users' cards is completed (step S174: YES).

As explained in detail above, in the battle game between users realized by the game control device of the present embodiment, when a card disappears due to the attack and defense of the card group between users, the card group of each user remaining in the battle field Move in the battle field so that they are adjacent. That is, since each user's card group shows a commanded movement from the start to the end of the battle, the user can enjoy a more realistic feeling in the battle game.
In the attack process of the CPU 21 regarding the battle game of this embodiment, the attack of the card group of the executing user and the enemy user is executed alternately. When the playback file transmitted to the user's communication terminal 10 is played back, Attacks are reproduced at high speed. At this time, any user operation is not required due to the change of the battle phase, and the battle display is more interesting than the conventional turn-based battle.

  As described above, in the battle game of the present embodiment, the cards associated with the user are arranged in the field in order to be used for the battle. At this time, the cards can be stacked (stacked). If the HP (first parameter) of the card of the other user (battle partner) satisfies the disappearance condition due to the attack of the card of one user during the battle between the users, for example, the attacked card disappears from the field. . Therefore, the user is motivated to increase the total sum of HP by cards on the field by stacking cards associated with the user in order to advance the battle advantageously. For example, when a user's possession card has a card with low usage frequency on the game, it is motivated to stack the card on another card and use it. That is, the user can effectively use his / her possession card with low usage frequency, and can avoid a situation in which only some of the possession cards are frequently used. Further, when a plurality of cards are stacked, for example, the attacked card disappears, so that the use result of the stacked cards can be presented to the user in an easy-to-understand manner. As described above, according to this game control device, when performing a battle between users, it is possible to realize a mechanism that can effectively use a card associated with the user in the battle.

In the present embodiment, a monster character is associated with each card (object) as attribute-related information, and the superimposing means 53 displays a card of the same monster character as the card on the card arranged on the battle field. We explained the case of stacking. In this case, since a plurality of cards of the same monster character are arranged in an overlapping manner, for example, by viewing the display content of the top card, the user shows the plurality of cards arranged in an overlapping manner. A monster character can be recognized immediately. Also, for example, when the HP (first parameter) of the same monster character's card is about the same, the execution user is in the battle, the degree to which a plurality of stacked cards are attacked, It can be recognized by the number of lost objects.
When a plurality of cards are stacked, it may not be a requirement for stacking that the plurality of cards are cards of the same monster character. In other words, cards of different monster characters may be stacked. In that case, it may be set so that only cards having the same size can be stacked, or it may be set so that only cards having a smaller size than cards already arranged can be stacked. . In the latter case, for example, a 2 × 2 size card, a 1 × 2 size card, and a 1 × 1 size card may be stacked.

  In this embodiment, the fact that there is no card that can be placed in the user area is defined as a condition for stacking cards. However, such a condition may not be defined. In other words, even if there is a user-owned card with a size that can be placed in an area where no card is placed in the user area of the battlefield, the user-owned card is stacked on the already placed card. It may be possible to do this.

In the present embodiment, the manner in which cards disappear when a plurality of cards are stacked can be set as appropriate. 22A and 22B are diagrams each showing a display example of a card disappearance mode. In each figure, as shown in FIG. 15, three cards (cards C002, C120, C135) are stacked in order in the cell Ca (1, 1) at the start of the battle.
FIG. 22A shows an example in which cards are displayed upright in the game space as shown in FIGS. 10E and 10F. As shown in step S200a of FIG. 22A, at the start of the battle, the cards are arranged in an overlapping order in the order in which the cards are stacked (in the order of cards C002, C120, and C135). In the present embodiment, the card C135 stacked at the top (in this case, arranged on the user area side of the executing user in the game space) is first lost as an attack target card by the enemy user's card. . As a result, as shown in step S201a, the card C120 is the card arranged at the top. If the card C120 disappears as an attack target card by the enemy user's card in the state of step S201a, as shown in step S202a, only the card C002 is placed, and this card C002 is determined by the enemy user's card. It becomes the attack target card.
On the other hand, FIG. 22B is an example in which cards are arranged in parallel to the battle field in the game space, unlike the display methods shown in FIGS. 10E and 10F. In this case, as shown in step S200b, at the start of the battle, the cards are arranged so as to overlap from the bottom to the top in the game space in the order in which the cards are stacked (the order of the cards C002, C120, and C135). In this example, as shown in steps S201b and S202b, the cards become the target of attack by the enemy user's card in order from the top card.

(8) Modified Examples Hereinafter, modified examples of the above-described embodiment will be further described.

(8-1) Modification 1
In the game control device, when the changing means 55 is arranged with a plurality of cards stacked (that is, stacked), the HP (first parameter) change target (that is, among the plurality of cards) The case where the card to be attacked) is the card placed at the top has been described. In this case, for example, when trying to stack a plurality of different monster characters (attributes), the user will be considered to determine the order of the cards that will disappear among the plurality of cards. A battle game can be realized. For example, during a battle, the cards disappear in order from the top card among a plurality of stacked cards. Therefore, by determining the order in which a plurality of cards are stacked, the user can use, for example, a card used in the early stage of the battle. Or you can use different cards for the end of the battle. Note that the position of the uppermost object when a plurality of objects are arranged in an overlapping manner is not limited to a position based on any one of the vertical, horizontal, and front-back directions in the game space.
It is not limited to the case where the attack target card is the card placed at the top. The card to be changed may be the attack target card from the bottom (that is, the cards arranged in the battle field in the order of the stacked cards first).

  In addition, when a plurality of cards are arranged in an overlapping manner, the changing means 55 determines a card to be changed in HP (first parameter) among the plurality of cards at random or according to a predetermined rule. May be. In this configuration, for example, when a plurality of cards of different monster characters (attributes) are stacked, it is difficult for the user to predict a card to be changed from HP among the plurality of cards. Of these cards, the user's attention can be more attracted to the disappearing card. Further, when a card to be changed by HP is determined according to a predetermined rule, for example, a highly strategic battle game that allows the user to consider the order of stacking a plurality of cards of different monster characters can be realized. .

  For example, in order to realize this modification, the CPU 21 of the game server 20 determines a card to be attacked with a predetermined probability when a plurality of stacked cards exist within the range of the range. For example, when three cards are stacked, the probability that each card is an attack target may be 1/3, or may be a probability determined randomly. When the CPU 21 determines a card to be attacked according to a predetermined rule, the predetermined rule may be the order in which the remaining HP is small, or conversely, the order in which the remaining HP is large. If the rule is that the cards to be attacked are the ones with the smallest remaining HP among the plurality of stacked cards, a relatively strong card with a large remaining HP will remain in the battle field for a longer time. Can be made spectacular to the end.

(8-2) Modification 2
In the above-described embodiment, the superimposing means 53 may limit the number of cards that can be placed on the cards arranged on the battle field (that is, the number of cards that can be stacked) to a predetermined number or less. In this configuration, since the number of cards that can be stacked is limited, in order to guide the battle advantageously, the user will have to consider the selection of cards to stack from among the possessed cards, and a highly strategic battle game Can be realized.
In order to realize this modification, the CPU 21 of the game server 20 counts, for example, the number of cards stacked for each cell in the user area of the execution user, and a new card is assigned to the cell whose count value has reached a predetermined value. Arrangement (that is, writing of data into battle use card data) is prohibited.

(8-3) Modification 3
FIG. 23 shows a functional block diagram of the game control apparatus according to this modification. The functional block diagram shown in FIG. 23 is different from that shown in FIG. 14 in that a restricting means 58 is added.
In this modification, as shown in the card database (FIG. 7), the cost as the second parameter is associated with each card. The limiting means 58 is configured such that the sum of the costs of the cards associated with the user and arranged on the battle field and the cards arranged on the cards (that is, stacked cards) is a predetermined value or less. It has a function to restrict so that
In this modification, since the number of cards to be stacked is substantially limited based on the total cost of the user's cards existing in the battle field, which of the user's possessed cards is to be stacked. This makes it possible for the user to consider the above and to realize a highly strategic battle game.
In order to realize the present modification, in step S108 of the card placement process of FIG. 17, the CPU 21 determines whether or not the sum of the card costs (total cost) when the selected cell is placed is equal to or less than a predetermined value. Based on the above, it is determined whether or not the selected card can be arranged. If the total cost is less than or equal to a predetermined value, it is determined that the selected card can be placed, and if the total cost is greater than the predetermined value, it is determined that the selected card cannot be placed.

(8-4) Modification 4
This modification differs from the first embodiment in the lateral movement method of cards in battle.

Execution card center position, enemy card center position, and moving card center position determination method In the lateral movement of the card of this modification, the execution card center position and the enemy card center position are close to each other so that the execution user and the enemy user Move the card group horizontally. In this modification, the execution card center position and the enemy card center position determination method mentioned in the first embodiment are different. Further, a moving card center position indicating the center position of the movement target card is defined. Hereinafter, a method for determining the execution card center position, the enemy card center position, and the moving card center position according to the present modification will be described with reference to FIG.
FIG. 24 shows an enemy card center position (CL_opp) indicating the center position of the enemy user's card group, an execution card center position (CL_exe) indicating the center position of the execution user's card group, It is a figure for demonstrating the movement card | curd center position (CL_mov) which shows the center position of a card | curd. FIG. 24 shows a part of the matrix of the user area of the execution user, and values 0.0, 0.5, 1.0, and 1.0 indicating the position in the column direction of the matrix along the matrix columns. … Is defined. For example, the positions of both ends of the cells in the first column are 0.0 and 1.0, and the center position of the cells in the first column is 0.5. The same applies to the other columns. In the example of FIG. 24, since the matrix is composed of six columns, a value in the range of 0.0 to 6.0 is defined as a value indicating the position in the column direction.

In this modification, in determining the execution card center position (CL_exe), first, the leftmost position of the leftmost cell (referred to as “reference position”) among the cells in the first row of the execution card. Is identified. Next, a value that is ½ of the number of cells in which cards are arranged in the first row of the user area of the executing user is obtained. The execution card center position (CL_exe) is a position where the reference position is moved to the right side along the cell where the card is arranged by the calculated value. FIG. 24 shows a card C101 in the cell Ca (1,2), a card C102 in the cell Ca (1,4), and a card C103 having a size of 1 × 2 in the cell Ca (1,5) and the cell Ca (1,6). The execution card center position (CL_exe) in this example is as follows. In the example of FIG. 24, since the cell in which the card is arranged on the leftmost side is Ca (1, 2), the reference position = 1.0. Next, the number of cells in which cards are arranged in the first row is four. Therefore, the execution card center position (CL_exe) is a value indicating a position obtained by moving the reference position (1.0) to the right by 2 (= 4 × 1/2) along the cell where the card is placed. It will be 4.0.
The enemy card center position (CL_opp) is not shown, but is determined based on the cards arranged in the first row of the user area of the enemy user, as in the case of the execution card center position (CL_exe).
Further, in the example shown in FIG. 24, the moving card center position (CL_mov) of the card C101 arranged in the cell Ca (1,2) is 1.5 and is arranged in the cell Ca (1,4). The moving card center position (CL_mov) of the card C102 is 3.5. The moving card center position (CL_mov) of the card C103 having a size of 1 × 2 arranged in the cell Ca (1,5) and the cell Ca (1,6) is 5.0.

Card Horizontal Movement Method Next, a card horizontal movement method according to this modification will be described. The horizontal movement of the card according to this modification is performed according to the following steps. In the following, the case where the enemy user's card is moved first and then the execution user's card is moved will be described, but conversely, the execution user's card is moved first and then the enemy user's card is moved. Also good.

[Horizontal movement step M11]
When the enemy user's card is moved laterally, the enemy card center position and the execution card center position are determined. Next, based on the comparison result between the enemy card center position and the execution card center position, the order of the cards to be moved by the enemy user's card (that is, the movement order) is determined, and the enemy user's card is moved laterally. . Specifically, it is as follows.
(A) If the execution card center position is on the left side of the enemy card center position (that is, CL_exe <CL_opp), first, the enemy user's card on the right side of the execution card center position (that is, CL_mov) > Card that becomes> CL_exe) is moved horizontally to the left cell in order from the card on the left. Next, the enemy user's card on the left side of the execution card center position (that is, a card satisfying CL_mov <CL_exe) is laterally moved from the right card to the right cell in order.
(B) When the execution card center position (CL_exe) is on the right side of the enemy card center position (that is, CL_exe> CL_opp), first, the enemy user's card (left side of the execution card center position) That is, the card that satisfies CL_mov <CL_exe) is moved horizontally to the right cell in order from the card on the right. Next, the enemy user's card on the right side of the execution card center position (that is, a card satisfying CL_mov> CL_exe) is moved horizontally from the left card to the left cell.
When the execution card center position and the enemy card center position are the same, either of the processes (a) and (b) may be performed.
The enemy user's card (that is, a card with CL_mov = CL_exe) at the same moving card center position as the execution card center position is not moved. If there is another card in the destination cell, it will not be moved. When the card in the first row is moved laterally, other cards on the back in the same column as the card are also moved laterally in conjunction with the cards in the first row.

[Horizontal movement step M12]
In performing lateral movement of the executing user's card, the enemy card center position and execution card center position are determined. Based on the comparison result between the enemy card center position and the execution card center position, the order of cards to be moved by the execution user's cards (that is, the movement order) is determined, and the execution user's cards are moved laterally. Specifically, it is as follows.
(c) When the enemy card center position is on the left side of the execution card center position (that is, CL_exe> CL_opp), first, the executing user's card on the right side of the enemy card center position (that is, CL_mov) > Cards with CL_opp) are moved horizontally to the left cell in order from the card on the left. Next, the executing user's card on the left side of the enemy card center position (CL_opp) (that is, a card satisfying CL_mov <CL_opp) is moved laterally from the right card to the right cell in order.
(d) When the enemy card center position is on the right side of the execution card center position (that is, CL_exe <CL_opp), first, the executing user's card on the left side of the enemy card center position (that is, CL_mov) <Card that becomes CL_opp) is moved horizontally to the right cell in order from the card on the right. Next, the executing user's card on the right side of the enemy card center position (that is, a card satisfying CL_mov> CL_opp) is laterally moved from the left card to the left cell.
When the execution card center position and the enemy card center position are the same, either of the processes (c) and (d) may be performed.
The executing user's card at the same moving card center position as the enemy card center position (that is, a card with CL_mov = CL_opp) is not moved. If there is another card in the destination cell, it will not be moved. When the card in the first row is moved laterally, other cards on the back in the same column as the card are also moved laterally in conjunction with the cards in the first row.

[Exception of horizontal movement processing]
In the lateral movement step M11, when the condition that the difference between the execution card center position and the enemy card center position is 0.5 or less and the difference between the movement card center position and the execution card center position is 0.5 or less is satisfied. May cause the card to be moved to reciprocate left and right across the center position of the execution card. Therefore, when the above condition is satisfied, lateral movement of the enemy user's card to be moved is prohibited.
Similarly, in the lateral movement step M12, the condition is that the difference between the execution card center position and the enemy card center position is 0.5 or less, and the difference between the movement card center position and the enemy card center position is 0.5 or less. If it is satisfied, the card to be moved may reciprocate left and right across the enemy card center position. Therefore, when the above condition is satisfied, lateral movement of the execution user's card to be moved is prohibited.
Note that this exception processing is intended to avoid a situation in which the card to be moved reciprocates left and right by one cell, so the threshold (0.5) for the above difference is the unit of movement (1 cell). Any value smaller than) may be used. For example, the difference is not limited to 0.5 or less, and the difference may be less than 1.

  In the game of this modification, an attack by the executing user's card group and an attack by the enemy user's card group are alternately performed, and each time the attack is performed, the lateral movement process of the cards in the above steps M11 and M12 is sequentially performed. Done. During the battle, the cards are attacked and gradually disappear, so the center position of the execution card and the center position of the enemy card change each time. At this time, for example, when the executing user's card is moved laterally, based on the comparison result between the executing card center position and the enemy card center position, the card on the left or right side is first determined based on the enemy card center position. In order to determine whether to move the card, the card is moved so that the difference between the execution card center position and the enemy card center position becomes early.

-Example of Battle Card Movement Next, in this modification, a specific example of the movement mode of each card of the executing user and the enemy user from the start of the battle to the end of the battle will be described with reference to FIGS. . FIGS. 25A to 25D are diagrams showing the card arrangement on each cell in the battle field when the game space is viewed in a plan view in order to explain the movement mode of the cards from the start to the end of the battle. In each figure, the movement of the card is indicated by an arrow.
In the battle of this modification, for example, as described above, the attack of the card group of the executing user and the enemy user is performed in order. After each user's attack is performed, the card is moved forward and the card is moved in order.

In the battle shown in FIGS. 25A to 25D, as shown in step S210 of FIG. 25A, the user area UAa of the executing user and the user area UAb of the enemy user are each configured by 2 × 6 cells, and the size of each card is all An example of 1 × 1 (that is, an example in which each user has 12 battle use cards) is shown.
Also in this modified example, as in the above-described embodiment, each user's attack is alternately performed, and each process of forward movement and lateral movement is performed after each attack. At the beginning of the battle, each user's card placed in the first line at the beginning of the battle is lost due to the attack. For example, as shown in step S211, the card moves forward. Is called. In step S211, a case where six cards move from the second row to the first row cell is shown.

  When the battle progresses and there is a case where no card exists in any column of each user's area as shown in step S212, lateral movement is performed. In step S212, no card exists in the fifth column of the user area UAa of the execution user and the second and third columns of the user area UAb of the enemy user. In the example of step S212, the execution card center position CL_exe = 2.5, and the enemy card center position CL_opp = 4.0. Therefore, when moving the enemy user's card sideways, first, the enemy user's card on the right side of the execution card center position CL_exe (that is, the card with CL_mov> CL_exe) is moved from the left card to the left cell in order. Move. That is, the card groups in the fourth to sixth columns are moved to the left cell in order from the cards in the fourth column. Next, the enemy user's card on the left side of the execution card center position CL_exe (that is, the card satisfying CL_mov <CL_exe) is moved laterally from the right card to the right cell. That is, the card group in the first column is moved to the right cell. The lateral movement of the enemy user's card is indicated by an arrow in step S213.

In the example of step S213, the execution card center position CL_exe = 2.5 and the enemy card center position CL_opp = 3.0. Therefore, when moving the executing user's card horizontally, the executing user's card on the left side of the enemy card center position CL_opp is first moved to the right cell in order from the card on the right (that is, the card with CL_mov <CL_opp). Move. However, in the example of step S213, the executing user's card on the left side of the enemy card center position CL_opp cannot be moved.
Next, the executing user's card on the right side of the enemy card center position (that is, a card satisfying CL_mov> CL_opp) is laterally moved from the left card to the left cell. In the example of step S213, the card group in the sixth column is moved to the left cell. The lateral movement of the executing user's card is indicated by an arrow in step S214.

  As a result of the battle proceeding from step S214, it is assumed that the card in the first row disappears and the card is moved forward, and the card is placed in step S215. In the example of step S215, the execution card center position CL_exe = 2.0 and the enemy card center position CL_opp = 2.5. Therefore, when moving the enemy user's card horizontally, first move the enemy user's card on the right side of the execution card center position (that is, the card with CL_mov> CL_exe) from the left card to the left cell in order. Let That is, as shown in step S216, one card (card on the cell Cb (1, 5)) in the fifth column is moved laterally to the left cell. In the example of step S216, the enemy user's card on the left side of the execution card center position (that is, a card satisfying CL_mov <CL_exe) cannot be laterally moved to the card on the right.

  In the example of step S216, the execution card center position CL_exe = 2.0 and the enemy card center position CL_opp = 2.5. Therefore, when laterally moving the executing user's card, the executing user's card on the left side of the enemy card center position is moved horizontally from the right card (that is, the card with CL_mov <CL_opp) to the right cell in order. Let However, in the example of step S216, the executing user's card on the left side of the enemy card center position cannot be moved. Next, the executing user's card on the right side of the enemy card center position (that is, a card satisfying CL_mov> CL_opp) is laterally moved from the left card to the left cell. That is, as shown in step S217, one card (card on the cell Ca (1, 5)) in the fifth column is moved laterally to the left cell.

As a result of the battle proceeding from step S217, it is assumed that the card in the first row disappears and the card is moved forward, and the card is placed in step S218. In the example of step S218, the execution card center position CL_exe = 2.0 and the enemy card center position CL_opp = 2.5. In this case, the enemy user's card is only the card arranged in the cell Cb (1, 3), but this card is not moved according to the exception rule of the lateral movement process described above. That is, the moving card center position CL_mov = 2.5 for this card, but the difference between the execution card center position CL_exe and the enemy card center position CL_opp is 0.5 or less, and the movement card center position CL_mov and the execution card center position Since the condition that the difference in CL_exe is 0.5 or less is satisfied, the card in the cell Cb (1, 3) is not moved.
In the example of step S218, the execution user's cards are adjacent to each other, and none of the execution user's cards can be moved due to the positional relationship with the enemy card center position CL_opp.

  As a result of the battle proceeding from step S218, it is assumed that the card in the first row has disappeared and the card has been moved forward, and the card is placed in step S219. In the example of step S219, the execution card center position CL_exe = 1.0 and the enemy card center position CL_opp = 2.5. Therefore, when the enemy user's card is moved laterally, one enemy user's card on the right side of the execution card center position CL_exe (that is, a card satisfying CL_mov> CL_exe) is moved laterally to the left cell. That is, as shown in step S220, the card arranged in the cell Cb (1, 3) is moved to the left cell.

  In the example of step S220, the execution card center position CL_exe = 1.0 and the enemy card center position CL_opp = 1.5. Therefore, when laterally moving the executing user's card, the executing user's card on the left side of the enemy card center position is moved horizontally from the right card (that is, the card with CL_mov <CL_opp) to the right cell in order. Let That is, the execution user's card in the cell Ca (1, 1) is moved to the right cell. Next, the executing user's card on the right side of the enemy card center position (that is, a card satisfying CL_mov> CL_opp) is laterally moved from the left card to the left cell. That is, the card on the cell Ca (1, 4) is moved laterally to the left cell. The lateral movement of the executing user's card is indicated by an arrow in step S221.

  In step S222, it is assumed that one card in the first row of the enemy user's area in step S221 disappears. In this case, since the enemy user's cards have all disappeared, the execution user wins.

As shown in the battle examples of FIGS. 25A to 25D, in the lateral movement method of the card according to the present modification, as in the lateral movement method according to the above-described embodiment, the execution user and the enemy are changed for each attack turn of each user. The card position is adjusted so that the user's card groups face each other. Therefore, each user's card group always faces each other from the start of the battle to the end of the battle, and the realism of the battle is more felt from the executing user, and the direction of attack by each card is mainly set in front of the card. If this is the case, an attack can be effectively applied to the opponent's card placed opposite to the card, so there is also an advantage that the battle wins or loses can be determined quickly.
Further, in this modification, for example, when moving an enemy user's card, a card to be moved first among left and right cards with reference to the execution card center position is compared with the execution card center position and the enemy card center position. Since switching is performed based on the result, cards that reduce the difference between the execution card center position and the enemy card center position move preferentially. The same applies when moving the executing user's card.

-Flow of Card Horizontal Movement Process Next, an example of the flow of the horizontal movement process of this modification will be described with reference to the flowcharts of FIGS. FIG. 26 is a flowchart illustrating an example of a lateral movement process of an enemy user's card. FIG. 27 is a flowchart showing an example of the horizontal movement process of the executing user's card.
Note that the overall flow of this modification may be as shown in FIG. 16 as in the above-described embodiment. In this modified example, in steps S44 and S44 in the overall flow of FIG. 16, the flowcharts of FIGS. 26 and 27 are executed instead of FIGS. 20 and 21, respectively.

-Enemy user's card movement process (Fig. 26)
The CPU 21 of the game server 20 first refers to the battle use card data, and executes an execution card center position CL_exe indicating the center position of the execution user's card group, and an enemy card center position CL_opp indicating the center position of the enemy user's card group. Is determined (step S240). After determining the execution card center position CL_exe and the enemy card center position CL_opp, the CPU 21 determines the processing order of each card of the enemy user's card group based on the comparison result between the two (step S242).

As described above, the card processing order differs depending on the comparison result between the execution card center position CL_exe and the enemy card center position CL_opp, and is as follows, for example.
(a) When the execution card center position is the same position as the enemy card center position or to the left of it (that is, CL_exe ≦ CL_opp), the following (a-1) to (a The priority order is as shown in -6).
(a-1) In the first line, among the cards of the enemy user on the right side of the execution card center position (that is, the card with CL_mov> CL_exe), the order of the cards arranged from left to right
(a-2) In each line other than the first line, among the cards of enemy users on the right side of the execution card center position (that is, cards with CL_mov> CL_exe), the order of the cards arranged from left to right
(a-3) In the first line, among the cards of the enemy user on the left side of the execution card center position (that is, the card with CL_mov <CL_exe), the order of the cards arranged from right to left
(a-4) The order of cards arranged from right to left among the cards of enemy users on the left side of the execution card center position (that is, cards with CL_mov <CL_exe) in each line other than the first line
(a-5) In the first row, the enemy user's card in the same column as the execution card center position (that is, a card with CL_mov = CL_exe)
(a-6) Enemy user's card in the same column as the execution card center position in each line other than the first line (that is, a card with CL_mov = CL_exe)

(b) When the execution card center position is on the right side of the enemy card center position (that is, when CL_exe> CL_opp), the priority order is as shown in (b-1) to (b-6) below. .
(b-1) In the first line, among the cards of enemy users on the left side of the execution card center position (that is, cards with CL_mov <CL_exe), the order of the cards arranged from right to left
(b-2) The order of cards arranged from right to left among the cards of enemy users on the left side of the execution card center position (that is, cards with CL_mov <CL_exe) in each line other than the first line
(b-3) In the first row, among the enemy user's cards on the right side of the execution card center position (that is, cards with CL_mov> CL_exe), the order of the cards arranged from left to right
(b-4) In each line other than the first line, among the cards of the enemy user on the right side of the execution card center position (that is, the card with CL_mov> CL_exe), the order of the cards arranged from the left to the right
(b-5) In the first row, the card of the enemy user in the same column as the execution card center position (that is, the card with CL_mov = CL_exe)
(b-6) Enemy user's card in the same column as the execution card center position in each line other than the first line (that is, a card with CL_mov = CL_exe)

When the processing order of each card is determined, the processing of steps S244 to S258 is performed for each card according to the processing order.
First, the CPU 21 determines whether or not the processing target card is a card arranged in the first row (step S244). If the processing target card is a card arranged in the first row (step S244: YES), the process proceeds to step S246, and if the processing target card is not a card arranged in the first row ( Step S244: NO), the process proceeds to Step S256.

The absolute value (| CL_opp−CL_exe |) of the difference between the execution card center position CL_exe and the enemy card center position CL_opp is 0.5 or less (step S246: NO), and the moving card center position CL_mov of the processing target card
When the absolute value (| CL_mov−CL_exe |) of the difference between the execution card center position CL_exe is 0.5 or less (step S254: YES), the process proceeds to step S258 without performing the horizontal movement process on the processing target card. Proceed (see [Exceptions to horizontal movement processing] above).

  Whether the absolute value (| CL_opp−CL_exe |) of the difference between the execution card center position CL_exe and the enemy card center position CL_opp is greater than 0.5 (step S246: YES), or execution with the moving card center position CL_mov of the processing target card If the absolute value (| CL_mov−CL_exe |) of the difference between the card center positions CL_exe is larger than 0.5 (step S254: NO), the process proceeds to step S248. In step S248, the moving card center position CL_mov is compared with the execution card center position CL_exe, and the processing differs based on the comparison result.

  If the processing target card is a card that satisfies either of the above (a-1) and (b-3), the moving card center position of the processing target card is on the right side of the execution card center position (step S248). : CL_mov> CL_exe), the CPU 21 performs processing for moving the processing target card to the left cell (step S250). If there is another card in the destination cell, it is not moved. In step S250, the CPU 21 creates battle use card data so that the current position data of the card to be moved is updated. When the process of step S250 is completed, if the process has not been completed for all the cards of the enemy user (step S258: NO), the process returns to step S244 for the next card process.

  If the card to be processed is a card satisfying either of the above (a-3) and (b-1), the moving card center position is on the left side of the execution card center position (step S248: CL_mov <CL_exe ) The CPU 21 performs processing for moving the processing target card to the right cell (step S252). If there is another card in the destination cell, it is not moved. In step S252, the CPU 21 creates battle use card data so that the current position data of the card to be moved is updated. When the process of step S252 is completed, if the process has not been completed for all the cards of the enemy user (step S258: NO), the process returns to step S244 for the next card process.

  If the card to be processed is a card that satisfies either of the above (a-5) and (b-5), the moving card center position is the same as the execution card center position (step S248: CL_mov = CL_exe). The CPU 21 proceeds to step S258 without performing the process of moving the processing target card. If the processing has not been completed for all the cards of the enemy user (step S258: NO), the process returns to step S244 for processing the next card.

  The card to be processed is a card that satisfies any of the above (a-2), (a-4), (a-6), (b-2), (b-4), or (b-6). In some cases, the card is not in the first row (step S244: NO), so that it is the same as the card that was in the previous cell on the battle field at the start of the process of FIG. ), A process of moving the processing target card is performed (step S256). That is, when the processing target card is a card in the second and subsequent cells, the above (a-1), (a-3), (a-5), (b-1), (b-3 ) and (b-5), the movement is performed in the same manner as the movement mode already performed for the card satisfying either of (b-5). In step S256, the CPU 21 creates battle use card data so that the current position data of the card to be moved is updated. When the process of step S256 is completed, if the process has not been completed for all the cards of the enemy user (step S258: NO), the process returns to step S244 for the next card process.

Execution user card horizontal movement processing (FIG. 27)
The CPU 21 of the game server 20 first refers to the battle use card data, and executes an execution card center position CL_exe indicating the center position of the execution user's card group and an enemy card center position CL_opp indicating the center position of the enemy user's card group. Is determined (step S260). When the CPU 21 determines the execution card center position CL_exe and the enemy card center position CL_opp, the CPU 21 determines the processing order of each card of the enemy user's card group based on the comparison result between the two (step S262).

As described above, the card processing order differs depending on the comparison result between the execution card center position CL_exe and the enemy card center position CL_opp, and is as follows, for example.
(c) When the enemy card center position is on the left side of the execution card center position (that is, CL_exe> CL_opp), the priority order is as shown in (c-1) to (c-6) below. .
(c-1) In the first line, among the executing user's cards on the right side of the enemy card center position (that is, cards with CL_mov> CL_opp), the order of the cards arranged from left to right
(c-2) The order of cards placed from the left to the right among the executing user's cards on the right side of the enemy card center position (ie, the card with CL_mov> CL_opp) in each line other than the first line
(c-3) In the first line, among the executing user's cards that are on the left side of the enemy card center position (CL_opp) (that is, the cards that are CL_mov <CL_opp),
(c-4) In each line other than the first line, among the executing user's cards on the left side of the enemy card center position (CL_opp) (that is, cards with CL_mov <CL_opp), they are arranged from right to left. Card order
(c-5) In the first row, the card of the executing user in the same column as the enemy card center position (CL_opp) (that is, the card with CL_mov = CL_opp)
(c-6) In each row other than the first row, the executing user's card in the same column as the enemy card center position (CL_opp) (that is, a card with CL_mov = CL_opp)

(d) If the enemy card center position is the same position as the execution card center position or on the right side of it (that is, CL_exe ≦ CL_opp), the following (b-1) to (b- The priority order is as shown in 6).
(d-1) In the first line, among the executing user's cards on the left side of the enemy card center position (that is, cards with CL_mov <CL_opp), the order of the cards arranged from right to left
(d-2) In each line other than the first line, among the executing user's cards on the left side of the enemy card center position (that is, cards with CL_mov <CL_opp), the order of the cards arranged from right to left
(d-3) In the first line, among the executing user's cards on the right side of the enemy card center position (that is, cards with CL_mov> CL_opp), the order of the cards arranged from left to right
(d-4) In each line other than the first line, among the executing user's cards on the right side of the enemy card center position (that is, cards with CL_mov> CL_opp), the order of the cards arranged from left to right
(d-5) In the first row, the card of the executing user in the same column as the enemy card center position (that is, the card with CL_mov = CL_opp)
(d-6) In each row other than the first row, the executing user's card in the same column as the enemy card center position (that is, a card with CL_mov = CL_opp)

When the processing order of each card is determined, the processes of steps S264 to S278 are performed for each card according to the processing order.
First, the CPU 21 determines whether or not the processing target card is a card arranged in the first row (step S264). If the processing target card is a card arranged in the first row (step S264: YES), the process proceeds to step S266, and if the processing target card is not a card arranged in the first row ( Step S264: NO), the process proceeds to step S276.

  The absolute value (| CL_opp−CL_exe |) of the difference between the execution card center position CL_exe and the enemy card center position CL_opp is 0.5 or less (step S266: NO), and the moving card center position CL_mov of the processing target card and the enemy When the absolute value (| CL_mov−CL_opp |) of the difference of the card center position CL_opp is 0.5 or less (step S274: YES), the process proceeds to step S278 without performing the lateral movement process on the processing target card ( (Refer to [Exceptions to horizontal movement processing] above).

  Whether the absolute value (| CL_opp−CL_exe |) of the difference between the execution card center position CL_exe and the enemy card center position CL_opp is greater than 0.5 (step S266: YES), or the moving card center position CL_mov of the processing target card and the enemy If the absolute value (| CL_mov−CL_opp |) of the difference in the card center position CL_opp is larger than 0.5 (step S274: NO), the process proceeds to step S268. In step S268, the moving card center position CL_mov is compared with the enemy card center position CL_opp, and the processing is different based on the comparison result.

  If the card to be processed is a card that satisfies either of the above (c-1) and (d-3), the moving card center position of the processing target card is on the right side of the enemy card center position (step S268). : CL_mov> CL_opp), the CPU 21 performs processing for moving the processing target card to the left cell (step S270). If there is another card in the destination cell, it is not moved. In step S270, the CPU 21 creates battle use card data so that the current position data of the card to be moved is updated. When the process of step S270 is completed, if the process has not been completed for all the cards of the executing user (step S278: NO), the process returns to step S264 for the next card process.

  If the card to be processed is a card that satisfies either of the above (c-3) and (d-1), the moving card center position is on the left side of the enemy card center position (step S268: CL_mov <CL_opp ) The CPU 21 performs processing for moving the processing target card to the right cell (step S272). If there is another card in the destination cell, it is not moved. In step S272, the CPU 21 creates battle use card data so that the current position data of the card to be moved is updated. When the process of step S272 is completed, if the process has not been completed for all the cards of the executing user (step S278: NO), the process returns to step S264 for the next card process.

  If the card to be processed is a card that satisfies either of the above (c-5) and (d-5), the moving card center position is the same as the enemy card center position (step S268: CL_mov = CL_opp). The CPU 21 proceeds to step S278 without performing the process of moving the processing target card. If the processing has not been completed for all the cards of the executing user (step S278: NO), the process returns to step S264 for processing the next card.

  The card to be processed is a card that satisfies any of the above (c-2), (c-4), (c-6), (d-2), (d-4), or (d-6). In some cases, the card is not in the first line (step S264: NO), so that it is the same as the card that was in the previous cell on the battle field at the start of the process of FIG. ), A process of moving the processing target card is performed (step S276). That is, for the case where the card to be processed is a card in the second and subsequent cells, the above (c-1), (c-3), (c-5), (d-1), (d-3 ) and (d-5), the movement is performed in the same manner as the movement mode already performed on the card satisfying either of (d-5). In step S276, the CPU 21 creates battle use card data so that the current position data of the card to be moved is updated. When the process of step S276 is completed, if the process has not been completed for all the cards of the executing user (step S278: NO), the process returns to step S264 for the next card process.

  As mentioned above, although embodiment of this invention was described in detail, this invention is not limited to the said embodiment. In addition, it goes without saying that each embodiment may be variously improved and changed without departing from the gist of the present invention. The technical matters described in the above embodiment and each modification may be applied in appropriate combination.

In the embodiment and the modification described above, the case where the front direction of the card is made to coincide with the row direction of the matrix and the horizontal movement direction of the card is made to coincide with the direction of the column of the matrix has been described. The forward direction of the card may be matched with the direction of the matrix column, and the lateral movement direction of the card may be matched with the direction of the matrix row. In that case, a battle is performed in which the user's cards face each other on the web page (that is, in the horizontal direction).
In the embodiment and the modification described above, the card moving direction is described as being either forward or lateral, but this is not a limitation. For example, you may set the card | curd which moves diagonally forward (diagonal right front or diagonal left front).
In the embodiment and the modification described above, the case where the battle field is a rectangular matrix has been described. However, the present invention is not limited to this case. As long as the card group of the executing user and the enemy user can move adjacent to each other, other forms may be used. For example, it may be a polygon such as a triangle or a hexagon (honeycomb shape).
In the embodiment and the modification described above, the processing order of cards when the card group is moved laterally is only an example. Based on the center position (center position of all cards, enemy card center position, or execution card center position), the card on the left side may be moved first, then the card on the right side may be moved, or on the right side. The card may be moved first, and then the card on the left side may be moved.

  In each embodiment mentioned above, although the monster card | curd was mentioned as an example of an object, it is not restricted to this. Any object can be used. For example, the object may include characters, items, etc. on the game, such as virtual persons, creatures, or monsters on the game, and these are displayed on the card as shown in this embodiment. Including those that are.

  In the above-described embodiment, the predetermined operation input by the user to the communication terminal is an input of a pressing operation of a predetermined operation button on the user's communication terminal or an input of a touch operation on the display screen to the communication terminal having a touch panel function. Although there is, the operation input is not limited to this. The operation input may be an operation input by shaking a communication terminal provided with an acceleration sensor, or an operation input by gesture (gesture input). In gesture input, by performing a predetermined gesture on a communication terminal having an imaging function, the communication terminal recognizes an image of the gesture and recognizes an operation input previously associated with the gesture. In the case of a communication terminal capable of executing a voice recognition program, the operation input may be performed by inputting voice.

  In the above-described embodiment, the game server 20 and the database server 30 on the network are configured to implement the functions of each unit illustrated in FIG. 14, but the configuration is not limited thereto. All or at least a part of the means shown in FIG. 14 may be realized by the communication terminal 10. Since the communication terminal 10 and the game server 20 have substantially the same hardware configuration, each function can be realized by the communication terminal 10 as described in the above embodiment. FIG. 28A and FIG. 28B each show a case where the functions between the communication terminal 10 and the game server 20 and the database server 30 are shared for each function (each function shown in FIG. 14) of the game control device of the present embodiment. An example of

  In the above-described embodiment, the game server 20 creates a reproduction file based on a series of battle use cards from the start to the end of the battle and transmits the reproduction file to the communication terminal 10, and the communication terminal 10 reproduces the reproduction file to perform the battle. Although the case where the video is played back has been described, the present invention is not limited to this. For example, the communication terminal 10 may store the execution user's battle use card data, acquire the enemy user's battle use card data at the start of the battle, and the communication terminal 10 may create a reproduction file. In this case, a program for realizing moving means, changing means, and the like is executed by the CPU 11 of the communication terminal 10.

  In the above-described embodiment, the case where the present invention is applied to a social game has been described as an example, but the present invention is not limited to this. For example, it can be realized by a stand-alone game machine, and can also be realized by a so-called online game system in which a server device placed on a network and a home online game machine are connected.

10: Communication terminal 11 ... CPU
12 ... ROM
13 ... RAM
DESCRIPTION OF SYMBOLS 14 ... Image processing part 15 ... Instruction input part 16 ... Display part 17 ... Communication interface part 18 ... Bus 20 ... Game server 21 ... CPU
22 ... ROM
23 ... RAM
24 ... Database access unit 25 ... Communication interface unit 26 ... Bus 30 ... Database server 31 ... User database 32 ... Game database 51 ... Association means 52 ... Arrangement means 53 ... Superposition means 54 ... Battle progress means 55 ... Change means 56 ... Disappearance Means 57 ... Moving means

Claims (7)

A game control device that executes a battle between the user and the opponent using a user object and the opponent object of the user, the object being associated with a parameter,
Arrangement means for arranging the user's object in a predetermined field in the game space according to the object arrangement determined based on the user's operation input before starting the battle;
In the battle, based on one of the objects of the user and the opponent, changing means for changing a parameter associated with any object used by the other of the user and the opponent;
An erasure means for erasing the object from the field when a parameter associated with the object satisfies a predetermined erasure condition;
With
When the object arrangement indicates the arrangement of a plurality of objects at the same position, the arrangement means arranges the plurality of objects at the same position in the field,
The erasure unit is characterized in that when any one of a plurality of objects arranged at the same position is lost, the number of objects arranged at the same position is reduced.
Game control device. Displaying the object so that the user can identify the number of objects arranged at the same position,
The game control apparatus according to claim 1. The arrangement means is characterized in that the number of objects that can be arranged at the same position is limited to a predetermined value or less,
The game control device according to claim 1 or 2. The placement means limits the objects that can be placed at the same position to objects having the same attribute,
The game control device according to claim 1. The battle is performed without receiving an operation input by the user from when the battle is started until the victory or defeat of the battle is determined.
The game control apparatus as described in any one of Claims 1-4. A program for executing a battle between the user and the opponent using a user object and an opponent object of the user, the object being associated with a parameter,
The program for functioning a computer as each means of the game control apparatus in any one of Claims 1-5. A game system including a communication terminal and a server accessed from the communication terminal, and performing a battle between the user and the opponent using a user object and an opponent object of the user , The object has associated parameters,
A game system, wherein each means of the game control device according to claim 1 is provided in either one of the communication terminal or the server.

Images