U.S. Pat. No. 8,608,572

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The invention will be described herein with reference to illustrative embodiments. Those skilled in the art will recognize that many alternative embodiments can be accomplished using the teachings of the present invention and that the invention is not limited to the embodiments illustrated for explanatory purposes.

It is to be noted that, in the explanation of the drawings, the same components are given the same reference numerals, and explanations are not repeated.

(Structure)

FIG. 1is a block diagram showing a structure of an example of a system of an embodiment.

The system shown inFIG. 1includes plural terminal devices1which belong to players (users), respectively, access points2such as a mobile base station, a Wi-Fi station or the like, a network3such as the INTERNET or the like, and a social game processing server apparatus4. The social game processing server apparatus4controls processing of a social game (social network game) in which plural players play a game via the network3.

FIG. 2is a block diagram showing an example of a hardware structure of the terminal device1. The terminal device1may be a smart phone, a mobile phone or the like.

The terminal device1includes a power source system101, a main system102, a storing unit106, an external port107, a high frequency circuit108, an antenna109, an audio circuit110, a speaker111, a microphone112, a proximity sensor113, an I/O sub system114, a touch panel display system118, an optical sensor119and an input unit120. The main system102includes a processor103, a memory controller104and a peripheral interface105. The I/O sub system114includes a display controller115, an optical sensor controller116, and an input controller117.

FIG. 3is a block diagram showing an example of a hardware structure of the social game processing server apparatus4.

The social game processing server apparatus4includes a Central Processing Unit (CPU)402, a Read Only Memory (ROM)403, a Random Access Memory (RAM)404, a non-Volatile Random Access Memory (NVRAM)405and an Interface (I/F)406connected to a system bus401, and an Input/Output Device (I/O)407such as a keyboard, a mouse, a monitor, a Compact Disk/Digital Versatile Disk (CD/DVD) drive or the like, a Hard Disk Drive (HDD)408, and a Network Interface Card (NIC)409connected to the I/F406, and the like.

FIG. 4is a block diagram showing an example of a functional structure of the terminal device1and the social game processing server apparatus4.

InFIG. 4, the terminal device1includes a player operation input unit11, a game logic processing unit12, a server accessing unit13, and a screen display unit14.

The player operation input unit11has a function to input (accept) an operation of a player (user) of the terminal device1.

The game logic processing unit12has a function to process a game by transitioning screens displayed by the screen display unit14in accordance with the operation by the player accepted via the player operation input unit11.

The server accessing unit13has a function to communicate with the social game processing server apparatus4. Specifically, the server accessing unit13sends a request to the social game processing server apparatus4when it is necessary to access the social game processing server apparatus4in the processing of the game logic processing unit12. Then, the server accessing unit13receives a processed result or the like as a response from the social game processing server apparatus4. Here, the request includes a request of updating and a request of referring to data. The request of updating is a request of processing an operation including updating player information. The request of referring to data is a request of processing an operation including referring to the player information.

The screen display unit14has a function to display screens on the touch panel display system118under control of the game logic processing unit12.

The social game processing server apparatus4includes a request processing unit41, a player management unit42, a player information database43, a quest/event management unit44, and a quest/event information storing unit45.

The request processing unit41has a function to receive a request from the terminal device1and process necessary operations. The request processing unit41further has a function to send the processed result of the request to the terminal device1as a response.

For the request of updating, the request processing unit41processes an operation including updating the player information, and the processed result may include the updated player information or the like. For the request of referring to data, the request processing unit41processes an operation including referring to the player information and obtaining a value of the player information. At this time, the processed result may include the obtained value of the player information. Further, the response includes screen information on which the player is to operate next, in addition to the required processed result.

The player management unit42has a function to manage various information items about all of the players participating in the game, which are stored in the player information database43. The player management unit42refers to and updates the player information in accordance with a request by the request processing unit41or the quest/event management unit44. An example of a data structure of the player information is explained later in detail.

The quest/event management unit44has a function to manage scenario information, an event management table and the like, which are stored in the quest/event information storing unit45.

The request processing unit41obtains information such as the scenario information and the event management table or the like stored in the quest/event information storing unit45based on the request received from the terminal device1. Then, the request processing unit41controls a generation of a quest (mission) or an event in accordance with a progression of the game in the terminal device1. Examples of data structures of the scenario information and the event management table are explained later in detail.

FIG. 5is a view showing an example of a data structure of the player information stored in the player information database43. The player information is an example of a “record of the plural players”.

InFIG. 5, the player information includes items (fields) such as “player ID”, “icon data”, “player name”, “team”, “status”, “specific event status” and the like.

The “player ID” is data to specify (identify) the player. The “icon data” is data to specify a displayed icon of the player. The “player name” is data indicating displayed name of the player.

The “team” is data indicating a team to which the player belongs and an opposing team to compete against for a common boss character.

The “status” is data indicating a status of the progression of the game for the player.

The “specific event status” is data of a status indicating whether a specific event is already generated (happened) for the respective player. In this embodiment, the specific event is “find a boss character”.

For the case shown inFIG. 5, the players named “aaa”, “bbb” and “ddd” belong to the same team “A” whose opposing team is “B”. Similarly, the players named “ccc”, “eee” and “fff” belong to the same team “B” whose opposing team is “A”. Further, only the player “aaa” has found the boss character among the players “aaa” to “fff”.

In other words, the player named “bbb”, for example, is associated with the players named “aaa” and “ddd” as being in the same team, and also associated with the players named “ccc”, “eee” and “fff” as being on the opposing team.

Further, each of the players is in correspondence with the “specific event status”.

As will be explained later, the event management unit44determines an event to be generated for a target player, for example, the player named “bbb”, based on a result obtained by determining whether the specific event is already generated for the players associated with the target player based on the player information stored in the player information database43.

Alternatively, the “status” may include information of the “specific event status” and in such a case, the item “specific event status” may be omitted.

FIG. 6is a view showing an example of a data structure of the scenario information stored in the quest/event information storing unit45.

InFIG. 6, the scenario information includes a status (mainly a stage) in correspondence with selectable areas (areas on a map at each of which a quest occurs). Generally, the areas are aligned in an order from easier to be conquered to harder to be conquered. First, only the areas easier to be conquered are set to be selectable.

FIG. 7is a view showing an example of a data structure of the event management table stored in the quest/event information storing unit45.

InFIG. 7, the event management table includes items (fields) such as “time zone”, “condition of specific event status (for team)”, “candidate event”, “screen number”, “weight” and the like.

The “time zone” is data for specifying a kind of time. The “time zone” includes “core time” in which many players are expected to participate in the game, “non-core time” in which the number of players participating in the game is expected to be small, “maintenance time” in which maintenance of an operating side is performed, and the like. Although not shown in the drawing, the social game processing server apparatus4may include a table in which the time (corresponding to a current time) and the time zone are in correspondence with each other.

The “condition of specific event status (for team)” is data of a condition of a status indicating whether the specific event is already generated (happened) for the players in the own team and the opposing team. As described above, as the specific event is “find a boss character” in this embodiment, the “condition of specific event status (for team)” includes “only own team found boss”, “only opposing team found boss”, “both teams not found boss”, “both teams found boss” and the like.

The “candidate event” is data for specifying a candidate event to be generated for the target player. The “candidate event” includes events such as “increasing ability”, “bonus”, “boss character” and the like.

The “screen number” is data indicating the number of screens to be displayed until the respective event occurs. Here, instead of using the word “screen number”, a word “step number” may be used provided that the screen is transferred for each of the steps of the player character. Even when the same event occurs, if the screen number is different, a different impression can be provided to the player. Thus, records of the same event with different screen numbers are differentiated in this embodiment.

The “weight” is a value which corresponds to a probability of the respective candidate event to be randomly selected by a drawing or the like.

(Operation)

FIG. 8is an example of a flowchart showing an operation of the terminal device1and the social game processing server apparatus4of the embodiment.

Here, it is assumed that the player, who is the target player, who operates the terminal device1is previously logged in to the social game processing server apparatus4so that the social game processing server apparatus4can specify the player ID of the target player.

At the terminal device1, when the player operation input unit11accepts an operation by the player to start the game, the game logic processing unit12recognizes the operation to start the game. Then, the server accessing unit13transmits the operation to start the game to the social game processing server apparatus4.

Then, at the social game processing server apparatus4, the request processing unit41recognizes the operation to start the game and starts the processing (step S101). In the following, the operation of the request processing unit41to access (update) data stored in the player information database43is performed via the player management unit42, and the operation of the request processing unit41to access (update) data stored in the quest/event information storing unit45is performed via the quest/event management unit44unless otherwise explained.

First, the request processing unit41determines whether it is the first time for the player to play the game (step S102). Specifically, the request processing unit41refers to the player information (FIG. 5) of the player information database43based on the player ID. Then, the request processing unit41can determine whether it is the first time for the player to play the game by determining whether the status of the respective player is set as an initial value.

When it is determined to be the first time for the player to play the game (YES of step S102), the request processing unit41allocates the player to one of the teams. Then, the request processing unit41sends screen information including a result of the allocation to have the terminal device1display a team allocating screen (step S103).

The allocation of the player to the team may be performed based on a predetermined rule. Alternatively, the allocation of the player to the team may be performed as follows. The request processing unit41selects a team for which the number of the players belonging to is small based on the player information stored in the player information database43. Then, the request processing unit41updates the team for the player in the player information stored in the player information database43.

The allocation of the team can be assumed as associating the target player with the other players as is explained above with reference toFIG. 5.

When the screen information including the result of the allocation is sent to the terminal device1and the server accessing unit13receives the screen information, the screen display unit14displays the team allocating screen under control of the game logic processing unit12.

Then, at the terminal device1, when the player operation input unit11accepts an operation of confirmation by the player (step S104), the server accessing unit13sends the confirmation by the player to the social game processing server apparatus4under control of the game logic processing unit12. Then, at the social game processing server apparatus4, the request processing unit41starts the subsequent processing. Here, the allocation of the team may be automatically performed at background without displaying the team allocating screen or the screen of confirmation for the player.

When it is determined that it is not the first time for the player to play the game (NO of step S102), the above operation of the allocation of the team is not performed as the player is already allocated to the team. Then, the operation previously interrupted is re-started (step S105). The re-starting of the operation is performed as follows. The request processing unit41refers to the status in the player information stored in the player information database43based on the player ID of the player and specifies the processing corresponding to the status.

After the confirmation of the allocation (step S104) or when the game is re-started (step S105), the request processing unit41controls the terminal device1to display a quest start screen from which the player is capable of selecting a desired area to play the quest (step S106).

Specifically, the request processing unit41refers to the player information stored in the player information database43based on the player ID of the player and obtains the status. Then, based on the obtained status, the request processing unit41refers to the scenario information (FIG. 6) stored in the quest/event information storing unit45and obtains the selectable areas corresponding to the status (stage). Then, the request processing unit41generates the quest start screen from the obtained selectable areas and sends the quest start screen to the terminal device1.

Then, at the terminal device1, when the server accessing unit13receives the quest start screen, the screen display unit14displays the quest start screen under control of the game logic processing unit12.

Then, when the player operation input unit11accepts a selection of the area by the player (step S107), the server accessing unit13sends the selection by the player to the social game processing server apparatus4under control of the game logic processing unit12. Then, the quest is started.

When the quest is started, the request processing unit41controls the terminal device1to display an “in-quest screen” including an image in which the player character goes through the selected area (step S108). It means that the request processing unit41sends the “in-quest screen” to the terminal device1. Then, when the server accessing unit13of the terminal device1receives the in-quest screen, the screen display unit14displays the in-quest screen under control of the game logic processing unit12.

Then, when the player operation input unit11of the terminal device1accepts an operation by the player to proceed or the like (step S109), the server accessing unit13sends the operation by the player to the social game processing server apparatus4under control of the game logic processing unit12. Then, the request processing unit41of the social game processing server apparatus4starts the subsequent processing. When the displaying of the in-quest screens continues, the above operation is repeated.

Then, the request processing unit41refers to the player information stored in the player information database43based on the player ID of the player (target player) and obtains the specific event statuses of the target player and the other players associated with the target player. At this time, the request processing unit41differentiates the other players who belong to the same team (own team) with the target player and who belong to the opposing team of the target player. Then, the request processing unit41determines the specific event status for the team of the target player (step S110). Specifically, these operations may be performed by the player management unit42and the quest/event management unit44under control of the request processing unit41.

For example, for the case shown inFIG. 5, it is assumed that the target player is the player named “bbb” and only the player named “aaa”, who belongs to the same team as the player named “bbb”, has already found the boss character. In such a case, the specific event status for team for the target player becomes “only own team found boss”. Alternatively, when it is assumed that the target player is the player named “ccc” and only the player named “aaa”, who belongs to the opposing team of the player named “bbb”, has already found the boss character, the specific event status for team for the target player becomes “only opposing team found boss”. Further, alternatively, when it is assumed that the target player is the player named “bbb” and nobody in the teams A and B has found the boss character, the specific event status for team for the target player becomes “both teams not found boss”.

Alternatively, the player information database43may include an item “specific event status for team” and the request processing unit41may update data for the “specific event status for team” every time when the specific event is generated for any of the players.

Then, the request processing unit41obtains the current time, and then refers to the table, not shown in the drawings, in which the current time and the time zone are in correspondence with each other. Then, the request processing unit41determines the time zone to which the current time belongs (step S111).

Then, the request processing unit41refers to the event management table (FIG. 7) stored in the quest/event information storing unit45. Then, the request processing unit41selects the candidate events for which the specific event status for team for the target player and the time zone determined as above meet the condition of specific event status for team and the time zone set in the event management table. Then, the request processing unit41obtains the selected candidate events and the screen numbers and the weights of the selected events, respectively, (step S112).

Then, the request processing unit41randomly selects an event to be generated for the target player in accordance with a probability which is in proportion to the obtained weights (step S113).

For example, when the specific event status for team determined as above is “only own team found boss” and the time zone determined as above is “core time”, for the case shown inFIG. 7, eight records from the upper side in the event management table meet the determined condition for the target player. In such a case, a ratio of the respective weight with respect to a total weight of the eight records, 1+35+20+10+3+15+5+10=99, is set to be a probability for each of the records. Then, the event to be generated for the target player is randomly selected.

Specifically, these operations to determine the event to be generated for the target player may be performed by the quest/event management unit44under control of the request processing unit41.

Here, as explained above, the events are differentiated when the screen number is different even when the names of the events are the same.

Here, in this embodiment, although the records in each of which the time zone is set to be “core time” are assumed, records in each of which the time zone is set to be “non-core time” or “maintenance time” may be further provided and weights may be set in accordance with an operation policy.

Referring back toFIG. 8, the request processing unit41repeats an operation in which the in-quest screens of the screen number of the determined event are displayed (step S114) and operations by the player to proceed or the like are accepted (step S115).

Thereafter, when the in-quest screens of the screen number of the determined event are displayed, the request processing unit41controls the terminal device1to display an event screen including an image of the event as determined above (step S116). In other words, the request processing unit41sends the event screen to the terminal device1. Then, when the server accessing unit13of the terminal device1receives the event screen, the screen display unit14displays the event screen under control of the game logic processing unit12.

Then, when the player operation input unit11of the terminal device1accepts an operation by the player of the event (step S117), the server accessing unit13sends the operation by the player to the social game processing server apparatus4under control of the game logic processing unit12. Then, the request processing unit41of the social game processing server apparatus4starts the subsequent processing. When the event screen is composed of plural screens, the above operation is repeated.

Thereafter, when the event ends in accordance with the operation by the player, the request processing unit41controls the terminal device1to display an event result screen including the result of the event (step S118). In other words, the request processing unit41sends the event result screen to the terminal device1. Then, when the server accessing unit13of the terminal device1receives the event result screen, the screen display unit14displays the event result screen under control of the game logic processing unit12. As the result of the event, the player character can obtain an ability such as magic power, a skill or the like, a weapon, or a reward.

Then, when the player operation input unit11of the terminal device1accepts an operation by the player of confirmation or the like (step S119), the server accessing unit13sends the confirmation by the player to the social game processing server apparatus4under control of the game logic processing unit12. Then, the request processing unit41of the social game processing server apparatus4starts the subsequent processing.

Thereafter, the request processing unit41determines whether the quest is finished (step S120). Whether the quest is finished may be determined based on whether the player character has reached the end of the area.

When it is determined that the quest is not finished (NO of step S120), the operation moves back to step S110.

When it is determined that the quest is finished (YES of step S120), the operation moves back to step S106.

Here, in the above processes, the player operating the terminal device1can stop the game before and after the operation, and can start the game from the same status when re-starting the game.

In this embodiment, the request processing unit41, the quest/event management unit44, and the player management unit42function as an event generating control unit which controls generation of a predetermined event and an event generated status management unit which manages an event generated status of each of the players.

Further, the components of the social game processing server apparatus4may not be included in a single apparatus and may be provided in plural apparatuses connected via a network or the like with each other. For example, the player information database43or the quest/event information storing unit45may be provided in a different apparatus from an apparatus including the request processing unit41, the player management unit42and the quest/event management unit44. The social game processing server apparatus4or a system including such apparatuses may be referred to as a “game processing server system”.

The individual constituents of the social game processing server apparatus4or each of the terminal devices1may be embodied by arbitrary combinations of hardware and software, typified by a CPU of an arbitrary computer, memory, a program loaded in the memory so as to embody the constituents illustrated in the drawings, storage units for storing the program such as a hard disk, and an interface for network connection. It may be understood by those skilled in the art that methods and devices for the embodiment allow various modifications.

As described above, according to the embodiment, adventurousness in generating an event can be increased so that a player does not have a tedious feeling in playing a game.

According to the embodiment, a game processing server apparatus and a game processing server system capable of increasing adventurousness in generating an event so that a player does not have a tedious feeling in playing a game can be provided.

Although a preferred embodiment of the game processing server apparatus and the game processing server system has been specifically illustrated and described, it is to be understood that minor modifications may be made therein without departing from the spirit and scope of the invention as defined by the claims.

The present invention is not limited to the specifically disclosed embodiments, and variations and modifications may be made without departing from the scope of the present invention.

The present application is based on Japanese Priority Application No. 2012-125175 filed on May 31, 2012, the entire contents of which are hereby incorporated by reference.