Game program, game system, game device, and game processing method

The game system addresses the challenge of mirror-inverted controller images by displaying rotating model objects and using inertial sensors to evaluate player movements, enhancing orientation clarity and reducing operational errors.

JP7824912B2Active Publication Date: 2026-03-05NINTENDO CO LTD
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
JP2023121939
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Filing Date
2023-07-26
Publication Date
2026-03-05
Estimated Expiration
2043-07-26

AI Technical Summary

Technical Problem

Players often struggle to determine whether a controller holding image is mirror-inverted, leading to potential errors in operation, especially in asymmetrical stances.

Method used

A game system that displays a model object rotating to show controller holding poses, accompanied by action instructions, and evaluates player movements using inertial sensors to prevent confusion and ensure correct orientation.

Benefits of technology

Facilitates easy understanding of controller orientation, reducing errors and ensuring players are prepared for games by clearly distinguishing between mirror-inverted and correct poses.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007824912000001
    Figure 0007824912000001
  • Figure 0007824912000002
    Figure 0007824912000002
  • Figure 0007824912000003
    Figure 0007824912000003
Patent Text Reader

Abstract

To enable display of a holding posture image that allows a player to easily recognize the orientation.SOLUTION: A game program causes a computer to display a model image in which a model object that imitates a player holding a controller takes a preset posture according to the type of game during a waiting period before a game starts, and to display a model image as animation that rotates from the orientation in which the front side of the model object is displayed to the orientation in which at least a portion of the back side of the object is displayed.SELECTED DRAWING: Figure 9
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present disclosure relates to information processing for games and the like. [Background technology]

[0002] Conventionally, there have been games in which an image showing how to hold a controller is displayed before the game starts (for example, Non-Patent Document 1). [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] Nintendo Co., Ltd., "WarioWare Dancing," [online], [Retrieved July 11, 2023], Internet (URL: https: / / www.nintendo.co.jp / wii / rodj / soft_info / index.html) Summary of the Invention [Problem to be solved by the invention]

[0004] When a player holds a controller in each hand, it is conceivable that the player will not be able to instantly determine whether the image showing how to hold the controller is a mirror-inverted image (i.e., an image displayed as if reflected in a mirror) or not. In particular, when an asymmetrical stance (controller holding position) is required, there is a possibility that a player will make an error in operation if they hold the controller incorrectly.

[0005] Therefore, an object of the present invention is to provide a game program, a game system, a game device, and a game processing method that are capable of displaying a holding image that allows a player to easily grasp the orientation. [Means for solving the problem]

[0006] To achieve the above object, the following configuration examples can be given.

[0007] A first configuration example is a game program that causes a computer of an information processing device to execute multiple types of games in succession, and for each game to be executed in succession, the computer displays, during a waiting period before the start of the game, a model image in which a model object representing a player holding a controller strikes a pose that is preset according to the type of game, and for a first type of game, the computer displays the model image as an animation in which the model object rotates from an orientation in which the front of the model object is displayed to an orientation in which at least a portion of its back is displayed, and starts the game after the waiting period, and displays at least action instructions indicating actions to be performed by the player in the game, and evaluates the movement of the controller based on operation data obtained from a controller equipped with an inertial sensor, and progresses the game based on the evaluation.

[0008] According to the first configuration example described above, by rotating the model object, it becomes easier to understand that the model object is not displayed in a mirror-inverted state, and when playing games consecutively, it is possible to prevent the player from being late in preparing for the game.

[0009] In a second configuration example, in the first configuration example, during a waiting period, the computer is made to display an example image of an example object that resembles a player holding a controller in each hand, and in the game, is made to perform an evaluation based on first operation data obtained from the first controller and second operation data obtained from the second controller.

[0010] According to the second configuration example described above, when playing a game with a controller held in each hand, there is no confusion as to whether the model object is displayed in a mirror-inverted state or not.

[0011] In a third configuration example, in the second configuration example, the first type of game includes a second type of game in which a pose that is asymmetrical with respect to the example object is set.

[0012] According to the third configuration example described above, in games where players take asymmetric stances, whether the model object is displayed with the left and right reversed is a particular issue, but this problem can be significantly resolved.

[0013] A fourth configuration example is the third configuration example, in which, at a predetermined scene before a plurality of types of games are executed in succession, the computer is caused to set which of the player's left or right hand will be the dominant hand, and for a second type of game, depending on the set dominant hand, the model object is made to assume a first pose or a second pose that is a mirror image of the first pose in the model video display, and the first operation data and second operation data used for evaluation are swapped in the game to perform the evaluation.

[0014] According to the fourth configuration example described above, by setting the dominant hand, in a game in which the player takes an asymmetric stance, the display of the object to be operated can be reversed to play the game.

[0015] A fifth configuration example is a second configuration example in which the computer is caused to display, for a third type of game included in the first type of game, a model image as an animation that rotates from a direction in which the front of the model object is displayed to a direction in which the diagonally rear part is displayed, and for a fourth type of game included in the first type of game, the computer is caused to display, for a fourth type of game included in the first type of game, a model image as an animation that rotates from a direction in which the front of the model object is displayed to a direction in which the rear part is displayed.

[0016] In the sixth configuration example, in the fifth configuration example, the third type of game is a game in which a pose is set in which the left and right hands are positioned in front of the example object.

[0017] According to the sixth configuration example described above, it is possible to prevent the part of the hand holding the controller of the example object from being hidden by the body.

[0018] The seventh configuration example is a fifth type of game in which a pose that is symmetrical to the model object is set on the computer in the second configuration example, and which is not included in the first type of game, and in which the model image is displayed as an animation in which the front or back of the model object remains facing in that direction.

[0019] According to the seventh configuration example described above, for some games in which the object to be operated is symmetrical, whether or not it is flipped left to right is not an issue, so it is possible to create an animation in which the model object is displayed facing forward or backward.

[0020] An eighth configuration example is any one of the first to seventh configuration examples, in which a computer displays a model image by drawing a model object in a virtual space based on a virtual camera, and for a first type of game, the model image is displayed by rotating the model object or the virtual camera from a position where the front of the model object faces the virtual camera to a position where the rear or diagonally rear of the model object faces the virtual camera.

[0021] A ninth configuration example is the eighth configuration example in which the computer is caused to rotate the model object or the virtual camera in the model image for the first type of game, and to animate the model object posing, and display the model image.

[0022] According to the above-mentioned ninth configuration example, the example object poses using animation, making it easier to understand. [Effects of the Invention]

[0023] According to this embodiment, it is possible to provide a game program, a game system, a game device, and a game processing method that are capable of displaying a holding image that allows the player to easily grasp the orientation. [Brief explanation of the drawings]

[0024] [Figure 1]FIG. 1 shows an example of a state in which the left controller 3 and the right controller 4 are attached to the main unit 2. [Figure 2] FIG. 10 shows an example of a state in which the left controller 3 and the right controller 4 are detached from the main unit 2. [Figure 3] Six-sided views showing an example of the main unit 2 [Figure 4] Six-sided diagram showing an example of the left controller 3 [Figure 5] Six-sided diagram showing an example of the right controller 4 [Figure 6] A block diagram showing an example of the internal configuration of the main unit 2. [Figure 7] A block diagram showing an example of the internal configuration of the main unit 2, the left controller 3, and the right controller 4. [Figure 8] A diagram showing an example of a left controller 3 and a right controller 4 with strings attached. [Figure 9] FIG. 10 is a diagram illustrating an example of an example video in which an example object holding a controller strikes a pose. [Figure 10] FIG. 1 is a diagram illustrating an example of a short game [Figure 11] FIG. 10 is a diagram illustrating an example of an example video in which an example object holding a controller strikes a pose. [Figure 12] FIG. 1 is a diagram illustrating an example of a short game [Figure 13] FIG. 10 is a diagram illustrating an example of an example video in which an example object holding a controller strikes a pose. [Figure 14] FIG. 1 is a diagram illustrating an example of a short game [Figure 15] FIG. 10 is a diagram illustrating an example of an example video in which an example object holding a controller strikes a pose. [Figure 16] FIG. 1 is a diagram illustrating an example of a short game [Figure 17] FIG. 10 shows an example of various data stored in the DRAM 85. [Figure 18] Example of a flowchart of game processing DETAILED DESCRIPTION OF THE INVENTION

[0025] An embodiment will be described below.

[0026] [Hardware configuration of information processing system]

[0027] An information processing system (game system) according to an example of this embodiment will be described below. An example of a game system 1 according to this embodiment includes a main unit (information processing device; in this embodiment, it functions as a game device main unit) 2, a left controller 3, and a right controller 4. The left controller 3 and the right controller 4 are each detachable from the main unit 2. In other words, the game system 1 can be used as an integrated device by attaching the left controller 3 and the right controller 4 to the main unit 2. The game system 1 can also be used by separating the main unit 2 from the left controller 3 and the right controller 4 (see FIG. 2). Below, the hardware configuration of the game system 1 according to this embodiment will be described, followed by a description of the control of the game system 1 according to this embodiment.

[0028] FIG. 1 is a diagram showing an example of a state in which a left controller 3 and a right controller 4 are attached to a main unit 2. As shown in FIG. 1, the left controller 3 and the right controller 4 are each attached to and integrated with the main unit 2. The main unit 2 is a device that executes various processes (e.g., game processes) in the game system 1. The main unit 2 is equipped with a display 12. The left controller 3 and the right controller 4 are devices that have operation units that allow the user to perform inputs.

[0029] Fig. 2 is a diagram showing an example of the state in which the left controller 3 and the right controller 4 are detached from the main unit 2. As shown in Figs. 1 and 2, the left controller 3 and the right controller 4 are detachable from the main unit 2. Note that, below, the left controller 3 and the right controller 4 may be collectively referred to as "controllers."

[0030] Fig. 3 is a six-sided view showing an example of the main unit 2. As shown in Fig. 3, the main unit 2 includes a substantially plate-shaped housing 11. In this embodiment, the main surface of the housing 11 (in other words, the front surface, i.e., the surface on which the display 12 is provided) is generally rectangular.

[0031] The shape and size of the housing 11 are arbitrary. As an example, the housing 11 may be of a portable size. Furthermore, the main unit 2 alone or an all-in-one device in which the left controller 3 and right controller 4 are attached to the main unit 2 may be a portable device. Furthermore, the main unit 2 or the all-in-one device may be a handheld device. Furthermore, the main unit 2 or the all-in-one device may be a portable device.

[0032] 3, the main unit 2 includes a display 12 provided on the main surface of the housing 11. The display 12 displays images generated by the main unit 2. In this embodiment, the display 12 is a liquid crystal display (LCD). However, the display 12 may be any type of display device.

[0033] The main device 2 also includes a touch panel 13 on the screen of the display 12. In this embodiment, the touch panel 13 is of a type that allows multi-touch input (for example, a capacitance type). However, the touch panel 13 may be of any type, and may be of a type that allows single-touch input (for example, a resistive type).

[0034] The main unit 2 is provided with a speaker (i.e., speaker 88 shown in FIG. 6) inside the housing 11. As shown in FIG. 3, speaker holes 11a and 11b are formed on the main surface of the housing 11. The output sound of the speaker 88 is output from these speaker holes 11a and 11b, respectively.

[0035] The main unit 2 also has a left terminal 17, which is a terminal for the main unit 2 to communicate with the left controller 3 via a wired connection, and a right terminal 21, which is a terminal for the main unit 2 to communicate with the right controller 4 via a wired connection.

[0036] As shown in FIG. 3, the main unit 2 includes a slot 23. The slot 23 is provided on the upper side of the housing 11. The slot 23 has a shape that allows a predetermined type of storage medium to be inserted therein. The predetermined type of storage medium is, for example, a storage medium (e.g., a dedicated memory card) dedicated to the game system 1 and the same type of information processing device. The predetermined type of storage medium is used, for example, to store data used by the main unit 2 (e.g., application save data, etc.) and / or programs executed by the main unit 2 (e.g., application programs, etc.). The main unit 2 also includes a power button 28.

[0037] The main unit 2 has a lower terminal 27. The lower terminal 27 is a terminal through which the main unit 2 communicates with the cradle. In this embodiment, the lower terminal 27 is a USB connector (more specifically, a female connector). When the all-in-one device or the main unit 2 alone is placed on the cradle, the game system 1 can display images generated and output by the main unit 2 on a stationary monitor. In this embodiment, the cradle also has the function of charging the all-in-one device or the main unit 2 alone that is placed on it. The cradle also has the function of a hub device (specifically, a USB hub).

[0038] FIG. 4 is a six-sided view showing an example of the left controller 3. As shown in FIG. 4, the left controller 3 includes a housing 31. In this embodiment, the housing 31 has a vertically long shape, that is, a shape that is long in the up-down direction in FIG. 4 (the z-axis direction shown in FIG. 4). The left controller 3 can also be held in a vertically long orientation when detached from the main unit 2. The housing 31 has a shape and size that allows it to be held in one hand, particularly the left hand, when held in a vertically long orientation. The left controller 3 can also be held in a horizontally long orientation. When the left controller 3 is held in a horizontally long orientation, it may be held with both hands.

[0039] The left controller 3 is equipped with a left analog stick (hereinafter referred to as the left stick) 32, which is an example of a directional input device. As shown in FIG. 4, the left stick 32 is provided on the main surface of the housing 31. The left stick 32 can be used as a directional input unit that can input directions. By tilting the left stick 32, the user can input a direction corresponding to the tilt direction (and input a magnitude corresponding to the tilt angle). Note that the left controller 3 may be equipped with a cross key or a slide stick that can perform slide inputs, instead of an analog stick, as a directional input unit. In this embodiment, input can be made by pressing down the left stick 32.

[0040] The left controller 3 is equipped with various operation buttons. The left controller 3 is equipped with four operation buttons 33 to 36 (specifically, a right button 33, a down button 34, an up button 35, and a left button 36) on the main surface of the housing 31. The left controller 3 is also equipped with a record button 37 and a - (minus) button 47. The left controller 3 is equipped with a first L button 38 and a ZL button 39 on the upper left side of the housing 31. The left controller 3 is also equipped with a second L button 43 and a second R button 44 on the side of the housing 31 that is attached to the main unit 2. These operation buttons are used to issue instructions according to various programs (for example, OS programs and application programs) executed on the main unit 2.

[0041] The left controller 3 also includes a terminal 42 for wired communication between the left controller 3 and the main unit 2.

[0042] FIG. 5 is a six-sided view showing an example of the right controller 4. As shown in FIG. 5, the right controller 4 includes a housing 51. In this embodiment, the housing 51 has a vertically long shape, that is, a shape that is long in the up-down direction in FIG. 5 (the z-axis direction shown in FIG. 5). The right controller 4 can also be held in a vertically long orientation when detached from the main unit 2. The housing 51 has a shape and size that allows it to be held in one hand, particularly the right hand, when held in a vertically long orientation. The right controller 4 can also be held in a horizontally long orientation. When the right controller 4 is held in a horizontally long orientation, it may be held with both hands.

[0043] Like the left controller 3, the right controller 4 is equipped with a right analog stick (hereinafter referred to as the right stick) 52 as a directional input unit. In this embodiment, the right stick 52 has the same configuration as the left stick 32 of the left controller 3. The right controller 4 may also be equipped with a cross key or a slide stick capable of slide input, instead of an analog stick. Like the left controller 3, the right controller 4 is equipped with four operation buttons 53 to 56 (specifically, an A button 53, a B button 54, an X button 55, and a Y button 56) on the main surface of the housing 51. The right controller 4 is further equipped with a + (plus) button 57 and a home button 58. The right controller 4 is also equipped with a first R button 60 and a ZR button 61 on the upper right side of the housing 51. Like the left controller 3, the right controller 4 is also equipped with a second L button 65 and a second R button 66.

[0044] The right controller 4 also includes a terminal 64 for wired communication between the right controller 4 and the main unit 2.

[0045] Fig. 6 is a block diagram showing an example of the internal configuration of main unit 2. In addition to the configuration shown in Fig. 3, main unit 2 includes components 81-91, 97, and 98 shown in Fig. 6. Some of these components 81-91, 97, and 98 may be mounted on an electronic circuit board as electronic components and housed in housing 11.

[0046] The main body device 2 includes a processor 81. The processor 81 is an information processing unit that executes various information processes executed in the main body device 2, and is, for example, a CPU (Central Processing Unit). The processor 81 may be configured with only a GPU (Graphics Processing Unit), or may be configured with an SoC (System-on-a-chip) including multiple functions such as a CPU function and a GPU (Graphics Processing Unit) function. The processor 81 performs various types of information processing by executing an information processing program (for example, a game program) stored in a storage unit (specifically, an internal storage medium such as a flash memory 84, or an external storage medium inserted in the slot 23).

[0047] The main device 2 includes a flash memory 84 and a DRAM (Dynamic Random Access Memory) 85 as examples of internal storage media built into the main device 2. The flash memory 84 and the DRAM 85 are connected to the processor 81. The flash memory 84 is a memory used primarily to store various types of data (which may be programs) saved in the main device 2. The DRAM 85 is a memory used to temporarily store various types of data used in information processing.

[0048] The main device 2 includes a slot interface (hereinafter abbreviated as "I / F") 91. The slot I / F 91 is connected to the processor 81. The slot I / F 91 is connected to the slot 23, and reads and writes data from and to a predetermined type of storage medium (e.g., a dedicated memory card) inserted into the slot 23 in accordance with instructions from the processor 81.

[0049] The processor 81 reads and writes data from and to the flash memory 84, DRAM 85, and the above-mentioned storage media as appropriate, to execute the above-mentioned information processing.

[0050] The main body device 2 includes a network communication unit 82. The network communication unit 82 is connected to the processor 81. The network communication unit 82 communicates with an external device via a network (specifically, wireless communication). In this embodiment, the network communication unit 82 connects to a wireless LAN using a method conforming to the Wi-Fi standard, for example, and performs Internet communication with an external device (another main body device 2). The network communication unit 82 can also perform short-range wireless communication (for example, infrared communication) with another main body device 2.

[0051] The main unit 2 is equipped with a controller communication unit 83. The controller communication unit 83 is connected to the processor 81. The controller communication unit 83 performs wireless communication with the left controller 3 and / or right controller 4. Any communication method may be used between the main unit 2 and the left controller 3 and right controller 4, but in this embodiment, the controller communication unit 83 performs communication with the left controller 3 and right controller 4 in accordance with the Bluetooth (registered trademark) standard.

[0052] The processor 81 is connected to the left terminal 17, right terminal 21, and lower terminal 27. When performing wired communication with the left controller 3, the processor 81 transmits data to the left controller 3 via the left terminal 17 and receives operation data from the left controller 3 via the left terminal 17. When performing wired communication with the right controller 4, the processor 81 transmits data to the right controller 4 via the right terminal 21 and receives operation data from the right controller 4 via the right terminal 21. When performing wired communication with the right controller 4, the processor 81 transmits data to the cradle via the lower terminal 27. As described above, in this embodiment, the main unit 2 can perform both wired and wireless communication with the left controller 3 and the right controller 4. When an integrated device in which the left controller 3 and the right controller 4 are attached to the main unit 2 or the main unit 2 alone is attached to the cradle, the main unit 2 can output data (e.g., image data and audio data) to a stationary monitor or the like via the cradle.

[0053] Here, the main unit 2 can communicate simultaneously (in other words, in parallel) with multiple left controllers 3. The main unit 2 can also communicate simultaneously (in other words, in parallel) with multiple right controllers 4. Therefore, multiple users can simultaneously input to the main unit 2 using their own sets of left controllers 3 and right controllers 4. For example, a first user can input to the main unit 2 using a first set of left controllers 3 and right controllers 4, while a second user can simultaneously input to the main unit 2 using a second set of left controllers 3 and right controllers 4.

[0054] The main device 2 includes a touch panel controller 86, which is a circuit that controls the touch panel 13. The touch panel controller 86 is connected between the touch panel 13 and the processor 81. Based on a signal from the touch panel 13, the touch panel controller 86 generates data indicating, for example, the position where a touch input was made, and outputs the data to the processor 81.

[0055] The display 12 is also connected to the processor 81. The processor 81 displays on the display 12 an image generated (for example, by executing the above-described information processing) and / or an image acquired from the outside.

[0056] The main unit 2 includes a codec circuit 87 and speakers (specifically, a left speaker and a right speaker) 88. The codec circuit 87 is connected to the speakers 88 and the audio input / output terminal 25, and is also connected to the processor 81. The codec circuit 87 is a circuit that controls the input and output of audio data to and from the speakers 88 and the audio input / output terminal 25.

[0057] The main device 2 includes a power control unit 97 and a battery 98. The power control unit 97 is connected to the battery 98 and the processor 81. Although not shown, the power control unit 97 is also connected to each part of the main device 2 (specifically, each part that receives power from the battery 98, the left terminal 17, and the right terminal 21). The power control unit 97 controls the power supply from the battery 98 to each of the above parts based on instructions from the processor 81.

[0058] Furthermore, battery 98 is connected to lower terminal 27. When an external charging device (e.g., a cradle) is connected to lower terminal 27 and power is supplied to main device 2 via lower terminal 27, battery 98 is charged with the supplied power.

[0059] Figure 7 is a block diagram showing an example of the internal configuration of the main unit 2, left controller 3, and right controller 4. Note that details of the internal configuration of the main unit 2 are omitted in Figure 7 because they are shown in Figure 6.

[0060] The left controller 3 is equipped with a communication control unit 101 that communicates with the main unit 2. As shown in FIG. 7 , the communication control unit 101 is connected to each component, including the terminal 42. In this embodiment, the communication control unit 101 can communicate with the main unit 2 both via wired communication via the terminal 42 and via wireless communication without using the terminal 42. The communication control unit 101 controls the method of communication between the left controller 3 and the main unit 2. That is, when the left controller 3 is attached to the main unit 2, the communication control unit 101 communicates with the main unit 2 via the terminal 42. When the left controller 3 is detached from the main unit 2, the communication control unit 101 communicates wirelessly with the main unit 2 (specifically, with the controller communication unit 83). Wireless communication between the controller communication unit 83 and the communication control unit 101 is performed in accordance with, for example, the Bluetooth (registered trademark) standard.

[0061] The left controller 3 also includes a memory 102, such as a flash memory. The communication control unit 101 is configured, for example, by a microcomputer (also called a microprocessor), and executes firmware stored in the memory 102 to perform various processes.

[0062] The left controller 3 includes buttons 103 (specifically, buttons 33 to 39, 43, 44, and 47). The left controller 3 also includes a left stick 32. Each button 103 and left stick 32 repeatedly outputs information relating to an operation performed on that button 103 and left stick 32 to the communication control unit 101 at an appropriate timing.

[0063] The left controller 3 is equipped with an inertial sensor. Specifically, the left controller 3 is equipped with an acceleration sensor 104. The left controller 3 is also equipped with an angular velocity sensor 105. In this embodiment, the acceleration sensor 104 detects the magnitude of acceleration along three predetermined axes (for example, the x, y, and z axes shown in FIG. 4). The acceleration sensor 104 may detect acceleration along one or two axes. In this embodiment, the angular velocity sensor 105 detects angular velocity around three predetermined axes (for example, the x, y, and z axes shown in FIG. 4). The angular velocity sensor 105 may detect angular velocity around one or two axes. The acceleration sensor 104 and the angular velocity sensor 105 are each connected to the communication control unit 101. The detection results of the acceleration sensor 104 and the angular velocity sensor 105 are repeatedly output to the communication control unit 101 at appropriate timing.

[0064] The communication control unit 101 acquires information about the input (specifically, information about the operation or the detection results by the sensors) from each input unit (specifically, each button 103, left stick 32, and each sensor 104 and 105). The communication control unit 101 transmits operation data including the acquired information (or information obtained by performing a predetermined process on the acquired information) to the main unit 2. The operation data is repeatedly transmitted once every predetermined time. The interval at which the information about the input is transmitted to the main unit 2 may or may not be the same for each input unit.

[0065] By transmitting the above operation data to the main unit 2, the main unit 2 can obtain the input made to the left controller 3. That is, the main unit 2 can determine the operation of each button 103 and left stick 32 based on the operation data. Furthermore, the main unit 2 can calculate information regarding the movement and / or posture of the left controller 3 based on the operation data (specifically, the detection results of the acceleration sensor 104 and the angular velocity sensor 105).

[0066] The left controller 3 is equipped with a power supply unit 108. In this embodiment, the power supply unit 108 has a battery and a power control circuit. Although not shown, the power control circuit is connected to the battery and to each part of the left controller 3 (specifically, each part that receives power from the battery).

[0067] As shown in FIG. 7, the right controller 4 is equipped with a communication control unit 111 that communicates with the main unit 2. The right controller 4 also has a memory 112 that is connected to the communication control unit 111. The communication control unit 111 is connected to each component, including the terminal 64. The communication control unit 111 and memory 112 have the same functions as the communication control unit 101 and memory 102 of the left controller 3. Therefore, the communication control unit 111 can communicate with the main unit 2 both via wired communication via the terminal 64 and via wireless communication that does not use the terminal 64 (specifically, communication in accordance with the Bluetooth (registered trademark) standard), and controls the method of communication between the right controller 4 and the main unit 2.

[0068] The right controller 4 has input units similar to those of the left controller 3. Specifically, it has buttons 113, a right stick 52, and inertial sensors (an acceleration sensor 114 and an angular velocity sensor 115). These input units have the same functions as those of the left controller 3, and operate in the same manner.

[0069] The right controller 4 is equipped with a power supply unit 118. The power supply unit 118 has the same functions as the power supply unit 108 of the left controller 3 and operates in the same manner.

[0070] FIG. 8 is a diagram showing an example in which strings for passing the player's wrists are attached to each of the left controller 3 and the right controller 4. As shown in FIG. 8, a string attachment member 200 is attached and fixed to the portion of the left controller 3 that is attached to the main unit 2 (see FIGS. 1 and 4). Both ends of a string 202 are fixed to the ends of the string attachment member 200. An adjustment member 204 is attached to the string 202 to adjust the size of the loop through which the player's left wrist is passed. Similarly, as shown in FIG. 8, a string attachment member 201 is attached and fixed to the portion of the right controller 4 that is attached to the main unit 2 (see FIGS. 1 and 4). Both ends of a string 203 are fixed to the ends of the string attachment member 201. An adjustment member 205 is attached to the string 203 to adjust the size of the loop through which the player's right wrist is passed. A player can play a game or the like by passing his / her left wrist through the loop of string 202 and holding left controller 3, and passing his / her right wrist through the loop of string 203 and holding right controller 4.

[0071] [Games assumed in this embodiment] Next, an overview of game processing (an example of information processing) executed by the game system 1 according to this embodiment will be described. The game assumed in this embodiment is a game in which multiple short games are played consecutively, and when a short game is cleared, the next short game begins. If a player fails to clear a short game, the game ends, and when the player plays again, the player can resume the game from the short game that was failed to be cleared, for example.

[0072] [Outline of game processing in this embodiment] In this game processing, during the waiting period before the start of each short game, a model video showing the player (user) how to hold the controller is displayed, and then the short game is played. The model video is a video of a model object placed in a virtual space (game space) photographed by a virtual camera, in which the model object, which resembles a player holding the left controller 3 in his left hand and the right controller 4 in his right hand, strikes a pose (a pose that is preset according to the short game to be played after the model video is displayed). The player then begins operations in the short game from the pose shown in the model video (a pose holding the controller in the same way as the pose of the model object). The model video and short game will be described in detail below.

[0073] Fig. 9 is a diagram illustrating an example of a model video (animation; sometimes referred to as "model video 1") that shows the player how to hold the controller before the start of a short game in which the player finds an airplane through a telescope. Fig. 10 is a diagram illustrating an example of a short game in which the player finds an airplane through a telescope.

[0074] As shown in Fig. 9(1), the model video 1 starts with the model object 310 facing forward (facing the virtual camera), holding a right controller image 4C representing the right controller 4 in the right hand with the thumb facing up, and holding a left controller image 3C representing the left controller 3 in the left hand with the thumb facing up, with both elbows bent at approximately 90 degrees and the hands positioned forward of the torso. Then, as shown in Fig. 9(2), the model object 310 rotates leftward, thrusting both hands forward and stretching both arms. Then, as shown in Fig. 9(3), the model object 310 rotates leftward further, thrusting both hands forward and stretching both arms further, while moving the right hand holding the right controller image 4C to a position above the left hand holding the left controller image 3C. Then, as shown in Figure 9 (4), the model object 310 rotates further to the left until it reaches a position where the virtual camera can see the right rear diagonal area (right rear diagonal area), and then it assumes a pose (an asymmetrical pose) in which the right hand holding the right controller image 4C with the thumb on top is positioned above the left hand holding the left controller image 3C with the thumb on top, and stops for a predetermined time (for example, 0.5 seconds), ending the animation of the model image 1.

[0075] In this way, in the model video 1, the model object 310 moves both hands holding the controller while rotating, and finally assumes a pose seen from diagonally rear right (a pose in which the diagonally rear part is displayed) in which the state of the arms and hands can be seen. From this, the player can intuitively understand that the model object 310 is not displayed inverted left to right as if reflected in a mirror, and can also quickly and intuitively understand the pose that should be taken at the start of a short game (the pose that should be taken with the controller held in both hands), which will be described later with reference to Figure 10.

[0076] After the display of sample video 1 has finished, the short game of finding an airplane with a telescope as shown in Figure 10 begins. First, as shown in Figure 10(1), an image of a person holding a telescope in each hand and facing the sea is displayed. The pose of the person holding the telescope is the same as or similar to the pose shown in sample video 1, and the orientation is also the same as or similar to that shown in Figure 9(4). Also, as shown in Figure 10(1), the action instruction "Get ready!" is displayed above the telescope, instructing the player holding controllers in both hands to move both arms to hold the telescope. After that, as shown in Figure 10(2), an image showing the state of looking through the telescope is displayed, and the action instruction "Find the plane!" is displayed. This action instruction is an instruction to the player to move the telescope (the left and right hands holding the controllers) to find the plane.

[0077] After that, the direction of the telescope in the virtual space changes based on the movement of the left and right controllers in response to the player's movement of the left and right hands. In Figure 10(3), the direction of the telescope in the virtual space changes, and the tail of the airplane becomes visible. If the player can then move his or her left and right hands to make the entire airplane visible through the telescope within a predetermined time (e.g., 10 seconds) after the start of the short game, as shown in Figure 10(4), the short game is cleared. On the other hand, if the player cannot make the entire airplane visible through the telescope within a predetermined time (e.g., 10 seconds) after the start of the short game, the player fails to clear the short game.

[0078] Here, in the above description, it is assumed that the player's right hand is set as the dominant hand before the start of the short game. When the player is right-handed, it is generally easier to operate the telescope if the dominant right hand is on top when holding it. For this reason, in the pose (first pose) of the model object 310 in FIG. 9(4), the right hand is above the left hand. Also, the person holding the telescope in FIG. 10(1) also has the right hand above the left hand.

[0079] On the other hand, if it is previously set before the start of the short game that the player's left hand is dominant, the model image 1 in FIG. 9 will be a left-right reversed image. Specifically, in FIG. 9, the model object 310 rotates clockwise and moves so that its left hand is above its right hand, finally assuming a pose viewed from diagonally behind the left (second pose). The person holding the telescope in FIG. 10(1) will also be a left-right reversed image. If it is previously set that the player's left hand is dominant, the operation data (left operation data) output from the left controller 3 and the operation data (right operation data) output from the right controller 4 are swapped and used for action determination (evaluation of the controller movement). In this way, whether the player is set to be right-handed or left-handed, the telescope movement can be controlled by assigning the right operation data to the upper side of the telescope (the part of the telescope closest to the eye when held) and the left operation data to the lower side of the telescope (the part of the telescope farthest from the eye when held).

[0080] Fig. 11 is a diagram illustrating an example of a model video (animation; sometimes referred to as "model video 2") that shows a player how to hold the controller before the start of a short game in which wrinkles are smoothed out of a washed shirt. Fig. 11 is a diagram illustrating an example of a short game in which wrinkles are smoothed out of a washed shirt.

[0081] As shown in Fig. 11(1), the model video 2 starts from the same state of the model object 310 as in Fig. 9(1). Then, as shown in Fig. 11(2), the model object 310 rotates left, thrusting its left and right hands forward beyond its torso and extending its left and right arms. Then, as shown in Fig. 11(3), the model object 310 rotates further left, thrusting its left and right hands further forward with the backs of its hands facing up and extending its left and right arms. Then, as shown in Fig. 11(4), the model object 310 rotates further left to a position where the virtual camera can capture the right-rear diagonal part, and then it strikes a pose with its left and right hands stretched forward with the backs of its hands facing up (a symmetrical pose) and stops for a predetermined time (e.g., 0.5 seconds), and the animation of the model video 2 ends.

[0082] In this way, in the model video 2, the model object 310 moves both hands holding the controller while rotating, and finally assumes a pose seen from diagonally rear right (a pose in which the diagonally rear part is displayed) in which the state of the arms and hands can be seen. From this, the player can intuitively understand that the model object 310 is not displayed reversed left to right as if reflected in a mirror, and can also quickly and intuitively understand the pose that should be taken at the start of the short game (the pose that should be taken with the controller held in both hands) which will be described later with reference to Figure 12.

[0083] After the display of model video 2 has finished, the short game of smoothing out the wrinkles in a washed shirt shown in FIG. 12 begins. First, as shown in FIG. 12(1), an image of a heavily wrinkled washed shirt being grasped with a left hand object 353 and a right hand object 352 is displayed. The positional relationship between the left hand object 353 and the right hand object 352 grasping the shirt is the same as or similar to the positional relationship between the hands in the pose shown in model video 2 (see FIG. 11(4)). Also, as shown in FIG. 12(1), an action instruction "Smooth out the wrinkles!" is displayed above the shirt, instructing the player, holding controllers in both hands, to move both hands and shake the shirt up and down to smooth out the wrinkles. Then, as shown in FIG. 12(2), the player moves the left hand object 353 and the right hand object 352 in the virtual space based on the movements of the left and right controllers in response to the up and down movements of the left and right hands, thereby shaking the shirt up and down and gradually smoothing out the wrinkles. If the player can smooth out all the wrinkles in the shirt within a predetermined time (for example, about 4 seconds, which may be shortened as the game progresses) after the start of the short game, as shown in Figure 12(3), the player has cleared the short game. On the other hand, if the player cannot smooth out all the wrinkles in the shirt within a predetermined time (for example, about 4 seconds, which may be shortened as the game progresses) after the start of the short game, the player has failed to clear the short game.

[0084] Fig. 13 is a diagram illustrating an example of a model video (animation; sometimes referred to as "model video 3") that shows the player how to hold the controller before the start of a short game in which an enemy object is flipped over. Fig. 14 is a diagram illustrating an example of a short game in which an enemy object is flipped over.

[0085] As shown in Fig. 13(1), the model video 3 starts from the same state of the model object 310 as in Fig. 9(1). Then, as shown in Fig. 13(2), the model object 310 rotates left, lowering its left hand and raising its right hand. Then, as shown in Fig. 13(3), the model object 310 rotates further left, lowering its left hand and raising its right hand. Then, as shown in Fig. 13(4), the model object 310 rotates further left to a position where the virtual camera can capture its direct rear (rear part), and then it assumes a pose in which its right hand is positioned next to its right ear and its left hand is positioned next to its waist (an asymmetric pose), and stops for a predetermined time (e.g., 0.5 seconds), at which point the animation of the model video 3 ends.

[0086] In this way, in the model video 3, the model object 310 moves both hands holding the controller while rotating, and finally assumes a pose seen from directly behind (a pose showing the rear part), in which the state of the arms and hands can be seen. From this, the player can intuitively understand that the model object 310 is not displayed inverted left to right as if reflected in a mirror, and can also quickly and intuitively understand the pose that should be taken at the start of a short game (the pose that should be taken with the controller held in both hands), which will be described later with reference to Figure 14.

[0087] When the display of the model video 3 ends, a short game begins in which the enemy object in FIG. 14 is flipped over. First, as shown in FIG. 14(1), an image is displayed in which the enemy object 355 is moving over a plurality of blocks arranged above the player object 356 operated by the player. The pose of the player object 356 is the same as or similar to the pose shown in the model video 3 (see FIG. 9(4)). Also, as shown in FIG. 14(1), an action instruction "Flip it over!" is displayed above the player object 356, instructing the player, who is holding controllers in both hands, to jump and thrust up his right hand to flip the enemy object 355 over.

[0088] Thereafter, when the enemy object 355 comes directly above the player object 356, based on the movements of the left and right controllers in response to the player's jumping and thrusting up their right hand, the player object 356 jumps and thrusts up their right hand to thrust up the upper block (FIG. 14(2)), causing the enemy object 355 to flip over and the short game to be cleared (FIG. 14(3)). On the other hand, when the player jumps and thrusts up their right hand at a timing other than the timing when the enemy object 355 comes directly above the player object 356, the enemy object 355 does not flip over and the player fails to clear the short game.

[0089] In the above description, it is assumed that the player's right hand is set as the dominant hand before the start of the short game. If the player is right-handed, he or she will generally be able to jump and thrust up with his or her right hand well.

[0090] On the other hand, if the player's left hand is set as the dominant hand before the start of the short game, the model image 3 in FIG. 13 is a mirror-inverted image. Specifically, in FIG. 13, the model object 310 rotates clockwise, moving to a position where the left hand is next to the left ear and the right hand is at the waist, and finally assuming a pose seen from directly behind. The player object 356 in FIG. 14 may be mirror-inverted, or may be displayed as is. Also, if the player's left hand is set as the dominant hand beforehand, the operation data output from the left controller 3 and the operation data output from the right controller 4 are swapped and used for motion determination (evaluation of the controller motion). In this way, if the player's left hand is set as the dominant hand and the player jumps and thrusts his left hand up, the player object 356 jumps and thrusts his right hand up to thrust up the upper block (see FIG. 14(2)). As a result, left-handed players who are not good at jumping and thrusting their right hand up can enjoy the short game in FIG. 14 just like right-handed players. In the short game of FIG. 14, it is sufficient that the player object 356 can perform the thrusting action while assuming the pose that the player is supposed to assume, so the thrusting hand does not necessarily have to be aligned with the model image 3 and the pose that the player is supposed to assume, and in cases where it is necessary to use a predetermined graphic, the player may raise a predetermined hand regardless of the model image 3.

[0091] Fig. 15 is a diagram illustrating an example of a model video (animation; sometimes referred to as "model video 4") that shows a player how to hold the controller before the start of a short game in which the player holds and pulls out a rocket. Fig. 15 is a diagram illustrating an example of a short game in which the player holds and pulls out a rocket.

[0092] As shown in Fig. 15(1), model video 4 starts from the same state of model object 310 as in Fig. 9(1). Then, as shown in Fig. 15(2), model object 310 moves its left and right hands apart while facing forward. Then, as shown in Fig. 13(3), model object 310 moves to a pose in which it stretches both arms straight out to the left and right with its palms facing forward (a symmetrical pose) while facing forward, and stops for a predetermined time (for example, 0.5 seconds), at which point the animation of model video 4 ends.

[0093] In this way, in the model image 4, the model object 310 faces forward (toward the virtual camera) and moves both hands holding the controller, ultimately assuming a pose seen from the front, in which the state of the arms and hands can be seen. This allows the player to quickly and intuitively understand the pose (the pose to be assumed with the controllers held in both hands) that should be assumed at the start of the short game, which will be described later with reference to FIG. 16 . Here, since the pose in FIG. 15(3) is a symmetrical pose, and the short game in which the player holds and releases the rocket, which will be described later, is a game in which the player operates symmetrically, it does not matter whether the model object 310 is displayed mirror-reversed. Therefore, in the model image 4, there is no need to rotate the model object 310 to indicate that it is not displayed mirror-reversed, and the model object 310 moves to assume a pose while facing forward.

[0094] 15, the example object 310 is configured to pose while facing forward, but the example object 310 may be configured to pose while facing backward. In this way, the player can also intuitively understand the poses to hold the controller.

[0095] After the display of the model image 4 has finished, the short game in which the player holds and pulls out the rocket shown in FIG. 16 begins. First, as shown in FIG. 16(1), an image is displayed in which the player's player object 359, with arms outstretched, faces the rocket 358 stuck in the ground. Also, as shown in FIG. 16(1), the action instruction "Pick it up and pull it out!" is displayed above the rocket, instructing the player, holding controllers in both hands, to hold the rocket with each hand (arm) and then lift it upward to pull it out. Then, as shown in FIG. 16(2), the player object 359 holds the rocket with each hand (arm) in virtual space based on the movement of the left and right controllers in response to the player's action of holding the rocket with each hand (arm). Then, as shown in FIG. 16(3), the player object 359 pulls out the rocket with each hand (arm) in virtual space based on the movement of the left and right controllers in response to the player's action of moving their hands (arms) upward, thereby clearing the short game. On the other hand, if the rocket cannot be pulled out within a predetermined time (for example, 12 seconds) after the start of the short game, the player fails to clear the short game.

[0096] [Details of information processing in this embodiment] Next, the information processing of this embodiment will be described in detail with reference to FIGS.

[0097] [About data usage] Various types of data used in this game processing will now be described. Fig. 17 shows an example of data stored in the DRAM 85 of the game system 1. As shown in Fig. 17, the DRAM 85 is provided with at least a program memory area 301 and a data memory area 302. The program memory area 301 stores a game program 401. The data memory area 302 stores game control data 402, image data 408, virtual camera control data 409, operation data 410, transmission data 411, received data 412, etc. The game control data 402 includes object data 403.

[0098] The game program 401 is a game program for executing the game processing.

[0099] The object data 403 is data on objects placed in the virtual space, such as player objects, enemy objects, items, the ground, blocks, etc. The object data 403 also includes data on the coordinates (position), direction, posture, state, etc. of the object.

[0100] Image data 408 is image data such as background and virtual effects.

[0101] The virtual camera control data 409 is data for controlling the movement of a virtual camera placed in a virtual space, specifically, data for specifying the position, posture, angle of view, imaging direction, etc. of the virtual camera.

[0102] The operation data 410 is data that indicates the content of operations performed on the left controller 3 and the right controller 4. For example, it includes data that indicates the input status of the movements and posture changes of the left controller 3 and the right controller 4, and the press status of various buttons. The content of the operation data is updated at a predetermined cycle based on signals from the left controller 3 and the right controller 4.

[0103] The transmission data 411 is data to be transmitted to other game systems 1, and includes at least information for identifying the transmission source and the contents of the operation data 410. The transmission data 411 includes data relating to the player's character (data indicating coordinates (position), posture, state, etc.) to be transmitted to other game systems 1 as multiplayer partners.

[0104] The received data 412 is data for transmission received from other game systems 1 and stored so as to be identifiable for each of the other game systems 1 (i.e., the sender). The received data 412 includes data relating to other player characters (data indicating coordinates (position), posture, status, etc.) received from other game systems 1 (or servers) of the multiplayer partners.

[0105] Additionally, the DRAM 85 stores various types of data used in game processing as needed.

[0106] [Details about game processing] Next, details of the game processing according to this embodiment will be described with reference to a flowchart. Fig. 18 is an example of a flowchart showing details of the game processing according to this embodiment.

[0107] 18, when the game processing starts, in step S100, processor 81 executes a dominant hand input process using game program 401, etc. Specifically, processor 81 displays an image (not shown) for inputting the dominant hand, and prompts the player to input whether the dominant hand is right or left. Thereafter, the process proceeds to step S101.

[0108] In step S101, processor 81 determines whether or not the dominant hand is input as the left hand in step S100. If the determination in step S101 is YES, the process proceeds to step S102, and if the determination is NO, the process proceeds to step S103.

[0109] In step S102, processor 81 performs settings to flip the display of the model video image horizontally and to swap the operation data acquired from the left and right controllers. Specifically, as described in the description of the short game using Figures 9 and 10 and the short game using Figures 13 and 14, processor 81 swaps the operation data output from left controller 3 and the operation data output from right controller 4, and performs action determination (evaluation of the movement of the controllers) in the processing of step S105, which will be described later, to perform settings to progress the short game. Then, the processing proceeds to step S103.

[0110] The process of setting the dominant hand in steps S100 to S102 does not have to be performed every time the game is started as described above, but may be performed when the player performs a predetermined setting operation at any timing.

[0111] In step S103, processor 81 determines the order of short games to be executed. The order of short games to be executed is determined at the start of this game process. Note that the order of short games to be executed may be determined in advance. Thereafter, the process proceeds to step S104.

[0112] In step S104, processor 81 displays a model video corresponding to the short game whose execution was determined in step S103. For example, if it is determined that the short game described with reference to FIG. 12 will be executed, processor 81 displays model video 2 described with reference to FIG. 11. Furthermore, for example, if it is determined that the short game described with reference to FIG. 14 will be executed, processor 81 displays model video 3 described with reference to FIG. 13. Thereafter, the process proceeds to step S105.

[0113] In step S105, processor 81 executes the short game whose execution was determined in step S103. Then, the process proceeds to step S106.

[0114] In step S106, processor 81 determines whether a game end condition has been met. The game end condition is a condition in which the player has failed to complete the short game. Note that the game end condition is not limited to this and may be, for example, a condition in which the player has failed to complete the short game a predetermined number of times (e.g., five times). If the determination in step S106 is YES, the game ends and the processing ends; if the determination is NO, the processing returns to step S103 to determine the next short game to be executed.

[0115] As described above, according to this embodiment, before the start of a short game, an animated model video of a model object representing a player holding a controller and posing is displayed (see FIGS. 9 to 16). This allows a player to intuitively understand how to hold (hold) the controller at the start of a short game. Furthermore, according to this embodiment, an animated model video of the model object posing in a way that shows the state of both hands is displayed (see FIGS. 9, 11, 13, and 15). Furthermore, when the model object is posing with its hands positioned in front of its body, the model object is displayed as seen from diagonally behind so that the state of both hands can be seen (see FIGS. 9 and 11). This allows a player to accurately understand how to hold (hold) the controller at the start of a short game. Furthermore, according to this embodiment, an animated model video of the model object rotating and posing asymmetrically is displayed (see FIGS. 9 and 13). This allows a player to intuitively understand that even when the model pose is asymmetrical, the model video is not displayed as a mirror image.

[0116] [Variations] In the above-described embodiment, the model object 310 is configured to appear to rotate in the model video by rotating in the virtual space (see FIG. 9, etc.). However, the present invention is not limited to this, and the model object 310 may appear to rotate in the model video by rotating and moving the virtual camera around the model object 310 in the virtual space.

[0117] In the above-described embodiment, the model video is a three-dimensional video captured in a virtual space by a virtual camera (see FIG. 9, etc.). However, the present invention is not limited to this, and the model video may be a two-dimensional image.

[0118] In the above-described embodiment, the player's hand movements are detected by the inertial sensor of the controller. However, this is not limiting, and the player's hand movements may be detected based on an image of the player taken from the front, for example.

[0119] In the above-described embodiment, the evaluation of success or failure in the short game is performed based on the operation data acquired from the controller. However, the present invention is not limited to this, and the evaluation of the short game may be performed by assigning a score based on the operation data acquired from the controller.

[0120] In the above-described embodiment, a series of processes related to game processing is executed by a single game device. In other embodiments, the series of processes may be executed in an information processing system consisting of multiple information processing devices. For example, in an information processing system including a terminal device and a server device capable of communicating with the terminal device via a network, some of the series of processes may be executed by the server device. Furthermore, in an information processing system including a terminal device and a server device capable of communicating with the terminal device via a network, main processes of the series of processes may be executed by the server device, and some processes may be executed by the terminal device. In the above-described information processing system, the server system may be composed of multiple information processing devices, and the processes to be executed on the server side may be shared and executed by the multiple information processing devices. A so-called cloud gaming configuration may also be used. For example, a game device may send operation data indicating user operations to a predetermined server, and the server may execute various game processes, with the execution results being streamed to the game device as video and audio.

[0121] Although the present embodiment and its modifications have been described above, these descriptions are merely illustrative in all respects and are not intended to limit the scope of the present embodiment and its modifications. It goes without saying that various improvements and modifications can be made to the present embodiment and its modifications. [Explanation of symbols]

[0122] 1. Game System 3, 4 Controller 3C, 4C controller images 12 Display 81 processors 85 DRAM 310 Example Object

Claims

1. A game program that causes a computer of an information processing device to continuously execute a plurality of types of games, The computer, For each of said games played in succession, during a waiting period before the start of the game, displaying an example image in which an example object representing a player holding a controller strikes a pose that is set in advance according to the type of game, and for a first type of game, displaying the example image as an animation in which the example object rotates from an orientation in which the front of the example object is displayed to an orientation in which at least a part of the back of the example object is displayed; a game program that starts the game after the waiting period, displays at least action instructions indicating actions to be performed by the player in the game, evaluates the movement of the controller based on operation data acquired from the controller equipped with an inertial sensor, and progresses the game based on the evaluation.

2. The computer, during the standby period, displaying the model image by the model object imitating a player holding a controller in each hand; 2. The game program according to claim 1, wherein the evaluation is made based on first operation data acquired from a first controller and second operation data acquired from a second controller in the game.

3. 3. The game program according to claim 2, wherein the first type of game includes a second type of game in which the pose is set asymmetrically with respect to the example object.

4. The computer, prompting the player to select which of the left and right hands is to be used as a dominant hand at a predetermined scene before the plurality of types of games are executed in succession; for the second type of game, according to the set dominant hand, In displaying the model image, the model object is made to take a first pose or a second pose that is a left-right inversion of the first pose; The game program according to claim 3 , wherein the evaluation is performed by switching the first operation data and the second operation data used for the evaluation in the game.

5. The computer, for a third type of game included in the first type of game, displaying the model image as an animation of the model object rotating from a direction in which a front portion of the model object is displayed to a direction in which a diagonally rear portion of the model object is displayed; The game program according to claim 2, wherein for a fourth type of game included in the first type of game, the model image is displayed as an animation rotating from an orientation in which the front of the model object is displayed to an orientation in which the rear portion is displayed.

6. 6. The game program according to claim 5, wherein the third type of game is a game in which the pose is set such that the left and right hands are positioned in front of the model object.

7. The computer, 3. The game program of claim 2, wherein for a fifth type of game not included in the first type of game, in which the pose is set to be symmetrical to the model object, the model image is displayed as an animation in which the front or back of the model object remains oriented.

8. The computer, displaying the example image by drawing the example object in a virtual space based on a virtual camera; 8. A game program according to claim 1, wherein, for the first type of game, the model object or the virtual camera is rotated from a position where the front of the model object faces the virtual camera to a position where the rear or diagonally rear of the model object faces the virtual camera, thereby displaying the model image.

9. The computer, 9. The game program according to claim 8, wherein, for the first type of game, the model object or the virtual camera is rotated in the model image while the model object is animated to assume the pose, and the model image is displayed.

10. A game system having a processor and capable of continuously executing a plurality of types of games, The processor: For each of said games played in succession, during a waiting period before the start of the game, a model image is displayed in which a model object representing a player holding a controller strikes a pose that is set in advance according to the type of game, and for a first type of game, the model image is displayed as an animation in which the model object rotates from a direction in which the front of the model object is displayed to a direction in which at least a part of the back of the model object is displayed; a game system that starts the game after the waiting period, displays at least action instructions indicating actions to be performed by the player in the game, evaluates the movement of the controller based on operation data acquired from the controller equipped with an inertial sensor, and progresses the game based on the evaluation.

11. The processor: during the standby period, displaying the model image by the model object imitating a player holding a controller in each hand; The game system according to claim 10 , wherein the evaluation is made based on first operation data acquired from a first controller and second operation data acquired from a second controller in the game.

12. The game system according to claim 11 , wherein the first type of game includes a second type of game in which the pose is set asymmetrically with respect to the example object.

13. The processor: setting which hand of the player is to be the dominant hand at a predetermined scene before the plurality of types of games are continuously executed; For the second type of game, according to the set dominant hand, In displaying the model image, the model object is made to take a first pose or a second pose that is a left-right inversion of the first pose; The game system according to claim 12 , wherein the evaluation is performed by switching the first operation data and the second operation data used for the evaluation in the game.

14. The processor: For a third type of game included in the first type of game, the model image is displayed as an animation of the model object rotating from a direction in which a front side of the model object is displayed to a direction in which a diagonally rear side of the model object is displayed; The game system according to claim 11, wherein for a fourth type of game included in the first type of game, the model image is displayed as an animation rotating from an orientation in which the front of the model object is displayed to an orientation in which the rear portion is displayed.

15. The game system according to claim 14 , wherein the third type of game is a game in which the pose is set such that the left and right hands are positioned in front of the example object.

16. The processor: The game system described in claim 11, wherein for a fifth type of game not included in the first type of game, in which the pose is set to be symmetrical to the model object, the model image is displayed as an animation in which the front or back of the model object remains oriented.

17. The processor: displaying the example image by drawing the example object in a virtual space based on a virtual camera; 17. A game system according to claim 10, wherein for the first type of game, the model image is displayed by rotating the model object or the virtual camera from a positional relationship in which the front of the model object faces the virtual camera to a positional relationship in which the rear or diagonally rear of the model object faces the virtual camera.

18. The processor:

18. The game system according to claim 17, wherein for the first type of game, the model image is displayed by rotating the model object or the virtual camera while causing the model object to animate in the pose.

19. A gaming device that includes a processor and that executes multiple types of games in succession, The processor: For each of said games played in succession, during a waiting period before the start of the game, a model image is displayed in which a model object representing a player holding a controller strikes a pose that is set in advance according to the type of game, and for a first type of game, the model image is displayed as an animation in which the model object rotates from a direction in which the front of the model object is displayed to a direction in which at least a part of the back of the model object is displayed; a game device that starts the game after the waiting period, displays at least action instructions indicating actions to be performed by the player in the game, evaluates the movement of the controller based on operation data acquired from the controller equipped with an inertial sensor, and progresses the game based on the evaluation.

20. A game processing method for causing a computer of an information processing device to continuously execute a plurality of types of games, comprising: The computer, For each of said games played in succession, during a waiting period before the start of the game, displaying an example image in which an example object representing a player holding a controller strikes a pose that is set in advance according to the type of game, and for a first type of game, displaying the example image as an animation in which the example object rotates from an orientation in which the front of the example object is displayed to an orientation in which at least a part of the back of the example object is displayed; a game processing method that starts the game after the waiting period, displays at least action instructions indicating actions to be performed by the player in the game, evaluates the movement of the controller based on operation data acquired from the controller equipped with an inertial sensor, and progresses the game based on the evaluation.

21. The computer, during the standby period, displaying the model image by the model object imitating a player holding a controller in each hand; 21. The game processing method according to claim 20, wherein the evaluation is made based on first operation data acquired from a first controller and second operation data acquired from a second controller in the game.

22. 22. The game processing method according to claim 21, wherein the first type of game includes a second type of game in which the pose is set to be asymmetrical with respect to the example object.

23. The computer, prompting the player to select which of the left and right hands is to be used as a dominant hand at a predetermined scene before the plurality of types of games are executed in succession; for the second type of game, according to the set dominant hand, In displaying the model image, the model object is made to take a first pose or a second pose that is a left-right inversion of the first pose; The game processing method according to claim 22, wherein the evaluation is performed by switching the first operation data and the second operation data used for the evaluation in the game.

24. The computer, for a third type of game included in the first type of game, displaying the model image as an animation of the model object rotating from a direction in which a front portion of the model object is displayed to a direction in which a diagonally rear portion of the model object is displayed; 22. The game processing method according to claim 21, wherein for a fourth type of game included in the first type of game, the model image is displayed as an animation rotating from an orientation in which the front of the model object is displayed to an orientation in which the rear part is displayed.

25. 25. The game processing method according to claim 24, wherein the third type of game is a game in which the pose is set such that the left and right hands are positioned in front of the example object.

26. The computer, 22. The game processing method according to claim 21, wherein for a fifth type of game not included in the first type of game, in which the pose is set to be symmetrical to the model object, the model image is displayed as an animation in which the front or back of the model object remains oriented.

27. The computer, displaying the example image by drawing the example object in a virtual space based on a virtual camera; 27. A game processing method according to claim 20, wherein for the first type of game, the model image is displayed by rotating the model object or the virtual camera from a positional relationship in which the front of the model object faces the virtual camera to a positional relationship in which the rear or diagonally rear of the model object faces the virtual camera.

28. The computer, 28. The game processing method according to claim 27, wherein, for the first type of game, the model object or the virtual camera is rotated in the model image while the model object is animated to assume the pose, and the model image is displayed.

Citation Information

Patent Citations

  • Information processing method, information processing program, and information processing device

    JP2018195172A

  • Information processing program, information processing system, information processing apparatus, and information processing method

    JP2021010561A

  • Game program, information processing system, information processing apparatus, and game processing method

    JP2022081163A