U.S. Pat. No. 8,460,088

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 the 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. The terminal device1may be a smart phone, a mobile phone, or the like.

FIG. 2is a block diagram showing an example of a hardware structure of the terminal device1.

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 based on screen transition information in accordance with the input operation by the player via the player operation input unit11.

The server accessing unit13has a function to send a request to the social game processing server apparatus4when it is necessary to access the social game processing server apparatus4in a course of the processing of the game logic processing unit12. Further, the server accessing unit13has a function to receive a processed result, screen transition information and the like as a response from the social game processing server apparatus4. Here, the request includes a request for updating and a request for referring to data. The request for updating is a request to perform an operation including updating player information such as “give an item to another player as a gift”, in which the player sends an obtained item to another player, or the like. Thus, with this operation, it is necessary to update the player information. The request for referring to data is a request to perform an operation including referring to the player information such as “referring to obtained items” or the like.

The screen display unit14has a function to display screens based on the screen information under control of the game logic processing unit12.

The social game processing server apparatus4includes a request processing unit41, a game parameter management unit42, a game parameter storing unit43, a player management unit44, and a player information database45.

The request processing unit41has a function to receive a request from the terminal device1, perform a corresponding process and send a processed result of the request to the terminal device1as a response. When the request processing unit41receives the request for updating, the request processing unit41performs an operation to update the player information, and sends the player information or the like which is changed by the operation as the processed result. When the request processing unit41receives the request for referring to data, the request processing unit41refers to the player information, and sends an obtained value of the player information as the processed result.

The game parameter management unit42has a function to manage game parameters, which relate to operations of a game such as a probability or the like for a reward given to a player when the player clears a mission, fights against an enemy character or the like in the game, stored in the game parameter storing unit43.

The player management unit44has a function to manage various information items about all of the players participating in the game, which are stored in the player information database45. An example of the data structure of the player information is explained later in detail.

FIG. 5is a view showing an example of a data structure of the player information stored in the player information database45.

InFIG. 5, the player information includes items (fields) such as “player ID”, “status”, “icon data”, “player name”, “friend player ID”, “attribute”, “obtained normal scroll”, “read normal scroll”, “obtained rare scroll”, “read rare scroll”, “bonding parameter data”, “letter data” and the like.

The “player ID” is data to specify (identify) the player. The “status” is data to specify a status of the player in the game. 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 “friend player ID” is data to specify the other players whom the player registers as friend players. The “attribute” is data indicating a type, selected by the player at a start of the game, of the player.

The “obtained normal scroll” is data to specify a normal (not rare) scroll (item) obtained by the player or given by the other players. When the player gives the item to the other player, the player information is updated so that the item is not registered as “obtained”. The “read normal scroll” is data to specify the normal scroll which is read after performing a predetermined operation among the obtained normal scrolls. The “obtained rare scroll” is data to specify a rare scroll obtained by the player or given by the other players. At this time as well, the player information is updated so that the item given to the other player is not registered as “obtained”. The “read rare scroll” is data to specify the rare scroll which is read after performing a predetermined operation among the obtained rare scrolls.

The “bonding parameter data” is data indicating intimacies from one player to the other players, and intimacies from the other players to the one player. The “bonding parameter data” is explained later in detail. The “letter data” is data of a new letter to be displayed when the player enters a room screen (my room screen), or when updating of the room screen is performed.

FIG. 6is a view showing an example of a data structure of the bonding parameter data.

InFIG. 6, bonding parameter data of a player (N) is exemplified. The bonding parameter data includes items (fields) such as “friend player ID”, “intimacy parameter of player (N)”, “intimacy parameter of friend player” “times of two-way intimacy” and the like.

The “friend player ID” is data to specify the other players whom the player registers as friend players. The “intimacy parameter of player (N)” is data indicating intimacy of the player (N) to the player identified by the friend player ID. The “intimacy parameter of player (N)” is calculated based on how rare and the number of items the player (N) has given (sent) to the player identified by the friend player ID. The “intimacy parameter of friend player” is data indicating intimacy of the player identified by the friend player ID to the player (N). The “intimacy parameter of friend player” is calculated based on how rare and the number of items the player identified by the friend player ID has given (sent) to the player (N).

In this embodiment, when both the values of the “intimacy parameter of player (N)” and the “intimacy parameter of friend player” become a predetermined value (for example, 100), it is assumed that a “two-way intimacy” is established between the player (N) and the player identified by the friend player ID. The “times of two-way intimacy” is data indicating the number of times the “two-way intimacy” is established. Here, when the “two-way intimacy” is established, the values of the “intimacy parameter of player (N)” and the intimacy parameter of friend player” are reset to be an initial value (0).

Although an example of the bonding parameter data in which both the “intimacy parameter of player (N)” and the “intimacy parameter of friend player” are provided for each of the players is described, the bonding parameter data may include only the “intimacy parameter of one player” for each of the other players. It is possible to obtain the “intimacy parameter of friend player” from the player (X) to the player (N) for the player (N) from the “intimacy parameter of player (X)” to the player (N) for the player (X) based on the friend player IDs of the player (N) and the player (X).

FIG. 7is a view showing an example of probabilities of candidate items appearing in a mission included in the game parameter data stored in the game parameter storing unit43.

In this embodiment, as described above, when starting the game, each of the players selects one of “tiger”, “crow”, and “shark” as an attribute (character). Then, the probabilities for scrolls (items) to appear in the mission are varied in accordance with the scrolls and the attributes.

For example, the probability to appear for the scroll “A” is 40% for the “tiger”, 0% for the “crow”, and 14% for the “shark”. It means that the scroll “A” tends to appear more for the player whose attribute is the “tiger” than the player whose attribute is the “crow” or the “shark”. Thus, the player whose attribute is the “tiger” may easily obtain the scroll “A” by himself/herself compared with the player whose attribute is the “crow” or the “shark”.

On the other hand, the probability to appear for the scroll “B” is 0% for the “tiger”, 40% for the “crow”, and 14% for the “shark”. It means that the scroll “B” tends to appear more for the player whose attribute is the “crow” than the player whose attribute is the “tiger” or the “shark”. Thus, the player whose attribute is the “crow” may easily obtain the scroll “B” by himself/herself compared with the player whose attribute is the “tiger” or the “shark”. With this mechanism, the players tend to have different items based on the attributes so that there exist other players who have obtained the item the player wants to obtain. This becomes a motivation for the players to make friends with each other.

(Operation)

FIG. 8is a flowchart showing an example of an operation when starting the game for the first time.

InFIG. 8, the screen display unit14displays an attribute selection screen under control of the game logic processing unit12(step S101).FIG. 9Ais a view showing an example of the attribute selection screen, in which attributes (characters) of a tiger (tiger clan), a shark (shark clan), and a crow (crow clan) are displayed from left side. When the player taps a desired portion (touch the screen), the attribute is tentatively selected.

Referring back toFIG. 8, when the operation of selection is accepted by the player operation input unit11(step S102), the screen display unit14displays an attribute selection confirmation screen under control of the game logic processing unit12(step S103).FIG. 9Bis a view showing an example of the attribute selection confirmation screen. When the player taps a “SELECT” button BTN1, the selection of the attribute is determined, and when the player taps an “X” button BTN2, the selection of the attribute is canceled.

Referring back toFIG. 8, when the operation of determination or cancellation is accepted by the player operation input unit11(step S104), and when it is the operation of cancellation (NO of step S105) the process goes back to step S101and the attribute selection screen is displayed again.

When the selection is determined (YES of step S105), the server accessing unit13sends a result of the selection of the attribute to the social game processing server apparatus4under control of the game logic processing unit12. Then, the request processing unit41of the social game processing server apparatus4sets the attribute of the respective player in the player information database45via the player management unit44(step S106).

FIG. 10is a flowchart showing an operation when a mission is executed.

InFIG. 10, the screen display unit14displays a mission screen under control of the game logic processing unit12(step S111).FIG. 11is a view showing an example of the mission screen, in which a “GO” button BTN3is displayed at a right lower side. When the player taps the “GO” button BTN3, the mission starts.

Referring back toFIG. 10, when the operation to start the mission is accepted by the player operation input unit11(step S112), the server accessing unit13sends a fact that the mission is started to the social game processing server apparatus4under control of the game logic processing unit12. Then, the request processing unit41of the social game processing server apparatus4randomly determines whether the mission succeeds and either of the items (the scrolls) can be obtained based on the probability to appear as shown inFIG. 7and sends the determined result to the terminal device1. When the determined result is that the mission succeeds, the obtained item is also sent (step S113).

When the mission succeeds (YES of step S114), the screen display unit14displays a mission success screen under control of the game logic processing unit12of the terminal device1(step S115).FIG. 12Ais a view showing an example of the mission success screen. When the user taps an “OK” button BTN4as a confirmation, a next screen is displayed.

Referring back toFIG. 10, when the operation of confirmation is accepted by the player operation input unit11(step S116), the screen display unit14displays an item get screen under control of the game logic processing unit12(step S117).FIG. 12Bis a view showing an example of the item get screen. When the player taps a “Next” button BTN5as a confirmation, a next screen is displayed.

Referring back toFIG. 10, when the operation of confirmation is accepted by the player operation input unit11(step S118), the series of processes to give the item is finished.

When the mission does not succeed (NO of step S114), the screen display unit14displays a mission failure screen under control of the game logic processing unit12of the terminal device1(step S119).FIG. 13is a view showing an example of the mission failure screen. When the player taps an “OK” button BTN6as a confirmation, a next screen is displayed.

Referring back toFIG. 10, when the operation of confirmation is accepted by the player operation input unit11(step S120), the series of processes is finished.

Here, when the player collects (obtains) a predetermined number (for example, 5) of different kinds of items (scrolls), and performs a predetermined operation (read a predetermined amount of the scroll and press a comprehended button or the like), the player is further given a reward (accessory or the like). At this time, the player can collect the items by the items being given by the other players, in addition to obtaining by himself/herself.

FIG. 14is a flowchart showing an operation when the player sends an item to a friend player.

InFIG. 14, the screen display unit14displays an item selection screen under control of the game logic processing unit12(step S121).FIG. 15Ashows an example of the item selection screen. In the item selection screen shown inFIG. 15A, the obtained scrolls are displayed at the lower part and “Send” buttons BTN7and BTN8are displayed for the read scrolls, respectively. When the player taps (touches) either of the buttons, the item to send to a friend player is selected.

Referring back toFIG. 14, when the player operation input unit11accepts the operation of selecting the item (step S122), the screen display unit14displays a friend player selection screen under control of the game logic processing unit12(step S123).FIG. 15Bshows an example of the friend player selection screen. In the friend player selection screen shown inFIG. 15B, the friend players are displayed at the lower part and “Send” buttons BTN9to BTN12are displayed for the players, respectively. When the player taps one of the buttons, the player can select a friend player to whom the item is sent. Here, it is configured that when sending the scroll, the player can add a message.

Further, in this embodiment, gauges (bar diagrams) G1to G4are provided for the players “fff”, “ggg”, “hhh”, and “iii”, respectively in the friend player selection screen. In each of the gauges G1to G4, a band with a length in accordance with the value of the bonding parameter indicating the intimacy of the player to the respective friend player is shown from the left end, and a band with a length in accordance with the value of the bonding parameter indicating the intimacy of the respective friend player to the player is shown from the right end. When the “two-way intimacy” is established, the bands extend to the center so that the bands are connected at the center. The gauges may not be straight lines but may be curved lines or the like. Further, instead of the gauge, a circle graph or a doughnut graph may be used.

Referring back toFIG. 14, when the operation of selection of the friend player is accepted by the player operation input unit11(step S124), the server accessing unit13sends an instruction to send the item to the selected friend player, to the social game processing server apparatus4under control of the game logic processing unit12. The request processing unit41of the social game processing server apparatus4updates the number of obtained items of the player information (reduces the number of items of the player who has sent the item, and increases the number of items of the player to whom the item is sent) (step S125).

Then, the request processing unit41updates the bonding parameter data of the player information (step S126). At this time, for example, when the normal scroll is sent, the bonding parameter from the player who has sent the item to the player to whom the item is sent is increased for 1 point, and when the rare scroll is sent, the bonding parameter from the player who has sent the item to the player to whom the item is sent is increased for 3 points.

Then, the request processing unit41determines whether one or both of the bonding parameters for the player who has sent the item and the player to whom the item is sent reach the predetermined value (for example, 100) (step S127). When one of the bonding parameters reaches the predetermined value (one-way of step S127), the request processing unit41sets letter data indicating that a “one-way intimacy” is established in the player information of both of the players (step S128).

When both of the bonding parameters reach the predetermined value (two-way in step S127), the request processing unit41sets letter data indicating that the “two-way intimacy” is established in the player information of both of the players (step S129).

FIG. 16is a flowchart showing an operation when a player room screen is displayed or when the room screen is updated.

InFIG. 16, the screen display unit14displays the room screen under control of the game logic processing unit12(step S131).FIG. 17Ais a view showing an example of the room screen.

Referring back toFIG. 16, prior to displaying the room screen, the game logic processing unit12determines whether a new letter for the player exists based on the letter data obtained from the social game processing server apparatus4(step S132). When a new letter exists (YES of step S132), the screen display unit14displays a letter cut-in message (step S133).

FIG. 17Bis a view showing an example of the room screen in which the letter cut-in message is displayed. At this time, an animation in which a white pigeon delivers a letter is played and a status indicating a letter is received is displayed for a letter button BTN13at a lower part of the screen.

Referring back toFIG. 16, when an operation of reading the letter is accepted by the player operation input unit11(step S134), the screen display unit14displays a letter content screen under control of the game logic processing unit12(step S135).FIG. 18is a view showing an example of the letter content screen in which a message indicating that a scroll is sent (as a gift), a “read” button BTN14and a “read all” button BTN15are shown. When the player taps either the “read” button BTN14or the “read all” button BTN15, the player can read the scroll.

Further, subsequently after the letter content screen shown inFIG. 18is displayed, a screen shown inFIG. 19Ais displayed when the one-way intimacy is established, and a screen shown inFIG. 19Bis displayed when the two-way intimacy is established. In both cases, a band with a length in accordance with the value of the bonding parameter indicating the intimacy of the player toward the respective friend player is shown from the left end, and a band with a length in accordance with the value of the bonding parameter indicating the intimacy of the respective friend player toward the player is shown from the right end. When the one-way intimacy is established, the respective band extends to the center, and when the “two-way intimacy” is established, both bands are connected at the center. The gauges may not be straight lines but may be curved lines or the like. Further, instead of the gauge, a circle graph or a doughnut graph may be used.

Further, subsequently after the screen shown inFIG. 19AorFIG. 19Bis displayed, a reward get screen shown inFIG. 20is displayed. It may be set that a more valuable reward is given when the two-way intimacy is established compared with a case when the one-way intimacy is established.

Referring back toFIG. 16, when the operation of the player in which the letter is read is accepted by the player operation input unit11(step S136), the series of the processes is finished.

As described above, according to the embodiment, the following advantages can be obtained.

(1) As the player can see the intimacies between the friend players which are calculated based on the past communications in each of which the respective friend player has given the item, when selecting a friend player to send an item to, it is easy for the player to recognize the friend player who has contributed to the collection of the player's items. Thus, the player can give the item to the friend player who has contributed to the collection of the player's items.

(2) As a notice is displayed or a reward is given when the one-way intimacy or the two-way intimacy is established, the communications between players in which the players send items to each other can be promoted.

According to the game processing server apparatus, the intimacies between the players are managed by the bonding parameters in accordance with the items sent or received between the players, and the statuses are appropriately displayed. Thus, the communications between players in which the players send items to each other, the players cooperate with each other, and the players have deep friendships with each other can be promoted to increase motivation to play the game.

Although a preferred embodiment of the game processing server apparatus and the terminal device 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 individual constituents of the game processing server apparatus4and the terminal device1may be embodied by arbitrary combinations of hardware and software, typified by a CPU of an arbitrary computer, a memory, a program loaded in the memory so as to embody the constituents illustrated in the drawings, a storage unit 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.

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-103454 filed on Apr. 27, 2012, the entire contents of which are hereby incorporated by reference.