Patent Publication Number: US-2023140372-A1

Title: Video game with automated screen shots

Description:
CROSS-REFERENCE TO RELATED APPLICATION(S) 
     This application is a continuation of U.S. Application No. 17/025,502 filed Sep. 18, 2020, which is a continuation of U.S. Application No. 16/027,763 filed Jul. 5, 2018, which is based on and claims priority under 35 U.S.C. 119 from Japanese Patent Application No. 2017-138253 filed on Jul. 14, 2017. The entire contents of the above applications are incorporated herein by reference. 
    
    
     BACKGROUND 
     The present disclosure relates to a game processing program, a game processing method, and a game processing device that provide a game in which an image of a virtual space is generated. 
     In some known video games, a game view can be generated and saved in response to a user operation. Japanese Laid-Open Patent Publication No. 2017-56114 describes an example of a video game in which a user device operated by a user displays a game view corresponding to the user. When the user performs a photographing operation, the user device displays a photographing view, which is a game view in which an object other than the character operated by the user acts in a predetermined manner. Further, when the user performs a saving operation, a photographing view displayed on the user device is saved. 
     In the video game of Japanese Laid-Open Patent Publication No. 2017-56114, operation of the user triggers generation of a photographing view. Thus, especially in an action game, it is difficult to generate a photographing view while the user is playing the game. This requires interruption of game playing by the user and thus reduces the operability for the user. Additionally, such a reduced operability prevents the user from easily generating and posting a game view. Accordingly, the function to post a game view has not been in widespread use. 
     SUMMARY 
     In a game in which a game medium in a virtual space is controlled, it is an object of the present disclosure to provide a game processing program, a game processing method, and a game processing device that allow an image of the virtual space including the game medium to be generated with a simple operation. 
     To achieve the above object, one aspect of the present disclosure provides a non-transitory computer-readable medium that stores a computer-executable instruction. The instruction, when executed by circuitry of a system, causes the circuitry to obtain game medium information associated with a game medium in a virtual space, determine, when a predetermined event occurs, a generation condition for an image of the virtual space based on the game medium information, and generate an image including the game medium based on the generation condition. 
     Another aspect provides a method including obtaining, by circuitry of a system, game medium information associated with a game medium in a virtual space, determining, when a predetermined event occurs, by the circuitry, a generation condition for an image of the virtual space based on the game medium information; and generating, by the circuitry, an image including the game medium based on the generation condition. 
     A further aspect provides a system including circuitry. The circuitry is configured to obtain game medium information associated with a game medium in a virtual space, determine, when a predetermined event occurs, a generation condition for an image of the virtual space based on the game medium information, and generate an image including the game medium based on the generation condition. 
     Other aspects and advantages of the present disclosure will become apparent from the following description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the present disclosure. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present disclosure, together with objects and advantages thereof, may best be understood by reference to the following description of the presently preferred embodiments together with the accompanying drawings in which: 
         FIG.  1    is a schematic diagram illustrating the configuration of a device according to a first embodiment; 
         FIG.  2    is a schematic table illustrating one example of the data structure of game field information in the first embodiment; 
         FIGS.  3 A to  3 C  are schematic tables each illustrating one example of the data structure of object information in the first embodiment; 
         FIG.  4    is a schematic table illustrating one example of the data structure of a game history in the first embodiment; 
         FIG.  5    is a schematic table illustrating one example of the data structure of an image generation condition in the first embodiment; 
         FIG.  6    is a flowchart illustrating an image transmission process in the first embodiment; 
         FIG.  7    is a flowchart illustrating a determination process for the image generation condition in the first embodiment; 
         FIG.  8    is a flowchart illustrating a determination process for a message in the first embodiment; 
         FIGS.  9 A to  9 D  are diagrams illustrating a generation process for an image of a game field in the first embodiment; 
         FIGS.  10 A to  10 C  are schematic diagrams each illustrating an image of the game field in the first embodiment; 
         FIG.  11    is a flowchart illustrating an image transmission process in a second embodiment; 
         FIG.  12    is a flowchart illustrating a determination process for an image transmission condition in the second embodiment; 
         FIG.  13    is a flowchart illustrating a determination process for the image transmission condition in the second embodiment; 
         FIG.  14    is a flowchart illustrating a determination process for a message in the second embodiment; 
         FIGS.  15 A to  15 D  are diagrams illustrating a generation process for an image of the game field in the second embodiment; and 
         FIGS.  16 A to  16 D  are diagrams illustrating a generation process for an image of the game field in the second embodiment. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     First Embodiment 
     A game processing program, a game processing method, and a game processing device according to a first embodiment will now be described. In the present embodiment, the case of providing a user device  10  with a game in which characters battle with each other will be described. 
     User Device  10   
     The user device  10  is a computer terminal (game processing device) operated by a user. The user device  10  executes various applications and is used to output and input information. 
     As shown in  FIG.  1   , the user device  10  includes a controller  20 , a memory  30 , a transceiver  40 , and a display  50 . 
     The memory  30  includes game field information  31 , object information  32 , a game history  33 , an image generation condition  34 , and an image generation history  35 . 
     The game field information  31  is used to render the background of a game field, which is a three-dimensional virtual space. As shown in  FIG.  2   , the game field information  31  includes identification information of the game field (field ID) and attribute information of a geographic element included in the game field (for example, the type of geographic element, size, and position coordinates in the game field). 
     The object information  32  relates to the attribute of an object placed in the game field. As shown in  FIG.  3 A , the object information  32  includes information on the character placed in the game field as an object (for example, size (height) of the character). Further, as shown in  FIG.  3 B , the object information  32  includes information on a body placed in the game field as an object (for example, the size of the body). Further, as shown in  FIG.  3 C , the object information  32  includes information on an activity of the character in the game field (for example, the activity content of the character corresponding to input operation of the user). In the activity content of the character corresponding to the input operation of the user, for example, the character walks when the user taps a predetermined position and jumps when the user taps the predetermined position twice in a row (double-tap). 
     The game history  33  is history information of the character included in a scene of the game and is updated as the game progresses. As shown in  FIG.  4   , the game history  33  includes information on the type of activity of each character of the corresponding playing time point of the game (activity ID) and information on the state of each character (for example, the position coordinates in the game field, battle history, health value, and the amount of damage given to the opponent). 
     The image generation condition  34  defines a condition in which an image of a scene of the game is generated as a still image optimized based on the attribute of an object included in the scene during the game progress. As shown in  FIG.  5   , the image generation condition  34  includes information on a position serving as a viewpoint, a direction of a sight line, and the angle of view when the image of the scene of the game is generated. The image generation condition  34  differs depending on the attribute of the object included in the scene of the game. When the progress state of the game satisfies a predetermined condition (for example, the health value of the character is zero), the image generation condition  34  is determined based on the progress state of the game. 
     The image generation history  35  includes information on the image of the game field that has been generated based on the image generation condition  34  during the game progress. 
     The controller  20  functions as a game manager  21 , a display controller  22 , and an SNS processor  23  by executing the game processing program. 
     The game manager  21  receives an operation signal from an operation input interface  60  operated by the user. In response to the received operation signal, the game manager  21  identifies the state in which the character is operated by the user. 
     The game manager  21  manages the progress of the game by the user. More specifically, the game manager  21  moves the character in the game field based on the state of operation of the character by the user. Further, when the character operated by the user (user-operated character) approaches the character serving as a battle opponent, the game manager  21  starts a battle between the characters. 
     The game manager  21  holds trigger conditions for performing photographing (image generation). When an event in the game (for example, attacking, walking, or clearing of a difficult state) matches a content that is set as the trigger condition, the game manager  21  determines the image generation condition  34  based on the attribute of the object included in the scene of the game. Examples of the trigger condition include a condition in which the user-operated character performs a special attack such as a finishing move and a condition in which the user-operated character starts battling with a boss character, which is stronger than normal enemy characters (i.e., associated with a parameter value such as a higher health value or attack ability). Further, the game manager  21  generates an image of the game field based on the image generation condition  34 . In addition, the game manager  21  identifies a region of the generated image other than the object included in the image as a vacant space and appends a message to the vacant space. In this case, the game manager  21  may append a set phrase as a message or append a message generated based on the game history  33 . The game manager  21  adds the image of the game field including the appended message to the image generation history  35 . 
     The display controller  22  extracts the game field information  31  corresponding to the viewpoint of the user-operated character. The display controller  22  transmits the extracted game field information  31  to a display  50  as an image signal. Further, the display controller  22  extracts images of the user-operated character and the character serving as the battle opponent from the object information  32  and transmits information corresponding to the extracted images to the display  50  as an image signal. 
     The SNS processor  23  executes a process for using a social networking service (SNS). The SNS processor  23  retrieves an image of the game field generated during the game progress from the image generation history  35  and transmits the image to an SNS server  100  via the transceiver  40 . In this case, the SNS processor  23  may obtain a post history on an SNS and automatically select where to post based on the post history. Alternatively, the user may set on which SNS the user posts. The user may set where to post during the initial setting or when a predetermined event ends (for example, when a stage ends) in the game played by the user. 
     The transceiver  40  communicates with a server device or other user devices via a network. 
     Game Process 
     A process for transmitting an image of the game field generated during the game progress to the SNS server will now be described with reference to  FIGS.  6  to  8   . 
     The controller  20  determines whether or not the event in the game matches the trigger condition (step S 10 ). More specifically, the game manager  21  of the controller  20  monitors a progress state of the event in the game and compares the progress state with the trigger condition set in advance. 
     If the progress state of the event in the game matches the trigger condition (“YES” in step S 10 ), the controller  20  identifies an object included in the scene of the game (step S 20 ). More specifically, the game manager  21  of the controller  20  identifies the position of the user-operated character in the game field. Further, the game manager  21  identifies other objects located in the vicinity of the position of the character based on position information in the object information  32 . 
     Subsequently, the controller  20  determines the image generation condition  34  (step S 30 ). 
     As shown in  FIG.  7   , in a determination process for the image generation condition  34 , the controller  20  identifies the attribute of the object (step S 30 A). More specifically, the game manager  21  extracts the object information  32  of the object identified in step S 20  and obtains information on the character included in the scene of the game, information on a body included in the scene of the game, and information on an activity of the character. 
     Then, the controller  20  identifies the progress state of the game (step S 30 B). More specifically, the game manager  21  extracts the game history  33  of the character identified as the object in step S 20  and identifies information on the state of the character included in the scene of the game. 
     Afterwards, the controller  20  determines whether or not the progress state of the game satisfies a predetermined condition (step S 30 C). More specifically, the game manager  21  determines whether or not the state of the character identified in step S 30 B satisfies a condition suitable for determining the image generation condition  34 . For example, the condition suitable for determining the image generation condition  34  is that the health value of the character is zero. 
     If the progress state of the game satisfies the predetermined condition (YES in step S 30 C), the controller  20  determines the image generation condition  34  based on the progress state of the game (step S 30 D). More specifically, for example, when the health value of the character is zero, the game manager  21  of the controller  20  determines the image generation condition  34  for generating an image in which the character having a health value of zero is looked down at by setting, as a viewpoint position, the position of an enemy character serving as a battle opponent. 
     If the progress state of the game does not satisfy the predetermined condition (“NO” in step S 30 C), the controller  20  selects the image generation condition  34  corresponding to the attribute of the object (step S 30 E). More specifically, the game manager  21  obtains a character ID, a body ID, and an activity ID as an example of the attribute of the object included in the scene of the game and selects the image generation condition  34  corresponding to the combination of the obtained IDs. 
     Referring back to  FIG.  6   , the controller  20  generates an image of the game field (step S 40 ). More specifically, the game manager  21  retrieves information on the viewpoint position, direction, and angle of view defined in the image generation condition  34 . In the game field corresponding to the game field information  31 , the game manager  21  generates an image from the viewpoint coordinates in the game field identified based on the viewpoint position. 
     Subsequently, the controller  20  determines whether or not there is a vacant space in the generated image (step S 50 ). More specifically, the game manager  21  identifies a region of the image of the game field occupied by the object based on the position information in the object information  32 . The game manager  21  determines whether or not there is a region in the image of the game field other than the object. 
     If the controller  20  determines that there is a vacant space (“YES” in step S 50 ), the controller  20  determines a message to be displayed in the vacant space (step S 60 ). 
     As shown in  FIG.  8   , in a determination process for a message, the controller  20  identifies the attribute of the object (step S 60 A). More specifically, the game manager  21  extracts the object information  32  of the object identified in step S 20  and obtains information on the character included in the scene of the game, information on a body included in the scene of the game, and information on an activity of the character. 
     Then, the controller  20  identifies the progress state of the game (step S 60 B). More specifically, the game manager  21  extracts the game history  33  of the character identified as the object in step S 20  and identifies information on the state of the character included in the scene of the game. 
     Afterwards, the controller  20  determines whether or not the progress state of the game satisfies a predetermined condition (step S 60 C). More specifically, the game manager  21  determines whether or not the state of the character identified in step S 60 B satisfies a condition suitable for generating the message. For example, the condition suitable for generating the message is that there is a battle history with an enemy character and that the playing time of the game until reaching the current stage is within a limited time. 
     If the progress state of the game satisfies the predetermined condition (“YES” in step S 60 C), the controller  20  generates the message based on the progress state of the game (step S 60 D). More specifically, when there is a battle history with an enemy character, the game manager  21  generates a message including the number of times of battling with the enemy character (for example, “this is Xth challenge to the boss!”). Further, when the playing time of the game until reaching the current stage is within a limited time, the game manager  21  generates a message including the playing time of the game (for example, “Y hours until this stage!”). 
     If the progress state of the game does not satisfy the predetermined condition (“NO” in step S 60 C), the controller  20  selects the message corresponding to the attribute of the object (step S 60 E). More specifically, the game manager  21  obtains a character ID, a body ID, and an activity ID as an example of the attribute of the object included in the scene of the game and selects the message corresponding to the combination of the obtained IDs. 
     Referring back to  FIG.  6   , the controller  20  appends the message to the image of the game field (step S 70 ). More specifically, the game manager  21  appends the generated message as described above to the vacant space in the image of the game field. 
     If the controller  20  determines that there is no vacant space (“NO” in step S 50 ), the controller  20  does not append the message to the image of the game field. 
     Subsequently, the controller  20  saves the image of the game field in the memory  30  (step S 80 ). More specifically, when there is a vacant space in the image of the game field, the game manager  21  adds the image of the game field, to which the message is appended, to the image generation history  35 . When there is no vacant space, the game manager  21  adds the image of the game field generated based on the image generation condition  34  to the image generation history  35 . 
     Then, the controller  20  posts the image on an SNS (step S 90 ). More specifically, the SNS processor  23  retrieves the image of the game field generated during the game progress from the image generation history  35  and transmits the image to the SNS server  100  via the transceiver  40 . 
     The images of the game field generated during the game progress will now be described with reference to  FIGS.  9 A to  9 D . 
       FIG.  9 A  schematically shows the positional relationship of objects S 1  to S 4  on the game field in a scene of the game. As shown in  FIG.  9 A , the game manager  21  sets, as a play view, the image viewed from a virtual camera X 1 . 
     As shown in  FIG.  9 B , in the present embodiment, the display controller  22  displays the image in which the objects S 1  to S 4  on the game field are viewed from the front on the display  50  as a play view. That is, the display controller  22  controls the display  50  so as to display the image. In this case, the display controller  22  displays the object S 1  (structure) placed in the game field as a body, the user-operated object S 2  (ally character), and the battle opponent objects S 3  and S 4  (enemy characters) on the display  50 . 
     Further, as shown in  FIG.  9 A , the game manager  21  sets the image viewed from a virtual camera X 2  on the game field as a generated view. 
     As shown in  FIG.  9 C , in the present embodiment, the game manager  21  sets, as a generated view, the image in which the objects on the game field are obliquely viewed with the user-operated object located in the center. In this case, the game manager  21  sets, as a generated view, the image including the user-operated object S 2  (ally character) and the object S 3  (enemy character) facing the object S 2 . 
     Additionally, as shown in  FIG.  9 D , the game manager  21  identifies the vacant space in the generated view shown in  FIG.  9 C  and appends a message to the identified vacant space. In this case, the game manager  21  generates a message M 1  based on the game history  33 . More specifically, as the game progresses, when the object S 2  (ally character) was previously defeated by the battling opponent object S 3  (enemy character), the game manager  21  generates the message M 1  reflecting the defeat. The game manager  21  appends the generated message M 1  to the vicinity of the user-operated object S 2  (ally character). 
     Another example of images of the game field generated during the game progress will now be described with reference to  FIGS.  10 A to  10 C . 
       FIG.  10 A  shows an example in which the image generation condition  34  is determined based on the size of an object included in the scene of the game. In this case, the size of the user-operated object S 2  (ally character) is smaller than that of a battling opponent object S 3   a  (enemy character). Thus, the game manager  21  generates the image of the game field from the viewpoint in which the user-operated object S 2  looks up at the battling opponent object S 3   a . 
       FIG.  10 B  shows an example in which the image generation condition  34  is determined based on the relative positions of multiple objects included in the scene of the game. In this case, the game manager  21  generates the image of the game field from the viewpoint in which the user-operated object S 2  (ally character) and a battling opponent object S3β (enemy character) are viewed laterally. 
       FIG.  10 C  shows an example in which the image generation condition  34  is determined based on the attribute of the object included in the scene of the game and the background of the game field. In this case, the game manager  21  generates the image of the game field from the viewpoint in which the user-operated object S 2  (ally character) and a battling opponent object S 3   y  (enemy character) are viewed laterally so as to include a geographic element ST (sun) serving as the background of the game field. 
     As described above, the first embodiment has the following advantages. 
     (1-1) In the first embodiment, when a scene of the game matches a content set as a trigger condition, the image generation condition  34  is determined based on the attribute of an object included in the scene of the game. The image of the game field including the object is generated based on the determined image generation condition  34 . This allows the image of the game field including the object to be automatically generated without operation of the user. 
     (1-2) In the first embodiment, the image generation condition  34  is determined based on the size of the object included in the scene of the game, the relative positions of multiple objects, and the background of the game field. This allows a wide variety of images of the game field to be provided. 
     (1-3) In the first embodiment, the message M 1  is displayed in a region of the image of the game field other than the object included in the image. This allows the message M 1  to be displayed without interfering with the object included in the image of the game field. Further, the appending of the message to the scene of the game allows other users to easily acknowledge what the scene is. Additionally, when a message is automatically appended, the user saves time to post the message. 
     (1-4) In the first embodiment, the image generation condition  34  is determined based on the attribute of the object set in advance in the memory  30  and the attribute of the object that is changed when the game progresses. This allows for a wide variety of images of the game field generated based on the attribute of the object. 
     (1-5) In the first embodiment, the message M 1  is generated based on the game history  33  that accumulates as the game progresses. This allows for a wide variety of images of the message M 1  displayed in the image of the game field. 
     (1-6) When other users check a wide variety of posted images, users who have already played the game and users who have not played the game are both motivated to play the game. 
     Second Embodiment 
     A game processing program, a game processing method, and a game processing device according to a second embodiment will now be described. In the second embodiment, the determination process for an image generation condition and the determination process for a message in the first embodiment are partially modified. Like or same reference numerals are given to those components that are the same as the corresponding components of the first embodiment. Such components will not be described in detail. 
     In the game of the second embodiment, an image of the game field is generated as the game progresses in the same manner as the first embodiment. In the second embodiment, it is assumed that two users advance the game simultaneously, and the object (ally character) operated by each user is placed in a common game field. The image generation condition is determined based on the relative positions of the objects in the game field. More specifically, when the positions of the objects in the game field are proximate to each other, the image generation condition is determined so as to generate an image including both objects. When the positions of the objects in the game field are spaced apart from each other, the image generation condition is determined so as to generate an image including only the object operated by one of the users. 
     As shown in  FIG.  11   , the controller  20  determines whether or not the event in the game matches the trigger condition (step S 110 ) in the same manner as step S 10 . 
     If the progress state of the event in the game matches the trigger condition (“YES” in step S 110 ), the controller  20  identifies an object included in the scene of the game (step S 120 ) in the same manner as step S 20 . 
     Subsequently, the controller  20  identifies the user operating each object included in the scene of the game (step S 130 ). More specifically, the game manager  21  identifies the user operating each object by performing communication with the user devices  10  operated by other users via the transceiver  40 . 
     Then, the controller  20  determines whether or not the number of users is two or more (step S 140 ). More specifically, the game manager  21  calculates the number of the identified users. 
     If the number of the users is two or more (“YES” in step S 140 ), the controller  20  determines whether or not the user-operated objects are proximate to each other (step S 150 ). More specifically, the game manager  21  extracts the object information  32  of the user-operated objects and identifies the position coordinates of each object in the game field. The game manager  21  compares the distance between the objects in the game field with threshold values. 
     If the user-operated objects are proximate to each other (“YES” in step S 150 ), the controller  20  uses a first method to determine the image generation condition  34  (step S 160 ). 
     As shown in  FIG.  12   , in a determination process for the image generation condition  34  using the first method, the controller  20  identifies the attributes of objects of multiple users (step S 160 A). More specifically, the game manager  21  obtains information on multiple user-operated characters identified in step S 130  and information on the activities of the characters based on the object information  32 . Further, the game manager  21  obtains information on a body located in the vicinity of each user-operated character based on the object information  32 . 
     Subsequently, the controller  20  identifies progress states of the game of the multiple users (step S 160 B). More specifically, the game manager  21  extracts the game history  33  of the multiple user-operated characters identified in step S 130  and obtains information on the state of each user-operated character. 
     Then, the controller  20  determines whether or not any one of the progress states of the game of the user satisfies a predetermined condition (step S 160 C). More specifically, the game manager  21  determines whether or not at least one of the progress states of the user-operated characters identified in step S 160 B satisfies the condition suitable for determining the image generation condition  34 . 
     If at least one of the progress states of the game satisfies the predetermined condition (“YES” in step S 160 C), the controller  20  determines the image generation condition  34  based on the progress state of the game satisfying the predetermined condition (step S 160 D). More specifically, when at least one of the progress states of the user-operated characters satisfies the condition suitable for determining the image generation condition  34 , the game manager  21  determines the image generation condition  34  for generating an image suitable for the state of the character. In this case, the game manager  21  determines the image generation condition  34  so as to generate an image including the two user-operated characters based on the attributes of the objects of the multiple users identified in step S 160 A. 
     If the predetermined condition is not satisfied by any one of the progress states of the game (“NO” in step S 160 C), the controller  20  selects the image generation condition  34  corresponding to the attributes of the objects of the multiples users (step S 160 E). More specifically, the game manager  21  obtains character IDs, body IDs, and activity IDs as an example of the attributes of the objects of the multiple users identified in step S 160 A and selects the image generation condition  34  corresponding to the combination of the obtained IDs. 
     Referring back to  FIG.  11   , if the user-operated objects are spaced apart from each other (“NO” in step S 150 ), the controller  20  uses a second method to determine the image generation condition  34  (step S 170 ). 
     As shown in  FIG.  13   , in a determination process for the image generation condition  34  using the second method, the controller  20  identifies the attribute of an object of a first user (step S 170 A). More specifically, the game manager  21  obtains information on the character operated by the first user identified in step S 130  (first user-operated character) and information on the activity of the character based on the object information  32 . Further, the game manager  21  obtains information on a body located in the vicinity of the first user-operated character based on the object information  32 . 
     Subsequently, the controller  20  identifies the progress state of the game of the first user (step S 170 B). More specifically, the game manager  21  extracts the game history  33  of the first user-operated character identified in step S 130  and obtains information on the state of the first user-operated character. 
     Then, the controller  20  determines whether or not the progress state of the game of the first user satisfies a predetermined condition (step S 170 C). More specifically, the game manager  21  determines whether or not the progress state of the first user-operated character identified in step S 170 B satisfies the condition suitable for determining the image generation condition  34 . 
     If the progress state of the game satisfies the predetermined condition (“YES” in step S 170 C), the controller  20  determines the image generation condition  34  based on the progress state of the game (step S 170 D). More specifically, when the progress state of the first user-operated character satisfies the condition suitable for determining the image generation condition  34 , the game manager  21  determines the image generation condition  34  for generating an image suitable for the state of the character. In this case, the game manager  21  determines the image generation condition  34  in which the first user-operated character is included in the image based on the attribute of the object of the first user identified in step S 170 A. 
     If the progress state of the game does not satisfy the predetermined condition (“NO” in step S 170 C), the controller  20  selects the image generation condition  34  corresponding to the attribute of the object of the first user (step S 170 E). More specifically, the game manager  21  obtains a character ID, a body ID, and an activity ID as an example of the attribute of the object of the first user identified in step S 170 A and selects the image generation condition  34  corresponding to the combination of the obtained IDs. 
     Referring back to  FIG.  11   , the controller  20  generates an image of the game field (step S 180 ) in the same manner as step S 40 . 
     Subsequently, the controller  20  determines whether or not there is a vacant space in the generated image (step S 190 ) in the same manner as step S 50 . 
     If the controller  20  determines that there is a vacant space (“YES” in step S 190 ), the controller  20  determines a message to be displayed in the vacant space (step S 200 ). 
     As shown in  FIG.  14   , in a determination process for a message, the controller  20  determines whether or not the image generation condition  34  is determined using the first method (step S 200 A). More specifically, the game manager  21  determines whether or not the number of users is two or more and whether or not the user-operated objects are proximate to each other. 
     If the image generation condition  34  is determined using the first method (“YES” in step S 200 A), the controller  20  identifies the attributes of objects of multiple users (step S 200 B). More specifically, the game manager  21  obtains information on multiple user-operated characters identified in step S 130  and information on the activities of the characters based on the object information  32 . Further, the game manager  21  obtains information on a body located in the vicinity of each user-operated character based on the object information  32 . 
     Subsequently, the controller  20  identifies the progress states of the game of the multiple users (step S 200 C). More specifically, the game manager  21  extracts the game history  33  of the multiple user-operated characters operated identified in step S 130  and obtains information on the state of each user-operated character. 
     Then, the controller  20  determines whether or not any one of the progress states of the game of the user satisfies a predetermined condition (step S 200 D). More specifically, the game manager  21  determines whether or not at least one of the progress states of the user-operated characters identified in step S 200 C satisfies the condition suitable for generating the message. 
     If at least one of the progress states of the game satisfies the predetermined condition (“YES” in step S 200 D), the controller  20  generates the message based on the progress state of the game satisfying the predetermined condition (step S 200 E). More specifically, when at least one of the progress states of the user-operated characters satisfies the condition suitable for generating the message, the game manager  21  generates the message suitable for the state of the character. 
     If the predetermined condition is not satisfied by any one of the progress states of the game (“NO” in step S 200 D), the controller  20  selects the message corresponding to the attributes of the objects of the multiples users (step S 200 F). More specifically, the game manager  21  obtains character IDs, body IDs, and activity IDs as an example of the attributes of the objects of the multiple users identified in step S 130  and selects the message corresponding to the combination of the obtained IDs. 
     Additionally, if the image generation condition  34  is not determined using the first method, that is, if the image generation condition  34  is determined using the second method (“NO” in step S 200 A), the controller  20  identifies the attribute of an object of the first user (step S 200 G). More specifically, the game manager  21  obtains information on the first user-operated character identified in step S 130  and information on the activity of the character based on the object information  32 . Further, the game manager  21  obtains information on a body located in the vicinity of the first user-operated character based on the object information  32 . 
     Subsequently, the controller  20  identifies the progress state of the game of the first user (step S 200 H). More specifically, the game manager  21  extracts the game history  33  of the first user-operated character identified in step S 130  and obtains information on the state of the first user-operated character. 
     Then, the controller  20  determines whether or not the progress state of the game satisfies a predetermined condition (step S 200 I). More specifically, the game manager  21  determines whether or not the progress state of the first user-operated character identified in step S 200 H satisfies the condition suitable for generating the message. 
     If the progress state of the game satisfies the predetermined condition (“YES” in step S 200 I), the controller  20  generates the message based on the progress state of the game (step S 200 J). More specifically, when the progress state of the first user-operated character satisfies the condition suitable for generating the message, the game manager  21  generates a message suitable for the state of the character. 
     If the predetermined condition is not satisfied by the progress state of the game (“NO” in step S 200 I), the controller  20  selects the message corresponding to the attribute of the object of the first user (step S 200 K). More specifically, the game manager  21  obtains a character ID, a body ID, and an activity ID as an example of the attribute of the object of the first user identified in step S 130  and selects the message corresponding to the combination of the obtained IDs. 
     Referring back to  FIG.  11   , the controller  20  appends the message to the image of the game field (step S 210 ) in the same manner as step S 70 . 
     If the controller  20  determines that there is no vacant space (“NO” in step S 190 ), the controller  20  does not append the message to the image of the game field. 
     Subsequently, the controller  20  saves the image of the game field in the memory  30  (step S 220 ) in the same manner as step S 80 . 
     Afterwards, the controller  20  determines whether or not the image of the game field includes multiple user-operated objects (step S 230 ). More specifically, the SNS processor  23  refers to the object information  32  associated with the image of the game field to identify the user who operates each object. The controller  20  determines whether or not the number of users operating the object is two or more. 
     If the image of the game field includes multiple user-operated objects (“YES” in step S 230 ), the controller  20  tags the image to the users operating the user-operated objects and posts the tagged image on the SNS (step S 240 ). More specifically, the SNS processor  23  retrieves the image of the game field generated during the game progress from the image generation history  35  and extracts information on the users identified from the image of the game field. The SNS processor  23  associates the information on the user with the image of the game field and transmits the information to the SNS server  100  via the transceiver  40 . 
     If the image of the game field does not include multiple user-operated objects (“NO” in step S 230 ), the controller  20  posts the image on the SNS (step S 250 ). More specifically, the SNS processor  23  retrieves the image of the game field generated during the game progress from the image generation history  35  and transmits the image to the SNS server  100  via the transceiver  40 . 
     The images of the game field generated when multiple user-operated objects are proximate to each other will now be described with reference to  FIGS.  15 A to  15 D . 
       FIG.  15 A  schematically shows the positional relationship of objects S 11  to S 15  on the game field in a scene of the game. As shown in  FIG.  15 A , the game manager  21  sets the image viewed from a virtual camera X 11  as a play view. 
     As shown in  FIG.  15 B , in the present embodiment, the display controller  22  displays, on the display  50  as a play view, the image in which the objects S 11  to S 15  on the game field are viewed from the front. In this case, the display controller  22  displays the object S 11  (structure) placed in the game field as a body, the object S 12  operated by the first user (first user-operated object, ally character), the object S 13  operated by the second user (second user-operated object, ally character), and the battle opponent objects S 14  and S 15  (enemy characters) on the display  50 . 
     Further, as shown in  FIG.  15 A , the game manager  21  sets, as a generated view, the image viewed from a virtual camera X 12  on the game field. 
     As shown in  FIG.  15 C , in the present embodiment, the game manager  21  sets, as a generated view, the image in which the objects on the game field are obliquely viewed based on the relative positions of the first user-operated object S 12  and the second user-operated object S 13 . In this case, the game manager  21  sets, as the generated view, the image including the first user-operated object S 12  (ally character) and the second user-operated object S 13  (ally character). 
     Further, as shown in  FIG.  15 D , the game manager  21  identifies the vacant space in the generated view shown in  FIG.  15 C  and appends a message to the identified vacant space. In this case, the game manager  21  generates a message M 2  based on information on the second user. More specifically, when the first-user operated object S 12  (ally character) and the second user-operated object S 13  (ally character) simultaneously attack the battle opponent objects S 14  and S 15  (enemy characters), the game manager  21  generates the message M 2  reflecting the attack. The game manager  21  appends the generated message M 2  to the vicinity of the first user-operated object S 12 . 
     The images of the game field generated when multiple user-operated objects are spaced apart from each other will now be described with reference to  FIGS.  16 A to  16 D . 
       FIG.  16 A  schematically shows the positional relationship of objects S 11  to S 15  on the game field in a scene of the game. As shown in  FIG.  16 A , the game manager  21  sets the image viewed from the virtual camera X 11  as a play view. 
     As shown in  FIG.  16 B , in the present embodiment, the display controller  22  displays, on the display  50  as a play view, the image in which the objects S 11  to S 15  on the game field are viewed from the front. In this case, the display controller  22  displays the object S 11  (structure) placed in the game field as a body, the first user-operated object S 12  (ally character), the second user-operated object S 13  (ally character), and the battle opponent objects S 14  and S 15  (enemy characters) on the display  50 . 
     Further, as shown in  FIG.  16 A , the game manager  21  sets, as a generated view, the image viewed from a virtual camera X 13  on the game field. 
     As shown in  FIG.  16 C , in the present embodiment, the game manager  21  sets, as a generated view, the image in which the objects on the game field are obliquely viewed based on the position of the first user-operated object S 12 . In this case, the game manager  21  sets, as the generated view, the image including the first user-operated object S 12  (ally character) without including the second user-operated object S 13  (ally character). 
     Further, as shown in  FIG.  16 D , the game manager  21  identifies the vacant space in the generated view shown in  FIG.  16 C  and appends a message to the identified vacant space. In this case, the game manager  21  generates a message M 3  based on the attribute of the first user-operated object S 12 . More specifically, when the first user-operated object S 12  (ally character) performs a special attack, the game manager  21  generates the message M 3  reflecting the special attack. The game manager  21  appends the generated message M 3  to the vicinity of the first user-operated object S 12 . 
     As described above, the second embodiment has the following advantages in addition to the advantages of the first embodiment. 
     (2-1) In the second embodiment, the image generation condition  34  is determined so that multiple user-operated objects in the game field are included in an image. This allows the image of the game field to be generated so as to indicate the relationship of the objects in the scene of the game. 
     (2-2) In the second embodiment, multiple user-operated objects included in an image are determined based on the relative positions of the objects. Thus, the combination of the objects included in the image of the game field can be changed depending on the scene of the game. 
     (2-3) In the second embodiment, other users who operate objects included in a scene of the game are identified, the identified users are tagged to an image, and the tagged image is transmitted to the SNS server  100 . This allows the image of the game field, in which multiple users are associated with each other, to be transmitted and thus spreads the image of the game field on the SNS. 
     (2-4) In the second embodiment, a wide variety of posted images are checked by other users on the SNS. This motivates them to play the game. 
     Each of the above embodiments may be modified as described below. 
     In the description of the second embodiment, the game in which two users play the game is provided. Instead, a game in which three or more users play the game may be provided. In this case, when three or more user-operated objects are proximate to each other, the controller  20  may determine the image generation condition  34  so that the image includes all the objects. This allows for generation of an image of the game field that can gain sympathy of many users. 
     In the second embodiment, other users operating the object S 13  included in the scene of the game are tagged to the image, and the tagged image is transmitted to the SNS server  100 . The transmission of the image of the game field may not involve tagging other users to the image. For example, the controller  20  may transmit the image of the game field to a shared folder of an external server, which is shared among multiple users. Further, the controller  20  may change the SNS server  100 , to which the image of the game field is transmitted, for each of the users. This facilitates each user to manage the image of the game field. As a result, each user views the image of the game field more frequently and is thus motivated to play the game. 
     In the second embodiment, objects to be included in the image are determined based on the relative positions of multiple user-operated objects. The objects to be included in the image do not have to be determined based on the relative positions of multiple user-operated objects. For example, the controller  20  may set priority as the attribute of an object and determine the image generation condition  34  so as to generate the image having the highest priority. Further, the controller  20  may determine the image generation condition  34  without taking into consideration the relative positions of multiple user-operated objects in the game field. In this case, the controller  20  may determine the image generation condition  34  so as to generate the image including multiple user-operated objects. Thus, regardless of the relative positions of multiple user-operated objects in the game field, an image in which multiple users are forming a party and playing the game can be generated. When such an image is posted on the SNS, a person viewing the image is motivated to play the game. Alternatively, the controller  20  may determine the image generation condition  34  so as to generate an image including only one of the user-operated objects. Thus, regardless of the relative positions of multiple user-operated objects in the game field, an image in which a single user is uniquely playing the game can be generated. When such an image is posted on the SNS, a person viewing the image is motivated to play the game. 
     In each of the above embodiments, a message is generated based on the game history  33 , which accumulates as the game progresses. The message does not have to be generated based on the game history  33 . For example, the controller  20  may generate a message based on an activity history of the user obtained through an information processing terminal, for example, a posting history on the SNS and a browsing history on the internet. This allows for generation of a message matching features of the user. 
     In each of the above embodiments, a message is displayed in a region of the image of the game field other than the object in the image. The display position of a message does not have to be determined based on a region of the image occupied by the object. For example, the controller  20  may narrow down the display position of the message in a vacant space of the image of the game field based on the attribute of the object. This optimizes the display position of the message and increases the effect of rendering the game. Further, the controller  20  may determine the display position of the message based on the attribute of the object without taking into consideration the region of the image occupied by the object. This allows the message to be displayed without limiting the number of characters. 
     In each of the above embodiments, a message is appended to the image of the game field when there is a vacant space. The controller  20  does not have to append a message to the image of the game field regardless of whether or not there is a vacant space. This prevents the image of the game field from being interfered with by a displayed message and thus avoids situations in which the message lowers the high artistry of the image of the game field such as an image photographed by a photographer. 
     In each of the above embodiments, the parameter related to a user-operated object (for example, the position and size of the object) is applied as the attribute of the object used to determine the image generation condition  34 . Instead, the type of an item used for battle by the user-operated object (for example, an ax and a bow) may be applied as the attribute of the object used to determine the image generation condition  34 . In this case, a region influenced by the effect of the item may be factored in the image generation condition. For example, subsequent to the image illustrating the moment the character draws an arrow with a bow, the angle of view may be enlarged so as to generate an image including both the character, which drew the bow, and the shot arrow. In contrast, in the case of an item held by the character when in use (for example, an ax), the image can be generated in the angle of view approaching the character. This allows a wider variety of images of the game field to be generated. 
     In each of the above embodiments, the information on the position, direction, and angle of view serving as the viewpoint when generating an image is determined as the image generation condition  34  based on the attribute of the object included in the scene of the game. That is, the composition when generating an image is determined based on the attribute of the object included in the scene of the game. The information determined as the image generation condition  34  is not limited to information on the composition of an image. For example, the controller  20  may determine the timing of generating an image as the game progresses based on the attribute of the object included in the scene of the game. In this case, the controller  20  may determine the timing of generating an image in addition to the composition of the image based on the attribute of the object included in the scene of the game. Alternatively, whereas the player manually sets the composition of the image, the controller  20  may determine the timing of generating an image based on the attribute of the object. As another option, whereas the controller  20  automatically determines the image generation condition  34  based on the attribute of the object, the player may manually determine a message subject to display. Conversely, whereas the player manually sets the image generation condition  34 , the controller  20  may automatically determine a message subject to display based on the attribute of the object. 
     In each of the above embodiments, the image of the game field is generated as a still image. Instead, the image of the game field may be generated as a moving image. Thus, a further realistic, appealing image of the game field can be posted on the SNS. 
     In each of the above embodiments, at least some of the operations and processes executed by the user device may be executed by a server device connected to the user device. For example, any one of the server device and the user device may execute the processes of, for example, display control on various views displayed in the user device and control on various GUIs. As another option, the server device and the user device may cooperate to execute the processes of display control on various views and control on various GUIs. For example, some of the various game views may be displayed by the user device based on the data generated by the server device (i.e., web view), and other game views may be displayed by a native application, which is installed in the user device (i.e., native view). In this manner, the game according to each of the above embodiments may be a hybrid game in which the server device and the user device are each in charge of some of the processes. 
     An information processing device such as a computer or a mobile phone may be used in a preferred manner in order for the information processing device to function as the server device or the user device according to each of the above embodiments. Such an information processing device can be implemented by storing, in a memory of the information processing device, a program describing the processing content that implements the functions of the server device or the user device according to the embodiments and then reading and executing the program with the CPU of the information processing device. 
     In the description of each of the above embodiments, the case of providing the game in which objects battle with each other is described as an example of a game. The present disclosure may be applied to other games such as a simulation game in which the player progresses in the game field from the viewpoint of objects placed in the game field. That is, as long as the game controls objects in the game field, the present disclosure may be applied. 
     The controller  20  is not limited to one that performs software processing on all processes executed by itself. For example, the controller  20  may be equipped with a dedicated hardware circuit (e.g., application specific integrated circuit: ASIC) that performs hardware processing on at least some of the processes to be executed by itself. That is, the controller  20  may be configured as 1) one or more processors that operate in accordance with a computer program (software), 2) one or more dedicated hardware circuits that execute at least some of the various processes, or 3) circuitry including combinations thereof. The processor includes a CPU and memories such as a RAM and a ROM, and the memory stores program codes or instructions configured to cause the CPU to execute the processing. The memories, that is, computer-readable media, include any type of media that are accessible by general-purpose computers and dedicated computers.