JP5842073B2 - User terminal and game providing program - Google Patents

Description

The present invention relates to a user terminal and the game provides a program that provides the game contents by web applications efficiently.

  Today, application software such as various online games is provided to users who use computer terminals such as smartphones. In application software, a native application in a format that can be directly interpreted and executed by a microprocessor of a terminal such as a personal computer or a smartphone can be used. On the other hand, it is also possible to use a web application that can be used on a browser without depending on the type of terminal (see, for example, Non-Patent Document 1).

  Furthermore, a server device that can prevent a user's willingness to continue the game according to the progress of the game has been studied (see, for example, Patent Document 1). The server device described in this document advances a game while communicating with a terminal. Here, when the first event occurs during the progress of the game, the parameter value of the game target is decreased and the corresponding first display data is created. Further, the number of occurrences of the first event is counted, and the winning probability of occurrence of the second event is set based on the number of occurrences of the first event and the parameter value. Then, based on the lottery according to the winning probability, the presence or absence of the second event is determined, the parameter value is decreased, the corresponding second display data is created, and the first display data and the second display data are stored in the terminal. Send.

JP 2013-128603 A (first page, FIG. 1)

Glee Co., Ltd., “Flow to App Release: Web App (Feature Phone / Smart Phone / Tablet)”, [online], Glee Co., Ltd. homepage, [January 10, 2014 search], Internet <https: // docs.developer.gree.net/en/startedguide/webapp>

  However, if game content consisting of a plurality of rounds is transmitted at once, it takes time to transmit the game content, and the user waits until the game starts. In particular, in order to increase interest, there are cases where various contents are provided, and the capacity of the contents tends to increase. On the other hand, if game content is transmitted for each round, smooth game progress may be hindered.

The present invention has been made in view of the above problems, its object is to provide a user terminal and a game providing program that provides game content by web applications efficiently.

(1) the user terminal to solve the above problems is a user terminal end which is connected to the game providing computer having a storage unit for managing the configured game from a plurality of rounds, from the game providing computer, a small Batch When the game screen data for the number of rounds are received together, and after determining whether or not the game is defeated at the end of the round, if it is determined that the game is not defeated, If it is determined that there are remaining rounds, the next round processing is performed, and it is determined that there is no remaining rounds. If you decide that you want to continue the game after sending end data and determining that there are no remaining rounds, To send over data to the game provides computer, from the game provides computer, from the next round of the end of the round, to receive together a game screen data of small-conclusion a few minutes round. Thereby, it is possible to realize efficient game development while reducing the waiting time until the game starts.

(2 ) When clearing of rounds corresponding to the number of rounds is detected, it is preferable to output screen data presenting midway result information received from the game providing computer. Thereby, it can be grasped that the battle of the number of rounds is cleared.

(3 ) It is preferable to output screen data for confirming a user's intention to continue the battle when clearing of rounds corresponding to the number of rounds is detected. Thereby, a battle can be retired on the way.

(4 ) When clearing of rounds corresponding to the number of sub-rounds is detected, it is preferable to output screen data notifying the user of the number of rounds reached. Thereby, the number of rounds cleared can be grasped.

(5 ) When clearing the number of rounds corresponding to the number of rounds is detected, screen data notifying the progress of the game of the related user of the user who uses the user terminal is received and output from the game providing computer It is preferable to do. Thereby, it is possible to grasp the progress of related users.

(6 ) It is preferable that the number of rounds is determined based on a terminal attribute of the user terminal. Thereby, the game screen data can be efficiently transmitted in consideration of the situation of the user terminal.

(7 ) It is preferable that the number of rounds is determined based on a user attribute of a user who uses the user terminal. Thereby, it is possible to efficiently transmit game screen data in consideration of the user situation.

(8 ) It is preferable that the number of rounds is determined based on the number of rounds that can be transmitted in a batch of strongly related rounds based on the relevance of newly transmitted rounds. Thereby, it is possible to efficiently transmit game screen data in consideration of game development.

(9) the small-conclusion number of rounds in the game, collectively or less the upper limit of the small Batch number of rounds to be transmitted to the user terminal, preferably Rukoto is determined by the round desired number specified in the user terminal . Thereby, the game screen data can be efficiently transmitted in consideration of the user's situation and wishes.

  ADVANTAGE OF THE INVENTION According to this invention, the game content by a web application can be provided efficiently.

The system schematic of this embodiment. Explanatory drawing of the process sequence of this embodiment. Explanatory drawing of the process sequence of this embodiment. Explanatory drawing of the screen of this embodiment. Explanatory drawing of the process sequence of other embodiment. Explanatory drawing of the process sequence of other embodiment. Explanatory drawing of the process sequence of other embodiment. Explanatory drawing of the process sequence of other embodiment.

Hereinafter, an embodiment of a game providing method will be described with reference to FIGS. This embodiment assumes the case where a game content is provided with respect to a user.
As shown in FIG. 1, in this embodiment, a user terminal 10 and a management server 20 (game providing computer) connected via a network such as the Internet are used.

  The user terminal 10 is a computer terminal (information processing terminal such as a smartphone) used by a user who plays a game. The user terminal 10 includes a browser 11 (program) for using game content provided from the management server 20. The browser 11 stores the screen data acquired from the management server 20 in the browser memory and outputs it to the display.

  As shown in FIG. 4, in this embodiment, an event TOP screen 501, a battle TOP screen 502, a party selection screen 503, a load screen 504, and a battle screen 505 are used. Further, an intermediate result screen 510, a defeat result screen 511, and an all clear screen 512 are used.

The event TOP screen 501 is a screen for introducing events related to this game.
The battle TOP screen 502 is an initial screen that is displayed before the game is started.
The party selection screen 503 is a screen for specifying a character to be a friend, an item to be used, or the like when performing a battle with the opponent (enemy). Here, a predetermined number of characters and items are selected from candidate items such as a plurality of characters and items. Furthermore, it is possible to specify other users participating in the game as friends when performing a battle with the opponent (enemy).

The load screen 504 is a standby screen set to be displayed during downloading of battle screen data.
The battle screen 505 is a screen displayed when a battle is performed. In the present embodiment, a plurality of round battles are performed, and a different battle screen 505 is used for each round.

  The intermediate result screen 510 is a screen that is set to present that a predetermined number of round battles have been won (intermediate result information). Further, the intermediate result screen 510 includes a display indicating the number of rounds reached and a display (selectable icon) for confirming the intention to continue the battle.

The defeat result screen 511 is a screen set to be displayed when a battle is defeated.
The all clear screen 512 is a screen set to be displayed when all rounds are cleared.

  The management server 20 is a server computer that provides various game contents to the user terminal 10. In this embodiment, the case where the battle game which consists of a some round is provided with respect to a user is assumed. This game content is described in HTML5 and is executed on the browser.

  As shown in FIG. 1, the management server 20 includes a control unit 21, a user information storage unit 22, a game information storage unit 23, a content storage unit 24, and an event information storage unit 25 including a CPU, a RAM, and a ROM. The control unit 21 functions as a login management unit 211 and a game management unit 212 by executing the game providing program.

  The login management unit 211 executes a process for managing users who use the game. In the present embodiment, when login authentication can be performed by the login management unit 211, the session with the user terminal 10 is taken over by the game management unit 212.

  The game management unit 212 executes a process of transmitting game content to each user terminal 10. The game management unit 212 holds game status information in a temporary memory. This game situation information is registered when the user starts the game, and is deleted when the game is ended. This game status information includes information regarding the user ID, game ID, party, and progress status.

In the user ID data area, data relating to an identifier for identifying a user who is using the game is recorded.
In the game ID data area, data relating to an identifier for identifying the game being used by the user is recorded.

In the party data area, data relating to an identifier for specifying a character to be a selected friend, an item to be used, or the like in this game is recorded. Furthermore, the data regarding the other user (friend) selected as a friend when this user battles with the other party (enemy) is recorded.
In the progress status data area, data related to the progress status in this game is recorded.

  The user information storage unit 22 stores user information regarding users who use the game. This user information is recorded when the user is registered. In the user information, data relating to a user ID, a login password, a use game, and user relevance is recorded.

In the user ID data area, data relating to an identifier for identifying each user is recorded.
In the login password data area, data for performing authentication upon login to the management server 20 is recorded.

  In the use game data area, data relating to an identifier (game ID) for specifying a game used by the user is recorded. The game title can be specified by the game ID.

  In the user relevance data area, data relating to relevance to other users (for example, a friend who belongs to the same group, a friend in the game, or a friend in a specific battle) is recorded. In this data area, an identifier for identifying a group to which another user belongs, an identifier for identifying another user who is a friend in the game, and another user selected as a friend in a specific battle Data relating to the identifier is recorded.

  In the game information storage unit 23, game management information related to the game used by the user is recorded. This game management information is recorded when the user registers the use of the game, and is updated when the game is played. In the game management information, data relating to the user ID, the game used, and the situation is recorded.

Data relating to an identifier for identifying each user is recorded in the user ID data area.
Data relating to an identifier for specifying each game used by the user is recorded in the use game data area.

  In the situation data area, data relating to the progress of the game for this user is recorded. In this data area, for example, information about items, abilities, arrival rounds, etc. held by the user are recorded.

  The content storage unit 24 stores content information related to the game screen provided to the user terminal 10. This content information is recorded when a game to be provided to the user is registered. In the content information, a game ID, a screen ID, and data related to the game screen are recorded.

Data relating to an identifier for identifying each game is recorded in the game ID data area.
In the screen ID data area, data relating to an identifier for specifying a screen used in this game is recorded. With this screen ID, the event TOP screen 501 to the all clear screen 512 shown in FIG. 4 can be specified. Furthermore, the battle screen 505 of each round can be specified.

  In the game screen data area, data related to the screen used in this round is recorded. In the present embodiment, screen data for displaying the event TOP screen 501 to the all clear screen 512 shown in FIG. 4 on the browser is recorded.

  In the event information storage unit 25, event information related to events of each game is recorded. This event information is recorded when an event is registered. In the event information, data related to the game ID and event contents is recorded.

Data relating to an identifier for identifying each game is recorded in the game ID data area.
In the event content data area, data relating to the content of the event held in each game is recorded.

(Game provision processing)
The game providing process will be described with reference to FIG.
Here, first, the control unit 21 of the management server 20 executes a login process (step S1-1). Specifically, when playing a game, the user terminal 10 is used to access the management server 20 that manages the game desired to be used. In this case, the login management unit 211 of the control unit 21 transmits login screen data to the display of the user terminal 10. In this case, the user terminal 10 executes a login screen display process (step S2-1). Specifically, the browser 11 of the user terminal 10 outputs a login screen. And the login management part 211 acquires the user ID and login password which were input into this login screen. Then, the login management unit 211 completes the login authentication when the user ID and the login password are registered in the user information storage unit 22 for the game ID desired to be obtained acquired from the user terminal 10.

  Next, the control unit 21 of the management server 20 executes event TOP screen data transmission processing (step S1-2). Specifically, the game management unit 212 of the control unit 21 acquires event information in which the desired game ID is recorded from the event information storage unit 25. Next, the game management unit 212 generates event TOP screen data including the acquired event information. Then, the game management unit 212 transmits event TOP screen data to the user terminal 10. In this case, the user terminal 10 executes an event TOP screen display process (step S2-2). Specifically, the browser 11 of the user terminal 10 outputs the event TOP screen acquired from the management server 20 to the display. The user confirms the contents displayed on the event TOP screen. And when performing a battle, a battle start icon is selected. In this case, the browser 11 transmits a battle start notification to the management server 20.

  Next, the control part 21 of the management server 20 performs the transmission process of battle TOP screen data (step S1-3). Specifically, the game management unit 212 of the control unit 21 generates game situation information associated with the user ID and stores it in the temporary memory. And the game management part 212 transmits battle TOP screen data. In this case, the user terminal 10 performs a battle TOP screen display process (step S2-3). Specifically, the browser 11 of the user terminal 10 outputs the battle TOP screen acquired from the management server 20 to the display.

  Next, the control part 21 of the management server 20 performs the transmission process of party selection screen data (step S1-4). Specifically, the game management unit 212 of the control unit 21 outputs a plurality of characters and candidates for items to be used. Here, another user who uses this game is specified in the game information storage unit 23. And the game management part 212 produces | generates the party selection screen data which displayed the party information which consists of the character who becomes a friend, the candidate of the item to be used, and a user, and transmits to the user terminal 10. In this case, the user terminal 10 executes party selection screen display processing (step S2-4). Specifically, the browser 11 of the user terminal 10 outputs the party selection screen acquired from the management server 20. And a user selects a desired fellow character, the item to be used, and another user according to hope, and comprises a party. In this case, the browser 11 transmits the selected party information to the management server 20.

  Next, the control part 21 of the management server 20 performs a party registration process (step S1-5). Specifically, the game management unit 212 of the control unit 21 registers the selected party information in the temporary memory in association with the user ID and the game ID in the game situation information.

Next, the control part 21 of the management server 20 performs a battle management process (step S1-6). Specifically, the game management unit 212 of the control unit 21 specifies the game progress status in the user terminal 10. Here, when the battle screen data is transmitted for the first time, the game management unit 212 collectively transmits the screen data of the load screen 504 and the battle screen 505 for the number of rounds from the first round to the user terminal 10. On the other hand, when the progress data is acquired from the user terminal 10, the game management unit 212 collects the screen data of the battle screen 505 for the number of rounds from the next round of the end round and transmits it to the user terminal 10. .
In this case, as will be described later, the user terminal 10 performs a battle process (step S2-5).

  Further, in the battle management process (step S1-6), when it is detected that a predetermined number of rounds have been cleared, the control unit 21 of the management server 20 sends the screen data of the midway result screen 510 to the user terminal 10. Send. In addition, the screen data of the intermediate result screen 510 may be transmitted to the user terminal 10 in advance, and the browser 11 may output the detection when a predetermined number of round battles are cleared.

  In addition, the control unit 21 of the management server 20 executes progress data storage processing. Specifically, when battle progress data is acquired from the user terminal 10, the game management unit 212 of the control unit 21 updates the game status information in the temporary memory. Further, the game management unit 212 updates the situation recorded in the game management information in the game information storage unit 23.

  Moreover, the control part 21 of the management server 20 performs the confirmation process of another user condition. Specifically, the game management unit 212 of the control unit 21 specifies the status of other users belonging to the same group as this user in the temporary memory. Then, the game management unit 212 includes the status information of the identified other users in the load screen 504 and transmits it to the user terminal 10.

  Next, the control part 21 of the management server 20 performs the determination process about whether it is the battle end (step S1-7). Here, the determination is made based on the end data and progress data acquired from the user terminal 10.

  When it is determined that the battle is not ended by acquiring the progress data (in the case of “NO” in step S1-7), the control unit 21 of the management server 20 returns to the battle management process (step S1-6), and newly Send battle screen data.

  On the other hand, when it is determined that the battle has ended by acquiring the end data (in the case of “YES” in step S1-7), the control unit 21 of the management server 20 executes a transmission process of the result display screen data (step S1-7). S1-8). Specifically, the game management unit 212 of the control unit 21 specifies the progress status (such as the end round) recorded in the temporary memory. Further, the game management unit 212 updates the situation recorded in the game management information in the game information storage unit 23. And the game management part 212 produces | generates the result display screen data including the information regarding a progress condition. Here, either the defeat result screen 511 or the all clear screen 512 is transmitted to the user terminal 10 as the result display screen data. In this case, the user terminal 10 performs a result display process (step S2-6). Specifically, the browser 11 of the user terminal 10 outputs a result display screen acquired from the management server 20.

  Here, when the defeat or retirement of the battle is detected, the game management unit 212 transmits the screen data of the defeat result screen 511 to the user terminal 10. When all the rounds are detected to be cleared, the game management unit 212 transmits the screen data of the all clear screen 512 to the user terminal 10.

(Battle processing)
Next, the battle process (step S2-5) in the user terminal 10 is demonstrated using FIG. In the present embodiment, when the user's victory continues in a battle up to a predetermined number of rounds (for example, 3 rounds), the control unit 21 of the management server 20 determines the new predetermined number of rounds after the end of the predetermined number of rounds. Send battle screen data for (number of rounds). Note that transmission of battle screen data for a new predetermined number of rounds (number of rounds) is performed only when the user selects to continue the battle process.

  Here, the user terminal 10 executes a download process (step S3-1). Specifically, the browser 11 of the user terminal 10 downloads game battle screen data from the management server 20. In this case, the browser 11 displays a load screen 504 including a message indicating that a new round of battle screen data is being downloaded. Further, when the progress status of another user belonging to the same group as the user or the friend status in the game is acquired from the management server 20, the browser 11 displays the progress status on the load screen 504.

  And the user terminal 10 which complete | finished download of battle screen data performs 1 round process in the predetermined number of rounds which downloaded (step S3-2). Specifically, the browser 11 of the user terminal 10 temporarily stores the battle screen data acquired from the management server 20 in the browser memory. Next, the battle screen 505 of the round which is not used for the battle (the first round immediately after downloading) is output. And the browser 11 performs a battle process based on the information contained in this battle screen 505. FIG. In this case, the used information is recorded for the round in which the battle was performed.

  Next, the user terminal 10 executes progress data storage processing (step S3-3). Specifically, the browser 11 of the user terminal 10 temporarily stores the battle progress information in this round in the browser memory in the user terminal 10.

  When the end of the battle in this round is detected, the user terminal 10 executes a determination process as to whether or not it is a defeat (step S3-4). Specifically, the browser 11 of the user terminal 10 determines the battle outcome in this round based on the progress information.

  When it is determined that the user is defeated (in the case of “YES” in step S3-4), the user terminal 10 executes an end data upload process (step S3-10). Specifically, the browser 11 of the user terminal 10 transmits end data to the management server 20. The end data includes defeat data indicating that the user has been defeated and result information (for example, acquired items) of the battle.

  On the other hand, when it is determined that the user has won and is not defeated (in the case of “NO” in step S3-4), the user terminal 10 performs a determination process as to whether or not there is a remaining round in the predetermined number of downloaded rounds. Execute (Step S3-5). Specifically, the browser 11 of the user terminal 10 confirms whether or not a round that is not used in the battle remains in the round of the battle screen temporarily stored in the browser memory.

When it is determined that there is a remaining round that is not used in the downloaded predetermined number of rounds (in the case of “YES” in step S3-5), the user terminal 10 executes the specifying process of the next round (step S3- 6). Specifically, the browser 11 of the user terminal 10 specifies battle screen data for the next round after the end round in the browser memory.
And the user terminal 10 returns to 1 round process (step S3-2).

  On the other hand, when all the downloaded rounds (predetermined number of rounds) are battled and it is determined that there are no remaining rounds that are not used (in the case of “NO” in step S3-5), the user terminal 10 A screen display process is executed (step S3-7). Specifically, the browser 11 of the user terminal 10 notifies the management server 20 about victory (round clear), and outputs a midway result screen 510 displaying a victory message. Here, an intermediate result screen 510 includes an icon for selecting whether to retire or continue the game.

  Next, the user terminal 10 performs a determination process as to whether or not the game is to be continued (step S3-8). Specifically, the browser 11 of the user terminal 10 determines whether or not it is necessary to continue the game based on the icon selected on the midway result screen 510.

  When the retire icon is selected on the midway result screen 510 and it is determined that the game is not continued (“NO” in step S3-8), the user terminal 10 executes an end data upload process (step S3-10). ). Specifically, the browser 11 of the user terminal 10 transmits end data to the management server 20. The end data includes retire data indicating that the user has retired and result information (for example, acquired items) of the round.

  On the other hand, when the continuation icon is selected on the midway result screen 510 and it is determined that the game is to be continued (in the case of “YES” in step S3-8), the user terminal 10 executes progress data upload processing (step S3-9). ). Specifically, the browser 11 of the user terminal 10 transmits progress data regarding a predetermined number of completed rounds to the management server 20. The progress data includes data related to the end round ended in the user terminal 10 and result information (for example, acquired items) of the round. Then, the user terminal 10 returns to the download process (Step S3-1).

According to the above embodiment, the following effects can be obtained.
(1) In the said embodiment, the control part 21 of the management server 20 performs a battle management process (step S1-6). Specifically, the game management unit 212 of the control unit 21 collects the battle screen data of the number of rounds and sends it to the user terminal 10. When the battle screen data of all the rounds are transmitted together, the waiting time until the transmission is completed becomes longer. Further, when the user loses, the battle screen data of the subsequent round is not used and is wasted. On the other hand, when the battle screen data is transmitted for each round, it is necessary to wait until the battle of the next round starts after the battle ends. By transmitting battle screen data for each number of rounds, battles for the number of rounds can be continuously performed. Moreover, since the battle screen 505 which changes with rounds can be provided, a user's interest can be maintained.

  (2) In the above embodiment, the user terminal 10 executes a download process (step S3-1). In this case, the browser 11 displays a load screen 504 including a message indicating that a new round of battle screen data is being downloaded. Thereby, the user can grasp the download situation.

  Furthermore, when the progress status of another user who configures the party is acquired from the management server 20, the browser 11 displays the progress status on the load screen. Thereby, it is possible to grasp the status of other users by using the time until the download is completed.

  (3) In the above embodiment, the user terminal 10 executes a midway result screen display process (step S3-7). Here, an intermediate result screen 510 includes an icon for selecting whether to retire or continue the game. Thereby, even if it is a case where it is not defeated, a game can be interrupted on the way.

  (4) In the above embodiment, a determination process is performed as to whether there is a remaining round in the downloaded round (step S3-5). When it is determined that there is a remaining round that is not used (in the case of “YES” in Step S3-5), the user terminal 10 executes the next round specifying process (Step S3-6). Thereby, a game can be continued using the battle screen data accumulate | stored in browser memory.

  On the other hand, when there is no remaining round that is not used and the game is continued, the user terminal 10 executes progress data upload processing (step S3-9). Specifically, the browser 11 of the user terminal 10 transmits progress data to the management server 20. Thereby, the battle screen data of a new round can be acquired from the management server 20.

In addition, you may change the said embodiment as follows.
In the above embodiment, the management server 20 collectively transmits battle screen data of a predetermined number of rounds to the user terminal 10, but the number of rounds is limited to a fixed value. is not. For example, you may make it change the number of round rounds transmitted collectively according to a terminal attribute. In this case, the management server 20 holds the terminal attribute table. In this terminal attribute table, the number of rounds to be transmitted collectively is recorded corresponding to the terminal attribute. In this terminal attribute table, the number of rounds in consideration of usability (the waiting time until the game starts) is recorded in the terminal situation. For example, when the information processing speed and the communication speed in the user terminal 10 are fast, a large number of rounds is set. And the control part 21 of the management server 20 performs a round number determination process before transmission of battle screen data.

Here, the summary round number determination process will be described with reference to FIG.
First, the control unit 21 of the management server 20 executes a terminal attribute specifying process for the user terminal (step S4-1). Specifically, the game management unit 212 of the control unit 21 acquires attribute information via the browser of the user terminal 10. As this attribute information, for example, OS version, browser type, terminal type, communication environment, and the like can be used.

Next, the control part 21 of the management server 20 performs the specific process of the number of rounds based on the terminal attribute (step S4-2). Specifically, the game management unit 212 of the control unit 21 determines the number of rounds using the terminal attribute table.
Thereby, a plurality of battle screen data can be transmitted collectively considering the usability of the game user.

  In the above embodiment, the management server 20 collectively transmits battle screen data of a predetermined number of rounds to the user terminal 10, but the number of rounds is limited to a fixed value. is not. For example, you may make it change the number of round rounds transmitted collectively according to a user attribute. In this case, the management server 20 holds the user attribute table. In this user attribute table, the number of rounds to be collectively downloaded is recorded corresponding to the user attribute. For example, when the number of game uses recorded in the game information storage unit 23 is large or when the skill level is high, a large number of rounds is set. And the control part 21 of the management server 20 performs a round number determination process before transmission of battle screen data.

Here, the summary round number determination process will be described with reference to FIG.
First, the control unit 21 of the management server 20 executes a user attribute specifying process (step S5-1). Specifically, the game management unit 212 of the control unit 21 acquires user attribute information in the game information storage unit 23. As this attribute information, for example, OS version, browser type, terminal type, communication environment, and the like can be used.

Next, the control unit 21 of the management server 20 executes a process for specifying the number of rounds based on the user attribute (step S5-2). Specifically, the game management unit 212 of the control unit 21 determines the number of rounds using the user attribute table.
Thereby, considering a user, a plurality of battle screen data can be transmitted collectively.

  Here, it is also possible to set an upper limit on the number of rounds that can be transmitted according to the terminal attribute. In this case, the number of rounds according to the user attribute can be determined below the upper limit of the number of rounds.

  In the above embodiment, the management server 20 collectively transmits battle screen data of a predetermined number of rounds to the user terminal 10, but the number of rounds is limited to a fixed value. is not. For example, in each round, the number of summary rounds to be transmitted together may be changed according to the relationship between the previous and next rounds. In this case, relationship information for each round is recorded in the content storage unit 24. In this relationship information, information for identifying rounds that should be transmitted together and rounds that can be divided and transmitted is recorded. And the control part 21 of the management server 20 performs a round number determination process before transmission of battle screen data.

Here, the summary round number determination process will be described with reference to FIG.
First, the control unit 21 of the management server 20 executes relevance identification processing for the next round (step S6-1). Specifically, the game management unit 212 of the control unit 21 specifies a predetermined number of battle screen data to be transmitted. Next, the game management unit 212 acquires relevance information between the last round of the battle screen 505 and the next round. Here, when the relevance is high, the next round is added as a transmission target. Then, the next round is identified sequentially, and the addition of the highly relevant field round is repeated.

Next, the control unit 21 of the management server 20 executes a process for specifying the number of rounds based on the round content (step S6-2). Specifically, the game management unit 212 of the control unit 21 specifies the number of rounds until a less relevant round is detected as the number of rounds.
Thereby, rounds with high relevance can be transmitted together and used continuously in the user terminal 10.

  In the above embodiment, when playing a game, the management server 20 collectively transmits battle screen data of a predetermined number of rounds to the user terminal 10. The number of rounds is not limited to a fixed value. For example, the number of rounds (the number of desired rounds) may be determined according to the user's desire. In this case, the game management unit 212 holds a downloadable round upper limit value according to the type of game. And the control part 21 of the management server 20 performs a round number determination process before transmission of battle screen data.

Here, the summary round number determination process will be described with reference to FIG.
First, the control unit 21 of the management server 20 executes an upper limit determination process (step S7-1). Specifically, the game management unit 212 of the control unit 21 specifies an upper limit value of the number of batch rounds that can be downloaded together according to a game desired to be used.

  Next, the control unit 21 of the management server 20 executes a required expected time calculation process (step S7-2). Specifically, the game management unit 212 of the control unit 21 calculates the time required for downloading each round number up to the upper limit value according to the terminal attribute.

  Next, the control unit 21 of the management server 20 executes acquisition processing for the desired number of rounds equal to or less than the upper limit value from the user terminal 10 (step S7-3). Specifically, the game management unit 212 of the control unit 21 outputs a round number determination screen to the user terminal 10. This round number determination screen includes a setting field for inputting the number of rounds to be downloaded together. In this setting field, the number of rounds up to the upper limit value can be designated. Further, the expected number of download times for each round number up to the upper limit value is displayed on the round number determination screen. The expected game time is calculated by the game management unit 212 based on the battle screen data capacity and terminal attributes (communication environment, etc.). Then, the user sets a desired number of rounds in the setting field of the round number determination screen. In this case, the game management unit 212 performs batch download using the number of rounds entered in the setting field.

  -In above-mentioned embodiment, when it determines with there being no remaining round in the downloaded round (in the case of "NO" in step S3-5), the user terminal 10 performs an intermediate result screen display process (step S3-7). . Here, the output timing of the intermediate result screen 510 is not limited to when a predetermined number of round battles are won. For example, it may be displayed at the time of winning each round.

  In the above embodiment, the intermediate result screen 510 includes icons for confirming the intermediate result information, the number of rounds reached, and the intention to continue the battle. The load screen 504 can also include a display for confirming midway result information, the number of rounds reached, and the intention to continue the battle.

  DESCRIPTION OF SYMBOLS 10 ... User terminal, 20 ... Management server, 21 ... Control part, 211 ... Login management part, 212 ... Game management part, 22 ... User information storage part, 23 ... Game information storage part, 24 ... Content storage part, 25 ... Event Information storage unit.

Claims (10)

A user terminal end which is connected to a game providing a computer having a storage unit for managing the gaming composed of a plurality of rounds,
From the game providing computer, the game screen data of rounds for the number of rounds is received together,
At the end of the round, after determining whether or not the game is defeated, if it is determined that the game is not defeated, the game screen data received together performs a process for determining whether there is a remaining round.
If it is determined that there are remaining rounds, the next round process is performed,
After determining that there are no remaining rounds, if it is determined that there is no intention to continue the game, end data is transmitted,
After determining that there are no remaining rounds, if it is determined that there is an intention to continue the game, progress data is transmitted to the game providing computer,
A user terminal that collectively receives game screen data for the number of sub-rounds from the next round after the end round from the game providing computer . 2. The user terminal according to claim 1, wherein screen data presenting midway result information received from the game providing computer is output when clearing of rounds corresponding to the number of rounds is detected. 3. The user terminal according to claim 1, wherein screen data for confirming a user's intention to continue the battle is output when clearing of rounds corresponding to the number of rounds is detected. The user terminal according to any one of claims 1 to 3, wherein screen data for notifying a user of the number of rounds reached is output when clearing of rounds corresponding to the number of rounds is detected. When clearing the number of rounds corresponding to the number of rounds is detected, receiving and outputting screen data notifying the progress of the game of the related user of the user who uses the user terminal from the game providing computer. Yu according to any one of claims 1 to 4, characterized
User terminal . The user terminal according to claim 1, wherein the number of rounds is determined based on a terminal attribute of the user terminal . The user terminal according to claim 1, wherein the number of rounds is determined based on a user attribute of a user who uses the user terminal . The number of rounds is determined based on the number of rounds that can be transmitted in a batch of strongly related rounds based on the relevance of newly transmitted rounds. The user terminal according to item. The small Batch number of rounds in the game, collectively or less the upper limit of the small Batch number of rounds to be transmitted to the user terminal, wherein, wherein Rukoto determined by the round desired number specified in the user terminal Item 9. The user terminal according to any one of Items 1 to 8. A program for providing a game using a user terminal connected to a game providing computer having a storage unit for managing a game composed of a plurality of rounds,
The user terminal
From the game providing computer, the game screen data of rounds for the number of rounds is received together,
At the end of the round, after determining whether or not the game is defeated, if it is determined that the game is not defeated, the game screen data received together performs a process for determining whether there is a remaining round.
If it is determined that there are remaining rounds, the next round process is performed,
After determining that there are no remaining rounds, if it is determined that there is no intention to continue the game, end data is transmitted,
After determining that there are no remaining rounds, if it is determined that there is an intention to continue the game, progress data is transmitted to the game providing computer,
A game providing program that causes the game providing computer to function as means for collectively receiving game screen data for the number of sub-rounds from the next round after the end round.

Images