JP6657330B2 - Program and server system - Google Patents

Description

  The present invention relates to a program and the like for causing a player terminal to execute a predetermined game.

  In recent video games, there is a video game in which a friendship can be set and registered between players. Then, the opponents who set the friend relationship are called "friends", "friend players", etc., and the information about the friend players is used among the players to influence each other, thereby imitating the connection between the people. We realize various game interests.

  For example, in Patent Literature 1, although the game itself is independently controlled for each player (in other words, for each player terminal), when a friend logs in at the time when a certain player logs in, the friend player A technique is disclosed in which a player character to be used appears in a game as a "friend NPC (non-player character)". According to this technology, the player is given the feeling of playing the same game with a friend player, as in a real-time multiplayer online game, regardless of whether the game is independent for each player. Can have the effect of deepening friendship.

  Various devices utilizing the mutual relationship registered between the players have become an attractive feature of the game and an important factor for achieving differentiation from others.

JP 2013-208271 A

  The present invention has been devised in view of the technical background described above, and has as its object to provide a technology that can create a new interest in a game that utilizes mutual relationships between players.

A first invention for solving the above-mentioned problem is a program for causing a player terminal to execute a predetermined game,
An interrelation setting means (for example, the processing unit 200, the game calculation unit 210, the interrelation management control unit 212, and the interrelation setting unit in FIG. 9) for setting another player for which the interrelation is set based on the operation input of the player. 216, the latest co-op relationship setting data 620 in FIG. 15, the step S66 in FIG. 19),
Providing means for providing a game object to the player (eg, the processing unit 200, the game calculation unit 210, the object providing unit 246 in FIG. 9, step S40 in FIG. 18, and step S140 in FIG. 20);
Control for communicating with the other player terminal of the other player or with the game server system of the game to provide the game object given to the player by the giving means to the other player. (For example, the processing unit 200, the game calculation unit 210, the provision control unit 252, and step S172 in FIG. 20) for providing the player terminal.

  According to the first aspect, when one of the players having a mutual relationship acquires a game object, the game object can be provided to another player.

  Regarding the game object to be provided, as a second invention, the providing means may constitute a program according to the first invention for selecting a game object to be provided and select the game object by lottery.

According to a third aspect of the present invention, there is provided a setting canceling unit for canceling the set mutual relationship when a given valid period has elapsed from the setting by the mutual relationship setting unit (for example, the processing unit 200 of FIG. Unit 210, the mutual relationship management control unit 212, the automatic setting canceling unit 224, and the function of the player terminal as steps S10 to S14 in FIG.
The provision control means constitutes a program according to the first or second invention, wherein the game object to be provided is a game object given by the giving means while the mutual relationship is set. Alternatively, the game object may be provided only during the validity period of the mutual relationship.

  According to a fourth aspect of the present invention, there is provided a consumption medium quantity storage unit (for example, the processing unit 200 in FIG. 9, the game calculation unit) that stores the number of consumption media that can be consumed in consideration of the award by the awarding unit possessed by the player. 210, the owned object management unit 248, the player terminal functions as the own player owned object list 612 in FIG. 13, and the giving means gives the game object in exchange for the consumption of the consumption medium (for example, FIG. (Step S48 of 18), the program according to any one of the first to third aspects of the present invention may be configured to cause the player to pay the added value.

Furthermore, as a fifth invention, a parameter value setting means (for example, the processing unit 200 in FIG. 9, the game calculation unit) that variably sets a parameter value (hereinafter, referred to as “parameter value”) indicating the degree of the mutual relationship. 210, co-sensitivity setting unit 223, co-sensitivity 644 in FIG. 13, step S4 in FIG. 18, step S128 in FIG. 19),
Price setting means for variably setting the price using the parameter value (for example, the processing unit 200, the game calculation unit 210, the price setting unit 250 in FIG. 9, the graph in FIG. 7, the step S44 in FIG. 18, the step S44 in FIG. 20, As step S164), a program according to a fourth aspect of the present invention for causing the player terminal to further function may be configured to pay a fee according to the degree of the mutual relationship.

  According to a sixth aspect of the present invention, the player terminal further functions as parameter value setting means for variably setting a parameter value of a parameter indicating the degree of the relationship of the mutual relationship, and the adding means sets the game object to be added to the parameter. A game object which is changed using a value (for example, step S50 in FIG. 18 and step S170 in FIG. 20), which constitutes the program according to any one of the first to fifth aspects of the invention, and which is given according to the degree of mutual relation. May be different.

According to a seventh aspect of the invention, a mutual relationship setting unit (for example, the processing unit 200, the game calculation unit 210, and the mutual relationship management control unit 212 in FIG. 9) configured to set another player based on an operation input of the own player is set. , The relation registration control unit 216, the latest co-op relation setting data 620 in FIG. 15, the step S66 in FIG. 19),
A selection event generation unit (for example, the processing unit 200, the game calculation unit 210, the question event generation control unit 218 in FIG. 9, and the question event generation control unit 218 in FIG. 11) that generates a selection event in which the player selects and operates any of a plurality of options. Question definition data 520, step S126 in FIG. 19),
Other player selection information acquisition means (for example, the processing unit 200, the game calculation unit 210, and the opponent player related data acquisition control in FIG. 9) for acquiring information on an option selected by the other player in the selection event at the player terminal of the other player. Unit 222, the opponent player profile data 630 in FIG. 13, step S2 in FIG. 18, step S68 in FIG.
The program according to the fifth or sixth invention, wherein the parameter value setting means variably sets the parameter value using an option selected by the own player and an option selected by the other player.

According to the seventh aspect, the same selection event can be experienced by the own player and the other players who have registered and set the mutual relationship, and the parameter value indicating the degree of the mutual relationship can be set based on each selection result. .
The choice of an option in a selection event depends to a large extent on the personality of the player, and the accumulation of the selection results reflects individuality. Therefore, it can be said that the similarity or difference in personality between players is reflected in the parameter value. Therefore, the game whose progress is controlled based on the parameter value naturally reflects the similarity and difference in personality between the players, and becomes a new game.

An eighth invention is a server system for executing a predetermined game on the player terminal through communication connection with a player terminal of each player,
Based on the operation input of the first player of the first player terminal and the operation input of the second player of the second player terminal, a mutual relationship is set between the first player and the second player. Interrelation setting means (for example, server processing unit 200s, game management unit 202, interrelation management control unit 212, and relation setting unit 216 in FIG. 22);
Providing means for providing a game object to the first player (for example, the server processing unit 200s, the game management unit 202, and the object providing unit 246 in FIG. 22);
Provision control means for controlling the provision of the game object provided to the first player by the provision means to the second player (for example, the processing section 200, the game management section 202, the provision control section in FIG. 22) 252).

  According to the eighth aspect, the same operation and effect as those of the first aspect can be obtained.

FIG. 1 is a diagram illustrating an example of a configuration of a game system according to a first embodiment. FIG. 2 is a front external view illustrating a configuration example of a player terminal. The figure explaining the mutual relationship registered / set by the combination of players. The figure explaining a sympathy. The figure explaining extension of a validity period. The figure explaining the specification which provides an object to an opponent player based on the object acquired within the effective period of the co-op relationship. The figure which shows the example of a relationship between the price for providing an object to an opponent player, and sympathy. The figure which shows the example of the influence which the sympathy gives to the object which appears. FIG. 3 is a functional block diagram illustrating an example of a functional configuration of a player terminal. FIG. 4 is a view showing an example of programs and data stored in a storage unit of the player terminal. The figure which shows the example of a data structure of question definition data. The figure which shows the example of a data structure of the recreation effect definition data. The figure which shows the example of the data contained in play data. The figure which shows the example of a data structure of own player profile data. The figure which shows the data structural example of the latest co-op relationship setting data. FIG. 3 is a functional block diagram illustrating a functional configuration example of a server system. The figure which shows the example of a data structure of user registration data. 13 is a flowchart for describing a flow of a process related to a mutual relationship by the player terminal 1500. The flowchart following FIG. 20 is a flowchart continued from FIG. The flowchart following FIG. FIG. 14 is a functional block diagram showing a functional configuration example of a server system in a modified example. The figure which shows the example of the program and data memorize | stored in the server storage part of the server system in a modification.

[First Embodiment]
As a first embodiment to which the present invention is applied, an example will be described in which a game in which mutual player characters can be used in a game is executed between players who have established a mutual relationship.

[Description of game system]
FIG. 1 is a diagram illustrating an example of a configuration of a game system according to the present embodiment. The game system according to the present embodiment includes a server system 1100 that can be connected to the communication line N, and player terminals 1500 (1500a, 1500b, 1500c,...) Prepared for each player 2 (2a, 2b, 2c,...). And is provided.

  The server system 1100 is a computer system including one or more server systems, storage devices, and the like, and various services for operating a membership-based community-type website such as SNS (social networking service). Can be realized.

  Specifically, the server system 1100 issues a unique account (which can be read as a handle name) to each of the users who have completed the member registration, and the server system 1100 transmits the user registration data 700 to the information on the registered users. And manage them centrally. Then, various services on the website are provided based on the user registration data 700. The game of the present embodiment is also provided and realized as part of the service to the registered user. That is, each player 2 (2a, 2b, 2c,...) Is a registered user. Each player 2 (2a, 2b, 2c,...) Accesses the server system 1100 using the respective player terminal 1500 (1500a, 1500b, 1500c,...) And enjoys the game of the present embodiment.

  The server system 1100 includes, for example, a main body device 1101, a keyboard 1106, a touch panel 1108, and a storage 1140. The main board 1101 has a control board 1150 mounted thereon. The control board 1150 includes various microprocessors such as a CPU (Central Processing Unit) 1151, a GPU (Graphics Processing Unit), a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), and various ICs such as VRAM, RAM, and ROM. A memory 1152 and a communication device 1153 are mounted.

  As functions related to the game of the present embodiment, the server system 1100 manages an account management function that performs processing related to user registration and login / logout, and manages data necessary for playing the game on the player terminal 1500 as needed. -It has a game management function for distribution.

  In the illustrated example, the server system 1100 is described as a single unit. However, the server system 1100 is equipped with a plurality of blade servers, is responsible for sharing the account management function and the game management function, and exchanges data via an internal bus. The configuration may be such that communication is possible. Alternatively, a configuration may be adopted in which a plurality of independent servers installed at distant locations are caused to perform data communication via the communication line N to function as the server system 1100 as a whole.

FIG. 2 is a front external view showing a configuration example of the player terminal 1500.
The player terminal 1500 is a computer and an electronic device (electronic device) capable of accessing the server system 1100 by connecting to the communication line N. The player terminal 1500 of the present embodiment is a device classified as a so-called smartphone, but includes a portable game device, a stationary home game device, a game controller of a stationary home game device, a business game device, a personal computer, and a tablet device. A device classified as a computer, a wearable computer, or the like may be used.

  The player terminal 1500 in this embodiment includes a direction input key 1502, a button switch 1504, a touch panel 1506 functioning as an image display device and a contact position input device, a speaker 1510, a built-in battery 1509, a microphone 1512, a control board, 1550, and a memory card reader 1542 that can read and write data from a memory card 1540 that is a computer-readable storage medium. In addition, a power button, a volume control button, and the like (not shown) are provided.

  The control board 1550 wirelessly communicates with a CPU 1551, various microprocessors such as a GPU and a DSP, various IC memories 1552 such as an ASIC, a VRAM, a RAM, and a ROM, and a mobile phone base station or a wireless LAN base station connected to the communication line N. A wireless communication module 1553 for communication is mounted. In addition, a driver circuit of the touch panel 1506, a circuit for receiving signals from the direction input key 1502 and the button switch 1504, an output amplifier circuit for outputting a sound signal to the speaker 1510, and an input signal for generating a sound signal collected by the microphone 1512 A so-called I / F circuit 1557 (interface circuit) such as a generation circuit and a signal input / output circuit for the memory card reader 1542 is mounted. The components mounted on the control board 1550 are electrically connected to each other via a bus circuit or the like, and are connected so as to be able to read and write data and transmit and receive signals.

  The control board 1550 temporarily stores the game program and data in the IC memory 1552. Then, the program is executed to execute arithmetic processing, and the respective sections of the player terminal 1500 are controlled in accordance with operation inputs from the direction input keys 1502, the button switches 1504, and the touch panel 1506 to enable game play. In the present embodiment, the player terminal 1500 is configured to acquire necessary programs and various setting data from the server system 1100, but may be configured to read from an information storage medium such as a separately obtained memory card 1540.

  Note that the communication line N means a communication path through which data communication can be performed. That is, the communication line N includes a dedicated line (dedicated cable) for direct connection, a LAN (Local Area Network) such as Ethernet (registered trademark), and a communication network such as a telephone communication network, a cable network, and the Internet. This means that the communication method may be wired or wireless.

[Explanation of interrelation]
FIG. 3 is a diagram for explaining a mutual relationship registered and set by a combination of players according to the present embodiment.
In the present embodiment, it is possible to set a mutual use contract with a valid period that enables the player character data to be used mutually between the players. This contractual relationship is a "mutual relationship" as referred to in the present specification, and can be expressed as a "co-relationship" in the sense that cooperation can make the game more enjoyable. Hereinafter, it will be referred to as “co-relationship”.

  The number of players for which the co-op relationship is set can be set as appropriate according to the content of the game, but in the present embodiment, it is assumed that the number is set and registered between the two players 2 (2a, 2b). That is, it is assumed that setting and registration can be performed only between the player and a certain player. In the following description, the player terminal 1500a will be mainly described, so that the player 2a using the terminal is referred to as “own player”, and the other player who has set a co-play relationship with the player is referred to as “opposite player” (in the example of FIG. ).

  As a setting method of the co-op relationship, a technique used for setting a pair, a team, a party, and a guild used in a known online multiplayer game or the like can be appropriately applied.

  For example, 1) the player 2a who wants to set a new co-op relationship causes the player character 4a to go to a chat room or a meeting place in a game, and finds and selects an opponent from the meeting place. 2) randomly determining an opponent by a computer; 3) obtaining a list of players (unregistered players; or player characters) not registered in the co-op relationship from the server system 1100 and selecting them with the player terminal 1500. At that time, the players (or player characters) included in the list may be all the players or may be randomly selected. Using a well-known matching technique, a player (or a player character) having a similar skill may be selected as a list by referring to parameter values related to the skill such as a player level.

  In the present embodiment, the player character 4 of the player 2 for which the co-op relationship has not been registered appears in the game as, for example, an NPC that can be selected and operated as a conversation partner, and the ID of the selected NPC is referred to as an encounter history. ". Then, when the player 2 sets a new co-op relationship, the player 2 of the player character 4 having the ID registered in the encounter history is set as a new opponent player candidate.

  In addition, mutual establishment between players may be required to establish a co-op relationship, or it may be established only by applying from one of them.

  The usage form of the player character realized by the setting of the co-op relationship may be a “multi-play type” in which each player 2 simultaneously operates each player character 4, or may appear as an auxiliary in the game of one player 2. It may be a “shorted type”. In addition, the genre of the game is not particularly limited.

  In the present embodiment, it is assumed that the latter is an action RPG (role playing game) of the borrow type. In the example of FIG. 3, the own player 2a can operate the original player character 4a set by the player 2a and the player character 4b of the opponent player 2b set in the co-op relationship in the game. Then, the player 2a plays for the purpose of defeating the enemy characters 8 one after another by making full use of the swords, bows, and magic possessed by those characters, and reaching the goal.

  Hereinafter, the original player character 4a set by the own player 2a is referred to as “own player character”, and the player character 4b of the opponent player 2b appearing in the game is referred to as “opponent player character”.

  In the present embodiment, the game can be enjoyed without setting the co-op relationship. However, when playing in a state in which a co-op relationship is set (which can also be referred to as a co-op relation registration state, a co-op relation setting state, and a co-op relation valid state), the players between the co-op relations are connected The player can proceed with the game more advantageously than when the co-op relationship is not registered according to the degree of the relationship. This is called a “co-play effect”.

  The degree of relationship is represented by a parameter value called “sympathy”, and is updated sequentially as the game progresses. The current value of the co-sensitivity is always displayed as the co-sensitivity gauge 10 in the game screen W2. The co-play effect is adjusted so that the higher the co-sensitivity, the higher the effect.

The content of the co-play effect can be appropriately set according to the content of the game and the like. Since the game of the present embodiment is an action RPG, for example, the ability of the player character 4a or the opponent player character 4b may be improved in accordance with the co-sensitivity, or the higher the co-sensitivity, the more frequently an object such as an item can be acquired in the game. It can be realized by raising the number of objects that can be acquired or increasing the degree of rarity. The frequency of occurrence and activation of the sympathetic effect may also be increased as the sensitivity increases.
The content of the object that can be obtained can be set as appropriate according to the game content. For example, items to be used for attack, defense, and recovery, characters and items as materials to be combined to enhance the player character and the item, play right on the hidden stage, lottery right with the object as a prize, and the like can be set.

FIG. 4 is a diagram illustrating the co-sensitivity in the present embodiment.
“Sympathy” in the present embodiment is the sum of “individual sympathy” managed and calculated for each player having a co-op relationship. The “individual co-sensitivity” is automatically changed according to the similarity of the profile with the opponent player and the hard work of the play within the effective period of the co-op relationship.

Specifically, profile data 20 is stored and managed for each player 2.
The profile data 20 stores personal information of the player 2 associated with each item. The contents of the items can be set as appropriate, such as address, age, gender, date of birth, place of origin, and nationality. The present embodiment further includes items related to hobbies and preferences. Items related to hobbies and preferences can be set as appropriate according to the expected age group of the player, such as favorite animals, favorite foods, dislikes, how to spend holidays, favorite movie titles, disliked music genres, etc. It is.

  The content of each item stored in the profile data 20 may be registered and set during the user registration process, for example, but in the present embodiment, it is set little by little as an event before starting game play. Specifically, as shown in the event screen W4 in FIG. 4, at the first login timing of the day, a “question event” in which the player 2 answers a question about a hobby or interest is activated, and the answer is sequentially stored in the profile data 20. register.

  Hierarchy is provided for at least some of the items related to hobbies and interests, and questions are gradually given at deeper hierarchies (hierarchies having specific contents) in the question event. For example, items related to “favorite animals” include the first level (shallow level) that allows the type of animal (major category) to be selected and the type of favorite animal (middle category) that is associated with the type. , And a third hierarchy (deep hierarchy) which is associated with each type and has a specific type (small classification) as an option.

  The number of layers and the number of options in each layer can be set as appropriate. In the example of FIG. 4, the first hierarchy has “dogs” and “cats” as options, the second hierarchy has “large dogs”, “medium dogs” and “small dogs” as options, and the third hierarchy has middle dog breeds as options. And three layers.

  The “similarity of the profile with the opponent player” in the present embodiment is obtained by comparing the answers of the respective items stored in the profile data 20, and as the number of the same answers increases, the individual co-sensitivity increases. It is calculated to be higher. In addition, the calculation is performed so that the individual responsivity increases as the same answer is given in a deeper content. The “hardness of play during the effective period of the co-op relationship” is based on the data of the login history and the play history of each player managed separately, and the play frequency (or simply the total number of times) of the effective period is calculated. It is calculated so that the individual sensitivity increases as the number increases.

Of course, the variables for calculating the individual co-sensitivity are not limited to the number of common responses and the frequency of play, and can be set as appropriate.
For example, the similarity determined using the parameter value related to the player character 4 (4a, 4b) can be included. More specifically, a plurality of types (so-called jobs, races, and attributes) are set for the player character 4, and the degree of similarity between them (for example, whether they are of the same type or not, if the ranks of similar types are different, the rank difference , Etc.) can be used to calculate individual co-sensitivities.

  The individual sympathy is identifiably displayed for each player on the symmetry gauge 10 (FIG. 3) of the game screen W2. In the present embodiment, a first individual bar 11 that expands and contracts according to the individual co-sensitivity of the player 2a and a second individual bar 12 that expands and contracts according to the individual co-sensitivity of the opponent player 2b are displayed left-justified. Is done. These two individual bars represent the magnitude of the co-sensitivity as a sum. In the present embodiment, a numerical value that considers the co-sensitivity to be 100% is set in advance, and the magnitude of the numerical value is represented by the gauge frame 13. When the sum of the individual co-sensitivities is equal to or larger than the numerical value, the gauge frame 13 is filled with the first individual bar 11 and the second individual bar 12, but does not go beyond the frame of the gauge frame 13.

  By the way, a valid period (for example, one week) is set in the co-op relationship of the present embodiment, and when the valid period expires, the co-op relationship is automatically canceled / dissolved. However, as shown in FIG. 5, before the expiration of the validity period, a predetermined extension permission condition (a state in which the numerical value of the co-sensitivity is 100% as a threshold in this embodiment, and the co-sensitivity is equal to or more than this threshold) is satisfied. For example, the effective period can be extended regardless of the ratio of the individual co-sensitivity to the co-sensitivity.

  More specifically, if the co-sensitivity is 100% during a predetermined application permission period (for example, from three days before to the end of the period) that precedes the expiration date of the validity period, it is possible to apply for an extension of the validity period Is displayed on the player terminal 1500, and the user can select whether or not to apply for an extension. Here, when an operation of selecting extension application is detected, it is determined that an extension instruction has been issued, and the validity period is extended. It may be said that the current co-op relationship is updated. In this embodiment, an upper limit is set for the number of extensions.

FIG. 6 is a diagram illustrating a specification for providing an object to the opponent player based on the object acquired during the valid period of the co-op relationship.
In the present embodiment, the same object as the object acquired by one player (own player 2a) or an object similar thereto is established in the co-op relationship registration state, that is, the validity period of the co-op relation, and the co-op relation is formed. It can also be given to the player (the opponent player 2b).

  In addition, the provision of the object to the player (the opponent player 2b) may be free and automatic, but in the present embodiment, payment of the consideration is required. The grant is executed after approval of the player (own player 2a) that has acquired the object. Hereinafter, the specification for giving the acquired object to the opponent player will be referred to as “providing the object”.

  The content of the acquired object can be appropriately set according to the content of the game. Since the game of the present embodiment is an action RPG, for example, items such as weapons, armor, and recovery medicine, characters and summons that can be used as player characters, various skills, usage rights of hidden stages, and experiences of enhancing the ability of the player character 4 Values, items, etc. can be set.

The object “provided object” to be provided / provided to the opponent player 2b is an object having the same content as the acquired object or a content equivalent thereto.
In the former case, a copy of the acquired object is given (provided). In addition, the amount and the number to be provided (provided) are the same as those obtained.
In the latter case, an object whose performance is slightly inferior to the acquired object or an object whose quantity is small is set as the provided object. The difference between the acquired object and the provided object is determined according to the sensitivity. In the present embodiment, if the co-sensitivity is equal to or less than the reference value, the latter is set as the "object according to the acquired object", and the difference is set to be smaller as the co-sensitivity is larger. If the value is equal to or greater than the reference value, the former is determined, that is, "the same as the acquired object".

  The price for providing the object can be appropriately set according to the content of the game, but in the present embodiment, a designated item that appears in the game and can be owned by the player 2 (in the figure, the virtual currency “gold” in the game) ") Has allocated consumption. Then, the magnitude of the consideration is determined according to the sensitivity, for example, as shown in FIG. Specifically, the higher the co-sensitivity, the higher the price, and the co-sensitivity is constant above a certain value. Of course, the concept of the price calculation is not limited to this, and an inversely proportional relationship may be used in which the lower the co-sensitivity, the higher the price.

  The opportunity for the acquired object to be given, that is, the opportunity for the player to acquire the object can be set as appropriate. In the present embodiment, it can be provided as a so-called “login lottery” that can be performed once a day at the time of login, a drop of the enemy character 8, a clear bonus for the game stage, and the like. Of course, other opportunities may be provided.

  Further, in the present embodiment, the type and frequency of the object appearing at those occasions are determined by lottery according to the sympathy at that time. Specifically, as shown in FIG. 8, the rarity of the appearing object is set higher according to the co-sensitivity. In addition, the winning probability (or appearance frequency) of an object with a high rarity is set to be higher as the sensitivity is higher. And it is determined by lottery.

[Explanation of Functional Configuration of Player Terminal]
Next, an example of a functional configuration for realizing the present embodiment will be described.
In the present embodiment, the main processing related to the setting / elimination of the co-op relationship and the progress of the game is executed by the player terminal 1500. On the other hand, the server system 1100 performs user registration of each player, management of save data, and supply of data relating to a communal relationship to the player terminal 1500 in response to a request.

  FIG. 9 is a functional block diagram illustrating an example of a functional configuration of the player terminal 1500 according to the present embodiment. The player terminal 1500 of the present embodiment includes an operation input unit 100, a processing unit 200, a sound output unit 370, an image display unit 372, a communication unit 374, and a storage unit 500.

  The operation input unit 100 outputs an operation input signal to the processing unit 200 in accordance with various operation inputs made by the player. For example, it can be realized by a push switch, a joystick, a touch pad, a trackball, an acceleration sensor, a gyro, a CCD module, and the like. The direction input key 1502, the button switch 1504, and the touch panel 1506 in FIG.

  The processing unit 200 is realized by, for example, a microprocessor such as a CPU and a GPU, and electronic components such as an ASIC and an IC memory, and controls input / output of data between the operation input unit 100 and each functional unit including the storage unit 500. Do. Then, it executes various arithmetic processes based on predetermined programs and data, operation input signals from the operation input unit 100, various data received from the server system 1100, and the like, and controls the operation of the player terminal 1500. The control board 1550 in FIG. 2 corresponds to this. The processing unit 200 according to the present embodiment includes a game calculation unit 210, a sound generation unit 270, an image generation unit 272, and a communication control unit 274.

The game calculation section 210 performs main calculation processing relating to the game.
For example, 1) a process of setting a game space in a virtual three-dimensional space and a process of arranging various characters, 2) a process of selecting and setting a type of a character to be the player character 4a according to an operation input, and 3) a process of responding to an operation input Equipping / releasing an item to own player character 4a, 4) selecting a game stage to play according to an operation input, 5) player characters (own player character 4a, opponent player character 4b) according to an operation input during game stage play ), Control of the appearance and movement of the enemy character 8, 6) hit judgment of the attack and reflection of the damage, 7) lottery and appearance processing of the acquired object, 8) judgment of the end of the game stage, 9) validity period, etc. It is possible to execute timekeeping processing related to timekeeping.

  More specifically, the game calculation section 210 includes a mutual relation management control section 212, a co-sensitivity explicit control section 240, an opponent player character definition data acquisition control section 242, a co-play effect control section 244, and an object provision section. 246, a possessed object management unit 248, a price setting unit 250, a provision control unit 252, and a data save control unit 254.

  The mutual relationship management control unit 212 performs a process related to setting and canceling of the “co-op relationship” in the present embodiment. Specifically, the opponent preparation control unit 214, the relationship setting unit 216, the question event occurrence control unit 218, the profile management unit 220, the opponent player related data acquisition control unit 222, the co-sensitivity setting unit 223, It includes a setting canceling unit 224, a forced setting canceling unit 225, a penalty compensation payment controlling unit 226, and a period extending unit 227.

  The opponent preparation control unit 214 performs processing relating to the preparation of opponent player candidates for setting the co-op relationship. In the present embodiment, the data of the player character of the other player is acquired from the server system 1100 in which the co-op relationship is not registered, and an NPC based on the data is made to appear so as to be able to encounter the own player character 4a. Then, when the player character 4a is encountered and selected and operated by the player as a target opponent for conversation or the like, the player account of the other player from which the NPC is based is stored as encounter history data 652 (FIG. 13). Perform management processing. In other words, it is a record of “edges” that link the mutual play.

The relationship setting unit 216 performs control for setting and registering a new co-op relationship.
For example, by setting (applying) a player to be a new opponent player and approval by the opponent player, registration and setting of the co-op relationship are performed assuming that a new co-op relation is established.
In the present embodiment, the player terminal 1500 generates the latest co-op relation setting data 620 (FIGS. 13 and 15) as master data of the co-op relation registration data, and submits a copy thereof to the server system 1100 to save the data. do that for me.

  More specifically, a predetermined number (one person in the present embodiment) is selected from player accounts registered in the encounter history data 652 stored and managed by the opponent preparation control unit 214 in accordance with a selection operation. Then, as a new opponent player, a request for setting a new co-op relationship is transmitted to the server system 1100 and the player account of the selected opponent player is transmitted. Upon receiving the request, the server system 1100 requests approval from the player indicated by the player account received at the same time. When the registration is approved, the registration permission is transmitted to the player terminal 1500. Upon receiving the registration permission, the relationship setting unit 216 sets the latest co-op relationship setting data 620 and provides a copy thereof to the server system 1100.

  The question event generation control unit 218 generates a selection event in which the player selects one of a plurality of options, that is, a question event, as a process related to collecting information for setting co-sensitivity. In the present embodiment, at the time of the first login on the day, a question to be set is selected based on the past answer history and a question event is activated.

The profile management unit 220 causes the storage unit 500 to record the selection result of the option in the question event, that is, the answer to the question, as the own player profile data 608 (FIG. 13).
The own player profile data 608 (corresponding to the profile data 20a in FIG. 4) is uploaded to the server system 1100 by the data save control unit 254 described later, and stored so as to be able to be provided to the player terminal 1500 of another player.

The opponent player-related data acquisition control unit 222 controls acquisition of data relating to the opponent player who has formed a co-op relationship, and causes the storage unit 500 to store the data.
In the present embodiment, since various data relating to each player is stored in the server system 1100, the server system 1100 receives the data. Since the profile data of the opponent player (corresponding to the profile data 20b in FIG. 4) is also included in the target, the opponent player-related data acquisition control unit 222 has a function of acquiring information on the result of selection by the other player in the selection event. It can be said.

The co-sensitivity setting unit 223 calculates “co-sensitivity” as a parameter value indicating a degree of mutual relation using the option selected by the own player 2a and the option selected by the opponent player 2b.
In the present embodiment, the co-sensitivity is determined by comparing the answer results to the questions stored in the profile data of the opponent player acquired from the server system 1100 and the profile data of the own player. Further, the co-sensitivity is determined from the log-in history within the valid period according to the play frequency (see FIG. 4).

  The automatic setting canceling unit 224 performs control for automatically canceling and canceling the co-op relationship whose validity period has expired. In the present embodiment, the master data of the play relationship registration is invalidated or discarded, and the server system 1100 is requested to invalidate the play relationship.

  The forced setting canceling unit 225 is for canceling and canceling the co-op relationship when an input of a predetermined forced setting canceling operation is detected even before the validity period and a penalty compensation payment approval operation is detected. Perform processing. In the present embodiment, the master data of the play relationship registration is invalidated or discarded, and the server system 1100 is requested to invalidate the play relationship.

  The penalty compensation payment control unit 226 executes the payment of the penalty compensation for canceling the forced setting. In the present embodiment, since the user pays for the consumption of the designated item, a process of reducing the designated items owned by the player is performed.

The period extension unit 227 detects that a predetermined application permission condition is satisfied before the validity period, and performs processing related to acceptance, approval, and extension of the period extension application operation.
In the present embodiment, when the co-sensitivity reaches a predetermined value (in the specification, the co-sensitivity is 100%), it is considered that the application permission condition is satisfied, and the extension application can be performed. In addition to notifying the player, an operation of selecting whether to apply for extension is accepted. Then, it is determined that the extension instruction operation has been performed by inputting the extension application operation, and the validity period is extended.

  The co-sensitivity explicit control unit 240 performs a process of specifying the current co-sensitivity to the player. In the present embodiment, display control of the co-sensitivity gauge 10 (FIG. 3) of the game screen W2 is performed.

  The opponent player character definition data acquisition control unit 242 executes control for acquiring data defining the player character 4 (in the example of FIG. 3, the opponent player character 4 b) of the opponent in the co-op relationship. In this embodiment, since the server system 1100 stores and manages the user registration information of all the players, the definition data of the corresponding character is acquired from the server system 1100.

  The co-play effect control unit 244 implements the determination of the trigger timing of the co-play effect, the determination of the effect content, and the activation and manifestation of the effect.

  The object providing unit 246 realizes an opportunity for the player 2a to acquire a new object (a game play resource available in the game: an item, for example). In the present embodiment, a login lottery event is executed at the time of log-in only once a day, and an object to be a lottery result is selected according to the sensitivity, and a process of giving the selected object to the player is performed. In addition, the enemy character 8 gives an object by dropping an object or a clear bonus. In any of these cases, an object to be given is selected in accordance with the sensitivity, and a process of giving the object to the player is performed.

  The price setting unit 250 determines a price for providing / providing an object (acquired object) newly acquired by the own player 2a to the opponent player 2b.

  The provision control unit 252 performs a process of accepting payment approval of the consideration determined by the consideration setting unit 250. Then, when the payment of the consideration is approved, control is performed to determine the provided object and to provide the object to the opponent player 2b. In the present embodiment, the server system 1100 requests the server system 1100 to execute the provision.

  The data save control unit 254 performs control for uploading the latest information on the game play and the co-op relationship to the server system 1100. The server system 1100 manages the uploaded data in association with the player account and makes the data usable in the game of the opponent player for which the co-op relationship has been set.

  The sound output unit 370 is realized by a device that outputs a sound effect, BGM, or the like based on a sound signal input from the sound generation unit 270. The speaker 1510 in FIG. 2 corresponds to this.

The image generation unit 272 is realized by, for example, a processor such as a GPU and a digital signal processor (DSP), a program such as a video signal IC and a video codec, and a drawing frame IC memory such as a frame buffer.
Then, the image generation unit 272 generates one image of the game screen in one frame time (for example, 1/60 second) based on the processing result of the game calculation unit 210, and displays the generated image signal of the game screen as an image. Output to the unit 372.

  The image display unit 372 displays various game images based on the image signal input from the image generation unit 272. For example, it can be realized by an image display device such as a flat panel display, a cathode ray tube (CRT), a projector, and a head mounted display. In the present embodiment, the touch panel 1506 in FIG. 2 corresponds to this.

  The communication control unit 274 performs data processing related to data communication, and realizes data exchange with an external device via the communication unit 374. The communication unit 374 connects to the communication line N to realize communication. For example, it is realized by a wireless communication device, a modem, a TA (terminal adapter), a jack of a wired communication cable, a control circuit, and the like, and corresponds to the wireless communication module 1553 in FIG.

  The storage unit 500 stores a system program for realizing various functions for causing the processing unit 200 to control the player terminal 1500 in an integrated manner, a program necessary for game play, various data, and the like. Further, it is used as a work area of the processing unit 200, and temporarily stores a calculation result executed by the processing unit 200 according to various programs, input data input from the operation input unit 100, and the like. These functions are realized by, for example, an IC memory such as a RAM or a ROM, a magnetic disk such as a hard disk, or an optical disk such as a CD-ROM or a DVD. The IC memory 1552 and the memory card 1540 mounted on the control board 1550 in FIG. 2 correspond to this.

FIG. 10 is a diagram illustrating an example of programs and data stored in the storage unit 500.
The storage unit 500 of the present embodiment stores a terminal system program 502 and a game program 504.
In addition, the storage unit 500 stores character initial setting data 510, object initial setting data 512, game stage initial setting data 514, and question initial setting data 510 as data acquired and stored by downloading or the like from the server system 1100 before the game starts. The definition data 520, the co-effect definition data 530, and the provided object selection condition data 540 are stored. Play data 600 is stored as data generated and managed in accordance with the progress of the game. In addition, information such as a timer and a counter for measuring time and various flags is stored.

  The terminal system program 502 is a program for implementing the basic input / output functions of the player terminal 1500 as a computer.

The game program 504 is application software for realizing a function as the game calculation unit 210 by being read and executed by the processing unit 200. The configuration may be incorporated as a part of the terminal system program 502. It may be a dedicated client program according to a technical method for realizing an online game, or may be constituted by a web browser program and a plug-in for realizing interactive image display.
Then, the game program 504 is downloaded from the server system 1100 and stored together with the character initial setting data 510 and the like. Alternatively, it is prepared by mounting a separately obtained memory card 1540 (FIG. 1) or the like.

The character initial setting data 510 is set for each character appearing in the game, and defines the initial state. For example, it is basic data for controlling and displaying the player character 4 (4a, 4b), the enemy character 8, and the like.
One character initial setting data 510 includes a unique character ID, character display data (data for displaying and operating a character, for example, model data of a character object, motion data, and the like), and an ability parameter in an initial state. And value. Of course, data other than these can also be stored as appropriate.

  The object initial setting data 512 is prepared for each object that can be newly acquired by a player in a login lottery or a game, and defines the object. One object initial setting data 512 stores a unique object ID, an object type, and an initial capability parameter value of the object. Of course, data other than these can also be stored as appropriate.

  The game stage initial setting data 514 is prepared for each game stage. One game stage initial setting data 514 includes a stage ID, a stage appearance condition, an enemy character ID that defines a strategy target of the stage, and a clear bonus ID that is an ID of an object provided as a clear bonus. Of course, data other than these can also be stored as appropriate.

  The question definition data 520 is definition data of a selection event. In the present embodiment, a question for obtaining an answer related to a profile of a player, particularly, a hobby and taste is defined. One question definition data 520 includes, for example, a unique question ID 521, a question condition 522 corresponding to an event activation condition, a question 523 corresponding to the event content, and an option 524 of an answer, as shown in FIG. Of course, data other than these can also be stored as appropriate.

  The co-play effect definition data 530 defines profits / disadvantages that the player can obtain in the game according to the co-sensitivity. As shown in FIG. 12, for example, one co-op effect definition data 530 stores a unique co-op effect ID 531, an application condition 532, and an effect content 533 in association with each other. Of course, data other than these can also be stored as appropriate.

  The provided object selection condition data 540 defines a condition for selecting a provided object based on the object acquired by the player. For example, a ratio indicating how much the various parameter values and the quantity of the acquired object are adjusted to provide the provided object is defined according to the co-sensitivity. Here, the “ratio” is a ratio of an object's ability parameter value (for example, level, rarity, attack power, resilience, etc.) or quantity.

  The play data 600 stores various data describing the progress of the game for each player. For example, as shown in FIG. 13, a player account 601, login history data 602 corresponding to a play history, a stage ID 604, own player profile data 608, own player character status data 610, and own player owned object list 612. , Latest co-op relationship setting data 620, opponent player profile data 630, opponent player login history data 632, opponent player character definition data 634, own player individual co-sensitivity 640, opponent player individual co-sensitivity 642, The co-sensitivity 644, the next co-op player candidate data 650, and the encounter history data 652 are stored. Of course, data other than these can also be stored as appropriate. For example, status data such as HP of the opponent player character 4b and the enemy character 8 being played on the game stage can be stored.

  The login history data 602 is a copy of the login history of the own player corresponding to the player account 601 among the login histories managed for each player in the server system 1100.

  The stage ID 604 stores the stage ID of the game stage currently playing or to be played. The data is uploaded to the server system 1100 after the game is over, and is saved in association with the player account 601.

  The own player profile data 608 stores personal information of the own player, that is, the player who operates the own device. For example, as shown in FIG. 14, an answer option 608b selected as a question answer and an answer date 608c are stored in association with the question ID 608a. The question ID 608a corresponds to the question ID 521 of the question definition data 520 (FIG. 11). In the answer option 608b, a predetermined value (NULL in the example in the figure) indicating an unanswered state is stored in the initial state, and the answer option 608b is changed to the content (or ID) of the option that is answered that an answer to the corresponding question is obtained. The data is uploaded to the server system 1100 after the game is over, and is saved in association with the player account 601.

Returning to FIG. 13, the own player character status data 610 is set for each original player character created and set by the own player, that is, various information describing the state of the own player character 4a (FIG. 3). Is stored.
One player character status data 610 includes a character ID indicating a corresponding character, a character type, an ability parameter value list, a possessed item list, an equipped item list, a possessed virtual currency amount, a position coordinate in the game space, motion control data, Etc. can be stored. Of course, data other than these can also be stored as appropriate. The data is also uploaded to the server system 1100 after the end of the game, and is saved in association with the player account 601.

  The own player owned object list 612 stores information on objects to which the own player has usage rights. For example, the number of possessions is stored in association with each object ID. The data is also uploaded to the server system 1100 after the end of the game, and is saved in association with the player account 601.

  The latest play relationship setting data 620 stores information that defines the latest play relationship. For example, as shown in FIG. 15, a valid period 621, an opponent player account 622, a co-op state flag 623, and a period extension number 624 are stored. Of course, data other than these can also be stored as appropriate. The data is also uploaded to the server system 1100 after the end of the game, and is saved in association with the player account 601.

In the validity period 621, the set date and time of the co-op relationship (registration start date and time) and the date and time after a predetermined validity period (that is, the expiration date of the validity period) are stored.
The co-op status flag 623 indicates whether the co-op relation is valid / invalid. In this embodiment, the initial value at the time of setting is “0 (invalid)”, and is changed to “1 (registered state: valid)” when the approval of the opponent player is obtained. Then, when the validity period expires, it is returned to “0 (invalid)” again.
The number of extension periods 624 is “0” in the initial state, and is increased by “1” each time an application for extension is made and approval from the opponent player is obtained.

  The opponent player profile data 630 is the opponent player's profile data 20 (corresponding to the profile data 20b in FIG. 3), and is provided from the server system 1100.

  The opponent player log-in history data 632 is log-in history data of the opponent player, and is also provided from the server system 1100.

  The opponent player character definition data 634 is the definition data of the opponent player character 4b (FIG. 3), and is a copy of the data saved in the server system 1100 for the opponent player 2b.

  The own player individual sympathy 640 stores the value of the individual sympathy of the own player 2a. The data is also uploaded to the server system 1100 after the end of the game, and is saved in association with the player account 601.

  The opponent player individual sympathy 642 is the individual sympathy of the opponent player 2b, and is provided from the server system 1100.

  The next co-op opponent player candidate data 650 is data relating to opponent player candidates in the next co-op relation. In this embodiment, the player count is prepared for each candidate, and the next player character definition data, which is a copy of the player character status data of the player, is stored in association with each other. These data are provided from the server system 1100. The latter is data on which NPCs appear so that the player character 4a can encounter them.

  The encounter history data 652 is history data created each time the own player character 4a encounters an NPC based on the next co-op player candidate data 650 and is selected and operated as a target such as a conversation. One encounter history data 652 stores, for example, a player account associated with an NPC encountered, the number of encounters, and encounter location information in association with each other. Of course, data other than these can also be stored as appropriate.

[Explanation of server system functional configuration]
FIG. 16 is a functional block diagram illustrating a functional configuration example of the server system 1100 according to the present embodiment. The server system 1100 according to the present embodiment includes an operation input unit 100s, a server processing unit 200s, an image display unit 372s, a communication unit 374s, and a server storage unit 500s.

  The operation input unit 100s is a unit for inputting various operations for managing the server. The keyboard 1106 in FIG. 1 corresponds to this.

  The server processing unit 200 s is realized by electronic components such as a microprocessor such as a CPU and a GPU, an ASIC (application-specific integrated circuit), and an IC memory, and includes various functional units including an operation input unit 100 s and a server storage unit 500 s. Data input / output control is performed between Then, various arithmetic processes are executed based on predetermined programs and data, operation input signals from the operation input unit 100s, and data received from the player terminal 1500, and the operation of the server system 1100 is integrally controlled.

  The server processing unit 200s of the present embodiment includes an account management unit 201, a game management unit 202, an image generation unit 272s, and a communication control unit 274s.

  The account management unit 201 performs a process related to a user registration procedure. A unique player account is issued to the user who has completed the registration procedure, that is, the player, and the user registration data 700 is generated and stored in the server storage unit 500 s and managed. In addition, a process related to login is executed.

  The game management unit 202 executes various processes related to game play. The present embodiment includes a save data management unit 204, an opponent player-related data supply control unit 206, and a next co-op partner player candidate data supply control unit 208.

  The save data management unit 204 controls to store and manage various data provided from the player terminal 1500 in association with the player account.

  The opponent player-related data supply control unit 206 generates, from the data stored and managed by the save data management unit 204, information on the opponent player for which the co-op relationship has been set, in response to a request from the player terminal 1500. Perform the control provided.

  Similarly, in response to a request from the player terminal 1500, the next co-op opponent player candidate data supply control unit 208 selects, from the data stored and managed by the save data management unit 204, the next co-op relation opponent player. And selects and provides information relating to a player who can be. The provided data becomes the next co-op player candidate data 650 (FIG. 13).

  The image generation unit 272s generates an image related to the maintenance of the server system 1100, and outputs the generated image to the image display unit 372s.

  The image display unit 372s displays various images for system management based on the image signal input from the image generation unit 272s. For example, it can be realized by an image display device such as a flat panel display, a cathode ray tube (CRT), a projector, and a head mounted display. The touch panel 1108 in FIG. 1 corresponds to this.

  The communication control unit 274s executes data processing related to data communication, and realizes data exchange with an external device via the communication unit 374s.

  The communication unit 374s connects to the communication line N to realize communication. For example, it is realized by a wireless communication device, a modem, a TA (terminal adapter), a jack of a communication cable for wired communication, a control circuit, and the like. The communication device 1153 in FIG. 1 corresponds to this.

  The server storage unit 500s stores a system program for realizing various functions for causing the server processing unit 200s to integrally control the server system 1100, programs and various data necessary for managing a game, and a player terminal 1500. The program to be provided and the original of various data are stored. Further, it is used as a work area of the server processing unit 200s, and temporarily stores a calculation result and the like executed by the server processing unit 200s according to various programs. This function is realized by, for example, an IC memory such as a RAM or a ROM, a magnetic disk such as a hard disk, or an optical disk such as a CD-ROM or a DVD. In FIG. 1, a storage medium such as an IC memory 1152 and a hard disk mounted on the main body device 1101 and a storage 1140 correspond to this.

  The server storage unit 500s stores a server system program 501, an account management program 503, a game management program 505, a distribution game program 507, and distribution game data 509 in advance. Further, user registration data 700 is stored as data that is appropriately generated and stored. In addition, information such as a timer, a counter, and various flags is appropriately stored.

  The server system program 501 is a system program for implementing basic input / output functions required as a computer in the server system 1100 by being read and executed by the server processing unit 200s.

  The account management program 503 is a program for realizing the function as the account management unit 201 by being read and executed by the server processing unit 200s.

  The game management program 505 is a program for realizing the function as the game management unit 202 by being read and executed by the server processing unit 200s.

  The distribution game program 507 is an original of the game program 504 (FIG. 10) provided to the player terminal 1500.

The distribution game data 509 is original data of various initial settings and definition data provided to the player terminal 1500.
In the present embodiment, each of character initial setting data 510, object initial setting data 512, game stage initial setting data 514, question definition data 520, co-effect definition data 530, and provided object selection condition data 540 is provided. The original is included.

  The user registration data 700 is prepared for each registered player, and in this embodiment, stores various data uploaded from the player terminal 1500 after the game is over. As shown in FIG. 17, for example, one user registration data 700 includes a player account 701, login history save data 702, stage ID save data 704, profile save data 708, player character save data 710, owned object The list save data 712, the play relationship setting history data 720, and the individual co-sensitivity save data 740 are stored. Of course, data other than these can also be stored as appropriate.

  The login history save data 702 is the master data of the login history of the player, and this copy becomes the login history data 602 (FIG. 13).

  The stage ID save data 704 is a copy of the uploaded stage ID 604 (FIG. 13).

  The profile save data 708 is a copy of the uploaded player profile data 608 (FIG. 13).

  The owned object list save data 712 is a copy of the own player owned object list 612 (FIG. 13) uploaded.

  The co-op relationship setting history data 720 is generated based on the uploaded latest co-op relation setting data 620 (FIG. 13) and is left for each co-op relationship.

  The individual co-sensitivity save data 740 is a copy of the own player's individual co-sensitivity 640 (FIG. 13) uploaded.

[Explanation of processing flow]
FIGS. 18 to 21 are flowcharts for explaining the flow of the processing related to the mutual relation by the player terminal 1500.
The processing flow described here is realized by executing the game program 504 while the processing unit 200 executes the terminal system program 502. Before this process is executed, it is assumed that data communication with the server system 1100 is established, the player has logged in with the player account acquired in advance, and his / her player character 4 has been set. Along with this, the player account 601 is stored in the play data 600, and the login history save data 702 (FIG. 17) is also updated.

  As illustrated in FIG. 18, the processing unit 200 of the player terminal 1500 performs a process of acquiring data on an opponent player who has a cooperative relationship with various save data relating to the player (step S2).

In this acquisition process, in the present embodiment, the processing unit 200 transmits a data provision request and the player account 601 of the own player to the server system 1100.
Upon receiving the request, the server system 1100 obtains the login history save data 702, the stage ID save data 704, the profile save data 708, and the player character from the user registration data 700 (FIG. 17) corresponding to the received player account. The saver data 710, the owned object list save data 712, the data with the latest validity period 721 of the co-op relationship setting history data 720, and the individual co-sensitivity save data 740 are transmitted to the player terminal 1500 requesting the data provision. Send to

  Further, if the co-op status flag 723 of the co-op relation setting history data 720 with the latest term of validity period 721 is “1”, the profile save data 708 and the profile save data 708 are obtained from the user registration data 700 corresponding to the opponent player account 722. Then, the login history save data 702, the player character save data 710, and the individual co-sensitivity save data 740 are read out and transmitted to the player terminal 1500 that has requested data provision in the same manner.

  The processing unit 200 of the player terminal 1500 receives them and adds the log history data 602, the stage ID 604, the own player profile data 608, the own player character status data 610, the own player owned object list to the play data 600 (FIG. 13). 612, the latest co-op relationship setting data 620, and the player's individual co-sensitivity 640 are stored in the play data 600. In addition, they are stored in the play data 600 as opponent player profile data 630, opponent player login history data 632, opponent player character definition data 634, and opponent player individual co-sensitivity 642, respectively.

Then, the processing unit 200 calculates the sensitivity 644 based on the obtained save data (step S4).
In the case of the first game play, the co-op relationship setting history data 720 is not generated because the co-op relation is not set. Therefore, the play data 600 of the player terminal 1500 includes the latest co-op relationship setting data 620, the own player individual co-sensitivity 640, the opponent player profile data 630, the opponent player login history data 632, the opponent player character definition data 634, and the opponent player individual data. The co-sensitivity 642 is not stored (or each is stored with a predetermined initial value). Therefore, in the case of the first game play, the co-sensitivity 644 is set to the initial value “0” or information indicating that no setting has been made (for example, NULL).

  Next, the processing unit 200 determines whether or not the co-op relationship is set and registered based on the presence or absence of the latest co-op relation setting data 620 and the co-op status flag 623 (FIG. 15), that is, whether or not the co-op relation is valid. A determination is made (step S10).

  If the co-op relationship is in the registered state (YES in step S10), the processing unit 200 determines whether the co-op relationship has expired (step S12). Then, if the time has expired (YES in step S12), a setting cancellation process of the current co-op registration is executed (step S14).

  In this embodiment, the processing unit 200 sets the co-op state flag 623 stored in the latest co-op relation setting data 620 (FIG. 15) to “0 (setting reset: invalid)”. Or deletes the latest co-op relationship setting data 620 itself. Also, the opponent player profile data 630, the opponent player login history data 632, and the opponent player character definition data 634 are deleted from the play data 600 (FIG. 13). In addition, the player's own individual sensitivity 640, the opponent player's individual sensitivity 642, and the sensitivity 644 are initialized to “0”. Then, the request for canceling the setting of the co-op relationship and the player account 601 are transmitted to the server system 1100.

Upon receiving the request, the server system 1100 searches the user registration data 700 (FIG. 17) of the received player account for the co-op relationship setting history data 720 with the latest validity period 721, and similarly sets the co-op state flag. 723 is set to “0”, and the individual co-sensitivity save data 740 is initialized to “0”.
Further, from the user registration data 700 associated with the player account of the opponent player indicated by the opponent player account 722 of the history data, similarly, the latest co-op relation setting history data 720 is similarly selected, and the co-op state flag 723 is similarly set. The value is changed to “0”, and the individual co-sensitivity save data 740 is changed to “0”.

  Then, when the common registration setting canceling process is executed, the processing unit 200 executes a process of notifying the player that the setting of the co-op relationship has been cancelled, and the self-relationship has become unregistered. (Step S16) The player is made to select whether or not to reset the player profile data 608 (FIGS. 13 and 14) (Step S18).

If a reset approval operation input is detected (YES in step S20), a reset process of the own player profile data 608 is executed (step S22).
In the present embodiment, all the answer options 608b of the own player profile data 608 (FIG. 14) are initialized to a state indicating “unanswered”. In addition, a profile data reset request and a player account are transmitted to server system 1100. Upon receiving the request, the server system 1100 initializes the contents of the answers to the questions registered in the profile save data 708 of the user registration data 700 of the received player account to a state indicating “unanswered” in the same manner. Become

Next, the processing section 200 executes a login lottery process (step S40).
At this time, the processing unit 200 sets a winning probability according to the co-sensitivity 644 for each rarity of an object that can appear as a prize in a lottery. Specifically, the upper limit of the degree of rarity that can appear according to the co-sensitivity 644 is set. If the co-relationship is unregistered, the upper limit of the rarity is set to the initial value because the co-sensitivity 644 is “0” in the initial state. However, the higher the co-sensitivity 644, the higher the upper limit of the rarity of an object that can appear. I do. The winning probability of the object corresponding to the upper limit of the rarity is determined to be higher as the co-sensitivity 644 is higher, while the winning probability of the object exceeding the upper limit of the rarity is set to “0” (in a state in which the winning is not substantially achieved). I do.
Then, in accordance with the setting of the rarity upper limit and the winning probability, the processing unit 200 executes the lottery process, and registers the information of the won object in the own player owned object list 612 of the play data 600.

  Next, if the co-op relationship of the player is in the registered state (YES in step S42), the processing unit 200 performs an approval process for providing a provided object based on the object obtained in the login lottery (step S44). More specifically, a price for providing the provided object is calculated in accordance with the co-sensitivity 644, the calculated price is notified, and a selection operation for approval / disapproval is received.

  Then, if the approval operation is detected (YES in step S46), the processing unit 200 consumes a predetermined consumption medium (for example, a specified item or the like) for which the price is calculated in advance. Is executed (step S48), an object to be provided to the opponent player is determined based on the co-sensitivity 644 (step S50), and a process of providing the provided object to the opponent player is executed (step S52).

In the provision processing of the provision object, in the present embodiment, the player account 601 and the object ID and the quantity of the provision object are transmitted to the server system 1100 together with the provision request.
When the server system 1100 receives the request, the server system 1100 refers to the partner player account 722 from the data having the latest validity period 721 based on the co-op relationship setting history data 720 of the user registration data 700 corresponding to the received player account. Then, the provided object is additionally registered in the owned object list save data 712 of the user registration data 700 corresponding to the referred player account. Accordingly, the server system 1100 may be configured to execute a process of notifying the opponent player that the provided object has been given.

19, the processing unit 200 of the player terminal 1500 executes an acquisition process of the next co-op player candidate data 650 (FIG. 13) (step S58).
In the present embodiment, when a request to provide the data is transmitted from the player terminal 1500 to the server system 1100, the server system 1100 appropriately selects the user registration data 700, generates the next co-op player candidate data 650, and returns the data. I do. The processing unit 200 of the player terminal 1500 receives this and stores it in the play data 600.

  Next, the processing unit 200 displays a home screen for receiving various operation inputs (step S60). In the present embodiment, on the home screen, 1) a new setting operation of the co-op relationship, 2) a forced cancellation operation of the co-op relation, 3) a play start operation, 4) an application end operation, and the like are possible. Of course, other operations can be appropriately performed.

  By the way, if the co-op relationship of the own player is not registered (NO in step S62), the processing unit 200 enables input of a new co-op relation setting operation on the home screen. Then, when the input of the operation is detected (YES in step S64), the processing unit 200 executes the co-op relationship setting process (step S66).

  The co-op relationship setting processing is, in other words, team formation or group formation processing. A matching technique related to team formation or group formation in an online game or the like can be used as appropriate. In the present embodiment, the processing unit 200 generates the latest co-op relationship setting data 620 (FIG. 15) for the play data 600 and sets it to an initial state. Alternatively, the existing data is reset to the initial state. Specifically, the current date and time and a date and time after a predetermined effective period from the current date and time are set in the validity period 621. The co-op state flag 623 is set to “0 (invalid)”, and the number of extended periods 624 is set to “0”.

  On the other hand, the processing unit 200 determines the next co-op opponent that matches the player account stored in the encounter history data 652 (FIG. 13) among the next co-op opponent player candidate data 650 stored in the play data 600. The player candidate data 650 is selected, a selection list is displayed, and an opponent player account 622 is set in accordance with a selection operation input. The selection at the time of selection list is an element that directs the “edge of meeting”.

Then, a player account 601 and the latest co-op relationship setting data 620 are transmitted from the player terminal 1500 to the server system 1100 together with a new co-op relation setting request.
Upon receiving the request, the server system 1100 generates new play relationship setting history data 720 in the user registration data 700 based on the received latest play relationship setting data 620. Then, a process of requesting the player indicated by the opponent player account 722 to approve the setting of the co-op relationship is executed. This processing uses a well-known mutual authentication procedure technique in matching in an online game or the like as appropriate.

If the approval is obtained, the server system 1100 changes the co-op state flag 623 of the co-op relation setting history data 720 generated previously to “1 (valid)”, and sends a predetermined approval completion signal (setting) to the player terminal 1500. Permission signal: setting enable signal). Upon receiving the approval completion signal, the player terminal 1500 changes the co-op state flag 623 of the latest co-op relation setting data 620 to “1 (valid)”.
Of course, in the co-op relationship setting process, a configuration that does not require such a mutual approval procedure may be used.

  Then, the processing section 200 acquires data on the partner player of the co-op relationship just set, from the server system 1100 (step S68).

On the other hand, if the co-op relationship of the own player is in the registered state (YES in step S62), the processing unit 200 enables input of an operation to forcibly cancel the co-op relation on the home screen. Then, when the input of the operation is detected (YES in step S90), a penalty for forced cancellation is calculated, the penalty is presented to the player, and a selection input of approval / cancellation is requested (step S92). .
The penalty compensation can be set as appropriate, such as consumption of a predetermined consumption medium (such as a specified item) or a reduction in the ability parameter value of the player character 4. The penalty may be a fixed price, but it is preferable that the penalty is determined such that the more the remaining valid period is, the higher the price is and the higher the sensitivity 644 is, the higher the price is.

  Then, if an operation input for approving the payment of the penalty is detected (YES in step S94), the processing unit 200 executes the payment processing of the penalty (step S96), and the latest communal play is performed in the same manner as in step S14. The cooperative relationship setting cancellation process indicated by the relationship setting data 620 is executed (step S98).

  When the input of the play start operation is detected on the home screen (YES in step S120), the processing unit 200 executes a process of selecting a game stage to be played (step S122). The identification information of the selected game stage is stored in the stage ID 604 (FIG. 13).

Next, if the co-op relationship of the player is in the registered state (YES in step S124), the processing unit 200 executes a process of a question event (step S164).
The question event process is a process for increasing items for finding common points between players who have formed a mutual play relationship, and for enhancing sympathy. In the present embodiment, with reference to the answer date and time 608c registered in the player profile data 608 (FIG. 14), if there is no record of the day, the question ID 608a which remains "unanswered" in the question-specific answer is not recorded. Is extracted. Then, a question is asked to the player with reference to the question definition data 520 (FIG. 11) corresponding to at least one of the extracted ones, and an answer selection operation is accepted (FIG. 4). The processing unit 200 updates the own player profile data 608 according to the answer selection operation.

Then, the processing unit 200 updates the sensitivity 644 (step S128).
In this embodiment, the updated answer profile 608b (FIG. 14) of the updated own player profile data 608 and the opponent player profile data 630 (FIG. 13) are compared, and the same type of answer is registered for the same question. The number of same responses Also, with reference to the log-in history data 602, the “play frequency per day” within the effective period of the currently active co-op relationship is calculated. Then, the co-sensitivity 644 is calculated and updated based on a predetermined function using the “number of answers” and “play frequency per day” as variables.
It should be noted that the predetermined function is set such that the greater the number of responses and the higher the frequency of play per day, the higher the value of the co-sensitivity 644.

Moving on to the flowchart of FIG. 20, next, the processing unit 200 causes the opponent player character 4b (FIG. 3) to appear as an auxiliary NPC and starts the progress control of the game in the game stage indicated by the stage ID 604 (step S140). ).
Along with this, the processing section 200 starts display control of the co-sensitivity gauge 10 and control relating to the manifestation of the co-play effect (FIG. 3). Regarding the latter, if there is the co-play effect definition data 530 (FIG. 12) that matches the application condition 532, the effect content 533 is applied to the progress control of the game.

Further, the processing unit 200 starts NPC appearance control based on the next co-op player candidate data 650 and recording control of the encounter history data 652 (FIG. 13).
Regarding the former, when an NPC that satisfies a predetermined condition (for example, an NPC in which the player character 4 can talk) appears, one of the next co-op opponent player candidate data 650 is selected and stored in the selected data. The next co-op player character based on the next co-op opponent player character definition data is caused to appear as an NPC. The appearance can be set as appropriate. It may be an NPC of a polygon model, or a so-called cut-in effect in which a band including the pattern of the character appears from the edge of the screen.

  Then, the processing unit 200 sequentially updates the sympathy 644 according to the progress of the game (step S142). In the present embodiment, it is assumed that the better the result, the more the sensitivity 644 is sequentially added.

  On the other hand, if the input of the play start operation is detected, but the co-op relationship of the player is unregistered (FIG. 19; NO in step S124), the processing unit 200 starts the game progress control, but the auxiliary NPC The game proceeds without causing the opponent player character 4b (FIG. 3) to appear (step S144). Since the co-op relationship has not been registered, the display control of the co-sensitivity gauge 10 and the control of the manifestation of the co-op effect are not performed, but the appearance control of the next co-op opponent player character and the recording control of the encounter history data 652 are performed. Start. In other words, compared to the situation where the co-op relationship is registered, the interest in the game is inferior to the extent that there is no factor such as the activation of the co-op effect. This motivates the player to set a co-op relationship.

  In any of step S140 and step S144, when the player acquires an object such as an item in the play of the game stage, the processing unit 200 sets the object as an acquired object in the current game play. Is registered in the own player owned object list 612.

  Then, the play on the game stage ends (step S160), and if the co-op relationship of the own player is in the registered state (YES in step S162), the processing unit 200 performs the current process in the same manner as in steps S44 to S52. A process for providing the opponent player with the provided object based on the acquired object in the game play is executed (steps S164 to S172).

  Referring to the flowchart of FIG. 21, the current date and time is within the application permission period (for example, from three days before to the end of the validity period) (YES in step S200), and the number of extension times 624 of the latest co-op relationship setting data 620 is set. If has not reached the predetermined upper limit (YES in step S202), the processing unit 200 determines whether the extension permission condition is satisfied (step S204).

  In the present embodiment, the co-sensitivity 644 has reached the threshold value (that is, the gauge has reached 100% in the case of the co-sensitivity gauge 10), and the play frequency within the effective period of each of the own player and the opponent player is the reference. In the case above, it is determined that the extension permission condition is satisfied. As for the extension permission condition, one of the condition relating to the co-sensitivity and the condition relating to the play frequency may be omitted.

  If it is determined that the extension permission condition is satisfied (YES in step S204), the processing unit 200 performs control to notify the player that an application for extending the validity period is possible, and requests the player to request the extension. A selection is made (step S206). For example, together with the notification display, each selection operation icon for requesting / not requesting extension may be displayed.

  If an extension application “necessary”, that is, a selection operation input of “perform extension” is detected (YES in step S208), the processing unit 200 extends the validity period 621 of the latest co-op relationship setting data 620 by a predetermined period. And the period extension count 624 is increased by “1” (step S210).

Further, the processing unit 200 executes a process of reflecting the extension of the co-op relationship to the opponent player who has a co-op relationship (step S212).
In the present embodiment, an extension reflection request and a player account 601 are transmitted to the server system 1100. Upon receiving the request, the server system 1100 refers to the opponent player account 722 of the latest co-op relationship setting history data 720 of the user registration data 700 corresponding to the received player account (FIG. 17). Then, in the user registration data 700 corresponding to the opponent player account 722, the valid period 721 of the latest co-op relationship setting history data 720 and the number of extended periods 724 are changed in the same manner as in step S210. At this time, if the start date of the validity period 721 before the change is the current day, the server system 1100 assumes that the opponent player has already applied for an extension of the validity period first, and No changes shall be made.

  As a step before Steps S210 and S212, a step of obtaining approval for extending the period from the opponent player may be appropriately inserted.

  Then, the processing section 200 notifies the player that the extension has been completed (step S214).

Next, the processing section 200 executes a save data update process (step S230).
In this embodiment, a player account 1500, a stage ID 604, own player profile data 608, own player character status data 610, an own player owned object list 612, together with a save data update request from the player terminal 1500 to the server system 1100. And the latest co-op relation setting data 620 and the player's individual co-sensitivity 640.

Upon receiving the update request, the server system 1100 updates the user registration data 700 corresponding to the received player account based on the provided various data.
Specifically, the received copy of the stage ID 604 is referred to as stage ID save data 704, and the received copy of the own player profile data 608 is referred to as profile save data 708.
Also, a copy of the received own player character status data 610 is referred to as player character save data 710, and a copy of the received own player owned object list 612 is referred to as owned object list save data 712.
Also, if there is the co-op relationship setting history data 720 whose validity period 721 is the same as the received latest co-op relation setting data 620, the received data is replaced with a copy of the received data. If there is no data that matches the validity period 721, new play relationship setting history data 720 is generated and stored by copying the received data.
A copy of the own player's individual co-sensitivity 640 received is used as individual co-sensitivity save data 740.

Then, if the input of the application end operation is detected on the home screen (YES in step S232), the processing unit 200 ends a series of processes.
If not detected (NO in step S232), the process returns to the flowchart in FIG. 19, and the processing unit 200 displays the home screen again (step S60).

  As described above, according to the present embodiment, a game in which a co-op relationship (specifically, a mutual support relationship in which a player character uses an NPC with each other) having a validity period of a plurality of days between players is realized. You. Then, when the game is played in the registered state of the co-op relationship, the co-sensitivity with the co-op partner player is automatically calculated, and the game is played according to the co-sensitivity more advantageously than in the case where the co-op relationship is not registered. Will be able to

  Then, the same player can experience the same selection event as the own player and the other players who have registered and set the co-op relationship, and the co-sensitivity can be set based on the respective selection results. The selection in the selection event depends to a large extent on the personality of the player, and the accumulation of the selection results reflects individuality. Therefore, the sympathy reflects the similarities and differences in personality between players, and the game whose progress is controlled based on the sympathy naturally reflects the similarities and differences in personality between players. Become. Differences in progress depending on how similar oneself and the opponent are to each other and how much one can sympathize will be created, and this will be an interest in a new game.

(Modification)
As described above, the embodiments to which the present invention is applied have been described. However, the embodiments of the present invention are not limited to the above, and the components can be added, omitted, or changed as appropriate.

[Part 1]
For example, in the above-described embodiment, main processes such as setting and canceling of mutual relations, occurrence of question events and management of profiles, calculation of sympathy, and control of game progress according to the sympathy are executed by the player terminal 1500. Although the configuration has been described, the configuration in which the processing is executed in the server system 1100 is also possible, and the processing can be executed in a distributed manner between the player terminal 1500 and the server system 1100.

  In the former configuration, the player terminal 1500 is used as a device for operation input and image display, and processing related to game realization is executed by the server system 1100. For example, this is the case where the game of the present invention is realized in the form of a browser game or a web game. Specifically, an example of the functional configuration of the server system 1100 is configured as shown in FIG. 22, and the configuration of programs and data stored in the server storage unit 500s is as shown in FIG. The flow of processing of the server system 1100 in this configuration is basically the same as the flowcharts described with reference to FIGS. 18 to 21, and may be replaced with the processing executed by the server processing unit 200 s of the server system 1100. .

  The latter configuration is applicable in a game system in which the server system 1100 is realized by another player terminal 1500, for example, in a configuration in which player terminals are connected in a peer-to-peer manner.

[Part 2]
Further, the player terminal 1500 has a form of a smartphone, but may be another computer, for example, an electronic apparatus. For example, a non-portable home-use game device including a device main body on which a control board is mounted and a plurality of game controllers with a touch panel wirelessly connected to the device main body can be provided. In this configuration, the apparatus main body may be equivalent to the control board 1550 of the above embodiment, and the game controller may be regarded as a wireless communication type touch panel 1506.

  Similarly, the player terminal 1500 may have a form as an arcade game device (business game device). In that case, the arcade game device is equipped with a device for reading data from a trading card carrying data relating to game play resources (for example, characters and objects in the above embodiment), and based on the data read from the trading card, the own player. Character status data 610 and own player owned object list 612 may be set.

[Part 3]
Also, the applicable game genre is not limited to the above embodiment, and the present invention is applicable regardless of the genre as long as it is a game in which an opponent player character appears.

2 ... player 2a ... own player 2b ... opponent player 4 ... player character 4a ... own player character 4b ... opponent player character 10 ... co-sensitivity gauge 20 ... profile data 200 ... processing unit 204 ... save data management unit 206 ... opponent player related data Delivery control unit 208 ... Next co-op player candidate data delivery control unit 210 ... Game calculation unit 212 ... Relationship management control unit 214 ... Opponent preparation control unit 216 ... Relationship setting unit 218 ... Question event occurrence control unit 220 ... Profile management unit 222: opponent player related data acquisition control unit 223: co-sensitivity setting unit 224: automatic setting cancellation unit 225: forced setting cancellation unit 226 ... penalty compensation payment control unit 227 ... period extension unit 240 ... co-sensitivity explicit control unit 242: opponent player Character definition data acquisition system Control unit 244 ... Co-play effect control unit 246 ... Object giving unit 248 ... Owned object management unit 250 ... Price setting unit 252 ... Provision control unit 254 ... Data save control unit 500 ... Storage unit 504 ... Game program 510 ... Character initial setting data 512 ... Object initial setting data 514 ... Game stage initial setting data 520 ... Question definition data 530 ... Co-op effect definition data 540 ... Provided object selection condition data 600 ... Play data 601 ... Player account 602 ... Login history data 604 ... Stage ID
608 ... own player profile data 610 ... own player character status data 612 ... own player owned object list 620 ... latest co-op relationship setting data 621 ... validity period 622 ... opponent player account 623 ... co-op status flag 624 ... number of extended periods 630 ... Opponent player profile data 632: opponent player login history data 634: opponent player character definition data 640: own player individual co-sensitivity 642: opponent player individual co-sensitivity 644: co-sensitivity 650: next co-op player candidate data 652: encounter history data 700: user registration data 720: play relationship setting history data 1500: player terminal 1550: control board 1551: CPU
W2: Game screen W4: Event screen

Claims (13)

A program for causing a player terminal to execute a predetermined game,
An interaction setting means for setting another player for which an interaction is to be set, based on an operation input of the player;
Parameter value setting means for variably setting a parameter value (hereinafter referred to as “parameter value”) indicating the degree of the mutual relationship;
Providing means for providing a game object to the player;
Providing object determining means for determining a game object to be provided to the other player (hereinafter referred to as “providing object”) using the game object provided to the player by the providing means and the parameter value;
Providing control means for communicating with the other player terminal of the other player, or communicating with the game server system of the game, and performing control for providing the provided object to the other player;
To function the player terminals as,
The providing object determining means is means for determining the providing object having a performance equal to or less than the performance of the game object provided to the player by the providing means, and the performance difference including the difference in the performance is determined by the parameter. Means for determining the provided object by determining based on the value,
program. A program for causing a player terminal to execute a predetermined game,
An interaction setting means for setting another player for which an interaction is to be set, based on an operation input of the player;
Parameter value setting means for variably setting a parameter value (hereinafter referred to as “parameter value”) indicating the degree of the mutual relationship;
Providing means for providing a game object to the player;
Providing object determining means for determining a game object to be provided to the other player (hereinafter referred to as “providing object”) using the game object provided to the player by the providing means and the parameter value;
Providing control means for communicating with the other player terminal of the other player, or communicating with the game server system of the game, and performing control for providing the provided object to the other player;
To function the player terminals as,
The provided object determining means is means for determining the provided object having a performance less than the performance of the game object provided to the player by the providing means, and determining the performance difference based on the parameter value. Is a means for determining the provided object by performing
program. The provided object determining means determines the provided object having lower performance than the game object given to the player, as the degree of the relationship indicated by the parameter value is smaller.
The program according to claim 1. A program for causing a player terminal to execute a predetermined game,
An interaction setting means for setting another player for which an interaction is to be set, based on an operation input of the player;
Parameter value setting means for variably setting a parameter value (hereinafter referred to as “parameter value”) indicating the degree of the mutual relationship;
Providing means for providing a game object to the player;
Providing object determining means for determining a game object to be provided to the other player (hereinafter referred to as “providing object”) using the game object provided to the player by the providing means and the parameter value;
Providing control means for communicating with the other player terminal of the other player, or communicating with the game server system of the game, and performing control for providing the provided object to the other player;
To function the player terminals as,
The assigning means determines an assigned number of the game objects, and assigns the determined assigned number of the game objects to the player.
The providing object determining means determines, based on the parameter value, the number of provided providing objects that is equal to or less than the number of game objects provided to the player by the providing means.
program. The provided object determining means determines the provided number of provided objects that is smaller than the provided number of game objects provided to the player, as the relationship degree indicated by the parameter value is smaller.
The program according to claim 4. The providing object determining means, when the relation degree satisfies a reference condition based on the parameter value indicating that the relation degree satisfies a given criterion, a game provided to the player by the providing means by the providing means. Determined as the same as the object,
The program according to any one of claims 1 to 5 . Causing the player terminal to function as consumption medium quantity storage means for storing the number of consumption media that can be consumed in consideration of the provision by the provision means held by the player;
The providing means provides the game object in exchange for consumption of the consumption medium;
The program according to any one of claims 1 to 6 . Price setting means for variably setting the price using the parameter value,
The program according to claim 7 , further causing the player terminal to further function. The providing means changes a game object provided to the player using the parameter value.
A program according to any one of claims 1 to 8 . Selection event generation means for generating a selection event in which the player selects and operates any of a plurality of options;
Another player selection information obtaining means for obtaining information on an option selected by the other player in the selection event at the player terminal of the other player,
Further functioning the player terminal as
The parameter value setting means variably sets the parameter value using an option selected by the player and an option selected by the other player,
Program according to claim 8 or 9. A server system for communicating with a player terminal of each player and causing the player terminal to execute a predetermined game,
Based on the operation input of the first player of the first player terminal and the operation input of the second player of the second player terminal, a mutual relationship is set between the first player and the second player. Interrelation setting means,
Parameter value setting means for variably setting a parameter value (hereinafter referred to as “parameter value”) indicating the degree of the mutual relationship;
Providing means for providing a game object to the first player;
Provided object determining means for determining a game object to be provided to the second player (hereinafter referred to as “provided object”) using the game object provided to the first player by the providing means and the parameter value. When,
Providing control means for performing control for providing the providing object to the second player;
Equipped with a,
The providing object determining means is means for determining the providing object having a performance equal to or less than a performance of a game object provided to the first player by the providing means, and A means for determining the provided object by determining based on the parameter value,
Server system. A server system for communicating with a player terminal of each player and causing the player terminal to execute a predetermined game,
Based on the operation input of the first player of the first player terminal and the operation input of the second player of the second player terminal, a mutual relationship is set between the first player and the second player. Interrelation setting means,
Parameter value setting means for variably setting a parameter value (hereinafter referred to as “parameter value”) indicating the degree of the mutual relationship;
Providing means for providing a game object to the first player;
Provided object determining means for determining a game object to be provided to the second player (hereinafter referred to as “provided object”) using the game object provided to the first player by the providing means and the parameter value. When,
Providing control means for performing control for providing the providing object to the second player;
Equipped with a,
The provided object determining means is means for determining the provided object having a performance less than a performance of a game object provided to the first player by the providing means, and determines a performance difference based on the parameter value. Means for determining the provided object by determining
Server system. A server system for communicating with a player terminal of each player and causing the player terminal to execute a predetermined game,
Based on the operation input of the first player of the first player terminal and the operation input of the second player of the second player terminal, a mutual relationship is set between the first player and the second player. Interrelation setting means,
Parameter value setting means for variably setting a parameter value (hereinafter referred to as “parameter value”) indicating the degree of the mutual relationship;
Providing means for providing a game object to the first player;
Provided object determining means for determining a game object to be provided to the second player (hereinafter referred to as “provided object”) using the game object provided to the first player by the providing means and the parameter value. When,
Providing control means for performing control for providing the providing object to the second player;
Equipped with a,
The providing means determines the number of game objects to be provided to the first player, and provides the determined number of game objects to the first player,
The provided object determining means determines, based on the parameter value, a provided number of the provided objects that is equal to or less than a provided number of game objects provided to the first player by the providing means.
Server system.

Images