JP6232533B1 - Computer game program - Google Patents

Abstract

Provided is a computer game program that cannot imitate an advanced player even if imitating a software hand pointing to a shogi or chess. In a conventional shogi or chess, if there is an enemy piece B on a movable square of a certain piece A, the piece A is taken by the piece A and the piece A is moved to the square where the piece B was located. However, in the present invention, when software is created so that it can be played using a computer, parameters such as life force, attack power, attack interval, defense power, waiting time for moving, resurrection waiting time, etc. are assigned to each piece. In addition, if the life force of the enemy piece is not less than zero, a function unique to the computer is added to the shogi or chess, such as preventing the enemy piece from moving. [Selection] Figure 7

Description

The present invention relates to a computer game program capable of playing shogi, chess and similar on-board games using a computer and a computer network.

JP 2004-089584 A

Software that points to shogi and chess can now win against professional players, but if you imitate the strong software pointers, even beginners of shogi and chess can impersonate you.

In conventional shogi or chess, if there is an enemy piece B on a movable square of a piece A, the piece A can be taken by the piece A and moved to the square where the piece B was, In the invention, when software is made so that it can be played using a computer, parameters such as life force, attack power, attack interval, defense power, waiting time for moving, resurrection waiting time, etc. are given to each piece, If the enemy's life force is not less than zero, add functions that are unique to computer use to the shogi and chess, such as making it impossible to take and move enemy pieces.

If there is an enemy piece on the trout where the ally piece can move, attack the enemy piece with a flying tool such as a beam, missile, bullet, or shuriken to reduce the vitality of the piece.

When the life force of a piece decreases due to an attack of a missile and eventually becomes less than zero, the piece is deactivated (transition to a state where it is impossible to move and attack and there is a possibility that the piece can be taken) .

An inactive piece cannot be moved or attacked with the possibility of being taken by an enemy piece, but will restore life force if it is not taken by the enemy piece until the time set in the Resurrection Time parameter has elapsed. To activate (transition to a state where movement and attack are possible and no piece is taken).

Even in the active state, after the movement, the piece is temporarily made impossible to move until the time set in the movement waiting time parameter elapses so that the piece cannot be moved.

The moveable piece can be operated without waiting for the opponent player's turn.

The initial values of the various parameters of the piece can be adjusted in advance within a certain range by the player.

The initial placement of the pieces and the place where the pieces are advanced are the same as those of conventional shogi and chess and similar on-board games.

It can be made meaningless to imitate traditional shogi and chess software moves.

It is a process division diagram designed by the client / server model as an example of the present invention. 2 shows a basic flow of a client process as an embodiment of the present invention. The basic flow of the server process as an Example of this invention is shown. It is explanatory drawing of the frame parameter adjustment screen as an Example of this invention. It is explanatory drawing of the various state display of the piece as an Example of this invention. It is explanatory drawing of the initial arrangement | positioning and state display of the piece at the time of the game start as an Example of this invention. It is explanatory drawing of the state which opened the corner path with seven steps from the initial position as an Example of this invention. It is explanatory drawing of the piece data and missed tool data as an Example of this invention. It is explanatory drawing when the enemy piece used as the attack object as an Example of this invention does not have an inactive piece. It is explanatory drawing when there exists a piece of an inactive state in the enemy piece used as the attack object as an Example of this invention.

Hereinafter, the example at the time of changing the conventional shogi by this invention is shown. As a feature of the present embodiment, the piece parameter is not sent to the enemy client, and therefore the enemy's movement waiting time and recovery waiting time are not visualized. All missiles shall move one square of the board at a speed of 1000 ms.

As shown in FIG. 1, a server process for performing various determination processes and state transition processes 0101 and a client process for performing player piece operation processes and screen display processes 0103 are designed separately. The server process is implemented in server software, and the client process is implemented separately in client software. Information transmission means 0102 between server software and client software is network communication.

Build an online battle system using the Internet. Network communication 0102 uses TCP / IP. The client process is provided online as a script that can be executed by various Internet browsers. The server process shall be incorporated into the software developed independently.

In the case of an online battle system using the Internet, although some lag occurs on the client terminal screen due to the influence of network latency, all judgment processing and state transition processing are performed only by the server process, so there is no conflict within the system. There will be no asynchronous / server intensive processing online battle system. Even a system constructed for online battle can be used as an offline battle system with one local computer by using loopback or using a virtual computer.

The basic flow of the client process is shown in FIG. The frame data having received the initial state and coordinates of all the frames from the server process 0201 is displayed on the client terminal by the screen update process 0202, the battle is started, and the event wait 0203 is entered. Here, a frame operation event (mouse click, etc.) and a reception event from the server process are accepted. The event waiting time is 50 ms. If any event occurs, it is determined whether or not the piece has been operated 0204. If the piece has been operated, the operated piece and the movement destination coordinates are transmitted 0205 to the server process. When there is a data reception event from the server process, all pieces of frame data and flying tool data that have changed are received from the server process by the data reception processing 0207. If there is winning / losing confirmation data in the received data, it is determined as winning / losing confirmation 0208 and the process proceeds to the screen update process 0210. After displaying the board at the time of winning / losing confirmation, the winning / losing display process 0211 is performed and the battle is ended. If the winning / losing is not confirmed, the positions of valid flying tool data (all the flying tools that have not yet disappeared after being generated) are calculated 0209, and the screen update process 0202 is returned to. The screen update process 0202 at this time displays the board, all the pieces, and all the flying tools.

The basic flow of the server process is shown in FIG. The player-defined frame data reading 0301 is read from the data that has been adjusted before the match and stored in the server on the frame parameter adjustment screen of FIG. If there is no saved data, the default value is set. Based on the initial state and coordinate setting 0302 of all the pieces, the initial coordinates of the shogi are set with all the pieces in the active state and the waiting state for movement, and all piece data is transmitted 0303 to the client process. In data reception waiting 0304 from the client process, the movement destination coordinates of the piece operated by the player are received. The reception waiting time is set to 50 ms. When the movement destination coordinates of the piece are received, it is determined that the movement is impossible by the internal processing of the piece movement process 0306. If the movement is possible, the movement is stored in the memory internally managed by the server process. The board is updated. Even if it is impossible to move, it is handled as a frame that has changed, and is set to return to the original coordinates or possessed frame. The frame and flying tool data that have changed after 0307 processing are sent to the client process. On the other hand, the piece is returned to the original coordinates or the holding piece. Even when the reception waiting time-out is 0305, even after the piece movement process 0306 is performed, the hit determination of all the flying tools and the state transition process 0307 of all the pieces are performed, and the piece data that has caused some change and generated or disappeared The missed tool data is all transmitted by sending 0308 the piece having changed and the missed tool data to the client process. When the king general or ball general is taken, the win / loss is transmitted from the win / loss confirmation 0309 to the client process 0310 and the process ends. If win / loss is not confirmed, the process waits again for data reception 0304 from the client process.

A piece parameter adjustment screen in the client terminal is shown in FIG. Players make adjustments before the match and save them on the server. Reference numeral 0401 denotes a selection cursor for a piece to be adjusted. Select by mouse operation. Reference numeral 0404 denotes the selected piece. The value 0403 is a parameter value set by the adjustment knob 0405. In the embodiment, a coefficient from 1 to 15 can be set for each parameter. The default value for each parameter is 5. If life force is 1, attack power is 5, attack interval is 3, defense power is 5, movement waiting time is 9, and recovery time is 5 as shown in FIG. These 2 remaining points can be assigned to other frames. The setting value is stored in the server, and the server process is read and sent to the client process at the time of the battle. In the present embodiment, even if it is an adjusted piece, the piece (held piece) that has been taken is reset to the default value, so it is not necessary to know because the piece parameter value of the opponent is not used. Therefore, only the piece parameter set and saved by the player itself is received by the client process via the server process.

The piece in FIG. 5A is a movable state in an active state (attackable state). 0501 is visualized as the percentage of vitality in the length of the bar. If the vitality is 100%, a complete bar is drawn. If the vitality decreases, the bar becomes shorter. The piece 0502 is displayed in a normal state.

The frame (B) in FIG. 5 is in the active state waiting for movement. The life force bar of 0503 is visualized similarly to 0501. The piece 0504 is displayed in a normal state. In 0505, the percentage of the waiting time for movement is visualized in a circle. If the waiting time is 100%, a complete circle is drawn. If the waiting time for travel is reduced, the circle will be missing. When the movement waiting time becomes 0% and the circle disappears, the piece becomes an active movable state. As shown in FIG. 6, in this embodiment, the circle of the enemy's movement waiting time is not visualized.

The piece (C) in FIG. 5 is in an inactive state (non-movable state and non-attackable state). The life force of 0506 shows zero percent. The piece 0507 is displayed in gray. 0508 visualizes the percentage of resurrection latency. A complete circle is drawn if the resurrection waiting time is 100%. If the waiting time for the resurrection decreases, the circle will be missing. When the recovery waiting time becomes 0% and the circle disappears, the vitality is returned to 100%, the piece becomes an active movable state, and the display of the piece 0507 is also returned to the original color.

At the start of the battle, as shown in FIG. 6, all the pieces are in the active state waiting for movement. With the passage of time, the player can point from a piece with a short movement waiting time. FIG. 7 shows a board surface where the player has made seventy-seven steps movable and pointed to the seventh step. The walk that moved to 76 is again waiting to move. In the case of a traditional shogi, 8 octagons can take 33 steps with the following hand, but in the present invention, if an enemy piece (33 steps in this example) is active under these conditions, A friend's piece (8 octagons in this example) will attack with a flying tool. 0701 is a flying tool shot by 8 octagons.

FIG. 8A shows data transmitted 0205 to the server process with the operated piece and the movement destination coordinates shown in FIG. 2 when pointing to the sixth step in FIG. 7 at the client terminal. If there is a piece and a piece is used, the holding piece state is turned on and the original coordinates are n / a. If a moving piece is made, the client process will be forced to choose whether or not to become a player. If the player chooses to become, the turn state is turned on. However, in online games using the Internet, due to the influence of network latency, etc., the board on the memory internally managed by the server process has changed, and enemy pieces have already been placed. There may be situations where the cannot move. Even if the selection process or the determination process is performed in the client process, it is only temporary, and the final determination process and determination are performed by the server process. If the server process determines that the movement of the piece and the instruction to make it are impossible, etc., the piece having changed in FIG. 3 and the flying tool data are transmitted to the client process, and the client process is caused to return the piece to the original position in 0308.

FIG. 8 (B) shows the change in FIG. 3 when pointing to the sixth step of FIG. 7 at the client terminal. The piece data is sent. If there are multiple pieces that have changed, all of them will be sent at once. The vitality of the piece is shown as a percentage. Even if the piece is operated by the player 1, the operation is not confirmed at the terminal of the player 1 until (B) in FIG. 8 is sent to the client process. The waiting time for movement is visualized after the data is judged by the server process and the operation is confirmed and the waiting state for moving is received. Display lag may occur due to the effects of network latency, but there is no problem because there is no conflict within the server process. The same is true for the wait for resurrection. Since the attack interval (time) is processed only inside the server, it is not sent to the client process as piece data. Instead, the missile data is sent to the client process.

(C) in FIG. 8 sends the piece and jumping tool data that have changed in FIG. 3 to the client process when pointing to the sixth step in FIG. 7 at the client terminal 0308 to the client processes of player 1 and player 2 This is the missile tool data sent. If there are multiple missiles that have changed, all of them will be sent at once. When attacking an enemy piece, the shooting coordinates and target coordinates are set and sent to the client process as state = generation. The flying, cornering, and incense wheel can move to the edge of the board if there are no enemy pieces. In accordance with this, the target coordinates of the flying, cornering, and scenting tool are set so that they fly to the edge of the board when an enemy piece is avoided. In the client terminal, when the missile tool data is received, display of the missile tool starts by the screen update process 0202 of FIG. In this embodiment, the event wait timeout is set to 50 ms, so the display is updated every 50 ms at the latest. Based on the time when the flying tool data (state = generation) is received and the time of the screen update process 0202, the position where the flying tool should be displayed is determined and displayed. It is assumed that the flying tool does not hit while the piece is moving. If the third and third steps in FIG. 7 are pointed to as three and four steps and then the two corners are pointed to as seven heptagons, it will pass the flying tool 0701. Basically, a missile will automatically disappear when it reaches the target coordinates, but if a missile that is shot from a flying car, cornering, or incense wheel hits an enemy piece, it will disappear there. In this case, the jump tool # (number) to be deleted is set, and the state = disappearance is set, and the piece and the jump tool data that have changed in FIG. 3 are transmitted to the client process 0308. , And the corresponding flying tool is erased from the client terminal.

FIG. 9A shows attack processing when a piece having a plurality of destination coordinate options has a plurality of active pieces at the destination. Since 2 kings and 4 hops are active, they are both attack targets. The missiles 0901 are shot at 4 at the same time, and the missiles 0902 are at the same time towards the 21st king.

FIG. 9B shows attack processing in the case where a piece having a plurality of choices of movement destination coordinates does not exist in all of the movement destinations. Flying tool 0903 has been shot aiming at 3 to 3 Katsura. Flying tool 0904 is shot from 3 Sankei to aim at 21 kings. 4 Since there is no piece in the first, no flying tool is shot in that direction.

FIG. 10 shows attack processing when a piece having a plurality of choices of movement destination coordinates has an active piece and an inactive piece at the movement destination. 4 Ippei is inactive and will not attack. 21 Since the king is active, he is shooting out the flying tool 1001.

Claims (7)

A computer game program for allowing a shogi, chess and similar on-board games to be played against each other using a computer , giving life force parameters to each piece, and the state of the piece (movable and attackable) Active state / movement and inactive state that cannot be attacked) and coordinates are stored in the memory, and when the movement coordinates of the piece are instructed to the computer by the computer terminal operated by the player, it is determined whether or not the piece is movable. If it can move, update the coordinates of the pieces and move the pieces. If an enemy piece is active at the coordinates where each piece can be moved by the next hand, a beam or missile from the ally piece. The enemy's life force is attacked by attacking enemy pieces by displaying them on the computer terminal's display where the player operates flying instruments such as bullets, bullets and shurikens. If the life force drops below zero, the piece is transitioned to the inactive state, and only if there is an inactive enemy piece in the coordinate where the ally piece can move. A computer game program for realizing the function of depriving enemy pieces that have become inactive. By holding the memory by adding the revival latency parameter in the piece, weighing the piece elapsed time using a timer of said computer immediately after falls below vitality is attacked zero to the computer, Once revived wait time elapses, by setting the constant value to the life force of the piece, a computer game program according to claim 1 for further achieving the function of transitioning the piece to be movable and exploitable active state. By holding the memory by adding the attack power parameter in the piece, a computer game program according to claim 1 for further realizing the function of changing the degree of decrease vitality pieces of enemy attack to the computer. By holding the memory by adding the attack interval parameter to said piece, to said frame to said computer measures a passage of time using a timer of said computer immediately after attack, attack time interval has elapsed, computer game program according to claim 1 for further realizing the function of the frame is not performed next attack. By holding the memory by adding a defense parameters in the piece, a computer game program according to claim 1 for further realizing the function of changing the degree of decrease vitality by enemy piece attack to the computer. By holding the memory by adding the moving latency parameter to said frame, it measures a passage of time using a timer of said computer immediately after the piece is moved to the computer, to the movement delay time has expired a computer game program according to claim 1 for further realizing the functions that can not be moved the piece. Computer game program according to any one of claims 6 adjustable function parameter values in the player setting screen before the remote station of said frame from claim 1 for further implemented to the computer.