Information processing program, information processing device, information processing system, and information processing method
The information processing program restricts character movement using height and angle thresholds to prevent unintended traversal of terrain features, maintaining game balance and player enjoyment.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- NINTENDO CO LTD
- Filing Date
- 2024-10-16
- Publication Date
- 2026-06-03
AI Technical Summary
Existing game engine techniques allow characters with spherical collisions to slide along collision points, enabling them to potentially overcome obstacles intended to be impassable, disrupting the intended game balance and player experience.
Implement an information processing program that includes a player character control mechanism, reference position determination, and forced movement logic to restrict character movement based on height thresholds and terrain angles, ensuring the character does not cross unintended terrain features.
This solution effectively limits character movement to the intended range, maintaining game balance and providing an enjoyable player experience by preventing unintended traversal of obstacles.
Smart Images

Figure 0007869839000001 
Figure 0007869839000002 
Figure 0007869839000003
Abstract
Description
Technical Field
[0001] The present disclosure relates to game processing in which a player object can perform an action (e.g., jump) to cross a predetermined step.
Background Art
[0002] Conventionally, a technique (game engine) capable of setting settings related to character collisions has been known (e.g., Non-Patent Document 1). In such a technique, when a character with a spherical collision set rides on a predetermined object, depending on whether the predetermined parameters related to the collision are turned on or off, the character can be made to slide or not slide in accordance with the collision of the object.
Prior Art Documents
Non-Patent Documents
[0003]
Non-Patent Document 1
Summary of the Invention
Problems to be Solved by the Invention
[0004] The above technique simply allowed a character with a spherical collision to slide along the collision point, depending on the parameter settings. Now, consider a scenario where there is a step of a height that the character should not be able to cross. In this case, it was sometimes possible to forcibly overcome such a step by making the character jump. For example, if the difference between the jump height and the step height was small, even if the character was set to slide along the collision point, it was sometimes possible to forcibly overcome it with the momentum of the jump. As a result, it was sometimes possible for the character to move beyond the range of movement intended by the game developers.
[0005] Therefore, the object of this disclosure is to provide an information processing program, information processing device, information processing system, and information processing method that can restrict the range of movement of a character to an appropriate range. [Means for solving the problem]
[0006] To achieve the above objective, the following configuration examples can be given.
[0007] (Composition 1) Configuration 1 is an information processing program executed in the computer of an information processing device, which causes the computer to function as a player character control means, a reference position determination means, a determination means, and a forced movement means. The player character control means causes the player character to move and perform target actions in the virtual space in response to user input. The reference position determination means determines the reference position based on the position of the player character prior to when the player character performs a target action at the first position. The determination means determines whether the height of the second position relative to the reference position is greater than or equal to a height threshold when the player character comes into contact with a terrain object at the second position as a result of the player character performing a target action. The forced movement means determines whether the height of the second position relative to the reference position is greater than or equal to a height threshold If it is determined that the value is greater than or equal to the specified value, the player character is moved either in the direction away from the terrain object that is on the first position relative to the terrain object, or in the downward direction along the terrain object, as the forced movement direction.
[0008] According to the above configuration, based on a determination using a height threshold, it is possible to control the player character so that it does not move beyond terrain objects. This allows the player character's movement range to be limited to an appropriate range (the range intended by the developer).
[0009] (Configuration 2) Configuration 2 is the same as Configuration 1, but the player character control means may cause the player character to jump based on user input as the target action. Furthermore, the reference position determination means may determine the position where the player character started jumping (first position) as the reference position.
[0010] With the above configuration, it is possible to ensure that areas that you do not want to be crossed by jumping cannot be crossed.
[0011] (Composition 3) Configuration 3 is an example in Configuration 2 where the reference position determination means determines the position of the player character's feet when the player character starts jumping as the reference position.
[0012] With the above configuration, even if the player character's height (size) changes during gameplay, for example, by switching playable characters or by some gimmick changing the player character's appearance, the same value can be used as the height threshold.
[0013] (Composition 4) Configuration 4 is a configuration in which, in configuration 3, the player character control means may control the jump such that the height to which the player character's feet rise when the jump is the same whether the player character's feet are in contact with the ground or whether the player character is floating on the water surface and the player character's feet are below the water surface.
[0014] With the above configuration, it becomes unnecessary to use different height thresholds depending on where the player character jumps. This simplifies the processing.
[0015] (Composition 5) Configuration 5 is a configuration in which, in configurations 1 to 4 above, the forced movement means may move the player character in the forced movement direction only if the difference in the inclination of the surface of the terrain object at the second position with respect to the horizontal direction is greater than or equal to an angle threshold.
[0016] According to the above configuration, forced movement is only triggered if the second position is on a steep slope where, for example, standing would seem unnatural. This prevents the user from feeling uncomfortable due to forced movement when, for some reason, they cross a high step without hitting a corner, or when they land on a gentle slope.
[0017] (Composition 6) Configuration 6, in configurations 1 to 5 above, may use a direction based on the normal direction at the second position of the terrain object as the forced movement direction for the forced movement means.
[0018] With the above configuration, the player character can be moved by bouncing off the surface of the terrain object it comes into contact with. This makes it easier for the user to recognize that a terrain object cannot be jumped over or overcome.
[0019] (Composition 7) Configuration 7: In the above Configuration 6, for the normal direction at the second position of the terrain object, when there is an upward component in the normal direction, the direction obtained by setting the upward component to 0 in the normal direction may be used as the forced movement direction.
[0020] According to the above configuration, it is possible to prevent unnatural repulsion in the direction opposite to the gravitational direction.
[0021] (Configuration 8) Configuration 8: In the above Configurations 1 to 7, when the upward component in the normal direction at the second position of the terrain object is greater than the upward component threshold value, the direction from the second position toward the first position may be used as the forced movement direction.
[0022] According to the above configuration, if the second position is a surface close to horizontal and it is assumed to move in the normal direction, the horizontal component (lateral component) in the normal direction becomes small, so the direction of the horizontal component changes greatly due to a slight difference in concavity and convexity at the second position. Therefore, when the second position is a surface close to horizontal, by not using the normal direction and setting the direction from the second position toward the first position as the forced movement direction, it is possible to prevent movement that repels the user in a direction that feels uncomfortable.
[0023] (Configuration 9) Configuration 9: In the above Configurations 1 to 8, when it is determined that the height of the second position with respect to the reference position is less than the height threshold value, the player character may be moved based on the collision between the terrain object and the player character.
[0024] According to the above configuration, if the height of the second position with respect to the reference position is less than the height threshold value, it can be processed by normal collision detection. Therefore, the movement of the player character does not give the user an uncomfortable feeling more than necessary.
[0025] (Configuration 10) Configuration 10, in Configurations 1 to 9 above, may move the player character in the direction of forced movement if the player character makes contact with the terrain object at a second position while moving along the terrain object as a result of the player character performing a target action, and if it is determined that the height of the second position relative to the reference position is equal to or greater than the height threshold.
[0026] With the above configuration, if a user attempts to cross a terrain object by performing a vertical jump, the user can be made aware that it is a terrain object that cannot be crossed.
[0027] (Composition 11) In configuration 11, the mesh of the terrain object and the collision of the terrain object may coincide in configurations 1 to 10 described above.
[0028] With the above configuration, players can make a rough judgment by visually inspecting whether or not it is possible to cross the elevation difference of terrain objects. [Effects of the Invention]
[0029] According to this embodiment, the movement range of the player character can be restricted to, for example, the movement range intended by the game developer. This allows the player to be provided with gameplay that has an appropriate game balance, thereby improving the enjoyment of the game. [Brief explanation of the drawing]
[0030] [Figure 1] This diagram shows an example of the main unit 2 with the left controller 3 and right controller 4 attached. [Figure 2] This diagram shows an example of the state in which the left controller 3 and right controller 4 have been removed from the main unit 2. [Figure 3] A six-view drawing showing an example of the main unit 2. [Figure 4] A six-view drawing showing an example of the left controller 3. [Figure 5]A six-view drawing showing an example of the right controller 4. [Figure 6] Block diagram showing an example of the internal configuration of the main unit 2. [Figure 7] Block diagram showing an example of the internal configuration of the main unit 2, left controller 3, and right controller 4. [Figure 8] An example of a game screen according to this embodiment. [Figure 9] A diagram illustrating the overview of the process according to this embodiment. [Figure 10] A diagram illustrating the overview of the process according to this embodiment. [Figure 11] A diagram illustrating the overview of the process according to this embodiment. [Figure 12] A diagram illustrating the overview of the process according to this embodiment. [Figure 13] A diagram illustrating the overview of the process according to this embodiment. [Figure 14] A diagram illustrating the overview of the process according to this embodiment. [Figure 15] A diagram illustrating the overview of the process according to this embodiment. [Figure 16] A diagram illustrating the overview of the process according to this embodiment. [Figure 17] A diagram illustrating the overview of the process according to this embodiment. [Figure 18] A diagram illustrating the overview of the process according to this embodiment. [Figure 19] A diagram to explain vertical jump [Figure 20] A diagram to explain vertical jump [Figure 21] A diagram to explain vertical jump [Figure 22] A diagram to explain water surface jumping. [Figure 23] A diagram to explain landing on a slope. [Figure 24] A memory map showing an example of various data stored in DRAM85. [Figure 25] An example of player object data 302 [Figure 26]Example of operation data 306 [Figure 27] Flowchart showing details of game processing according to this embodiment [Figure 28] A flowchart showing the details of the PC movement control process. [Figure 29] A flowchart showing the details of the process during the jump. [Figure 30] Flowchart showing details of the rebound movement process [Figure 31] An example of a rebound movement [Figure 32] An example of a rebound movement [Modes for carrying out the invention]
[0031] One embodiment will be described below.
[0032] The following describes a game system according to an example of this embodiment. An example of the game system 1 in this embodiment includes a main unit (information processing device; functioning as the game device main unit in this embodiment) 2, a left controller 3, and a right controller 4. The left controller 3 and the right controller 4 are 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. Alternatively, the game system 1 can be used with the main unit 2 and the left controller 3 and right controller 4 as separate components (see Figure 2). The hardware configuration of the game system 1 in this embodiment will be described below, followed by a description of the control of the game system 1 in this embodiment.
[0033] Figure 1 shows an example of the main unit 2 with the left controller 3 and right controller 4 attached. As shown in Figure 1, the left controller 3 and right controller 4 are attached to the main unit 2 and integrated together. The main unit 2 is a device that performs various processes (e.g., game processing) in the game system 1. The main unit 2 is equipped with a display 12. The left controller 3 and right controller 4 are devices equipped with operation parts for user input.
[0034] Figure 2 shows an example of the left controller 3 and right controller 4 being removed from the main unit 2. As shown in Figures 1 and 2, the left controller 3 and right controller 4 are detachable from the main unit 2. In the following, the left controller 3 and right controller 4 will be collectively referred to as "controllers".
[0035] Figure 3 is a six-view drawing showing an example of the main unit 2. As shown in Figure 3, the main unit 2 includes a roughly 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 roughly rectangular in shape.
[0036] The shape and size of the housing 11 are arbitrary. For example, the housing 11 may be portable. The main unit 2 alone, or the integrated unit in which the left controller 3 and right controller 4 are attached to the main unit 2, may be a portable device. The main unit 2 or the integrated unit may be a handheld device. The main unit 2 or the integrated unit may also be a portable device.
[0037] As shown in Figure 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.
[0038] Furthermore, the main unit 2 is equipped with 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 capacitive touch panel). However, the touch panel 13 may be of any type, for example, a type that allows single-touch input (for example, a resistive touch panel).
[0039] The main unit 2 is equipped with a speaker (i.e., speaker 88 shown in Figure 6) inside the housing 11. As shown in Figure 3, speaker holes 11a and 11b are formed on the main surface of the housing 11. The sound output from speaker 88 is emitted from these speaker holes 11a and 11b, respectively.
[0040] Furthermore, the main unit 2 is equipped with a left terminal 17, which is a terminal for the main unit 2 to communicate with the left controller 3 via wired connection, and a right terminal 21, which is for the main unit 2 to communicate with the right controller 4 via wired connection.
[0041] As shown in Figure 3, the main unit 2 is equipped with a slot 23. The slot 23 is located 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. The predetermined type of storage medium is, for example, a storage medium (e.g., a dedicated memory card) specifically for the game system 1 and similar information processing devices. 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 is also equipped with a power button 28.
[0042] The main unit 2 is equipped with a lower terminal 27. The lower terminal 27 is a terminal for the main unit 2 to communicate with the cradle. In this embodiment, the lower terminal 27 is a USB connector (more specifically, a female connector). When the integrated device or the main unit 2 alone is placed on the cradle, the game system 1 can display the 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 integrated 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).
[0043] Figure 4 is a six-view drawing showing an example of the left controller 3. As shown in Figure 4, the left controller 3 includes a housing 31. In this embodiment, the housing 31 has a vertically elongated shape, that is, it is long in the vertical direction (the z-axis direction shown in Figure 4). When the left controller 3 is detached from the main device 2, it can also be held in a vertically elongated orientation. The housing 31 is shaped and sized to be held with one hand, especially the left hand, when held in a vertically elongated orientation. The left controller 3 can also be held in a horizontally elongated orientation. When the left controller 3 is held in a horizontally elongated orientation, it may be held with both hands.
[0044] 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 Figure 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 direction. The user can input direction (and magnitude according to the angle of tilt) by tilting the left stick 32. In addition, the left controller 3 may be equipped with a directional pad or a slide stick that allows slide input instead of an analog stick as the directional input unit. Furthermore, in this embodiment, input by pressing the left stick 32 is also possible.
[0045] The left controller 3 is equipped with various operation buttons. The left controller 3 has four operation buttons 33-36 (specifically, a right direction button 33, a down direction button 34, an up direction button 35, and a left direction button 36) on the main surface of the housing 31. Furthermore, the left controller 3 is 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 side of the housing 31. In addition, the left controller 3 is equipped with a second L button 43 and a second R button 44 on the side of the housing 31 that is attached when mounted to the main unit 2. These operation buttons are used to give instructions according to various programs (e.g., OS programs and application programs) executed on the main unit 2.
[0046] Furthermore, the left controller 3 is equipped with a terminal 42 for wired communication between the left controller 3 and the main unit 2.
[0047] Figure 5 is a six-view drawing showing an example of the right controller 4. As shown in Figure 5, the right controller 4 includes a housing 51. In this embodiment, the housing 51 has a vertically elongated shape, that is, it is long in the vertical direction (the z-axis direction shown in Figure 5). The right controller 4 can also be held in a vertically elongated orientation when detached from the main unit 2. The housing 51 is shaped and sized to be held with one hand, especially the right hand, when held in a vertically elongated orientation. The right controller 4 can also be held in a horizontally elongated orientation. When the right controller 4 is held in a horizontally elongated orientation, it may be held with both hands.
[0048] The right controller 4, like the left controller 3, 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 directional pad or a slide stick capable of slide input instead of the analog stick. The right controller 4, like the left controller 3, is equipped with four operation buttons 53-56 (specifically, A button 53, B button 54, X button 55, and Y button 56) on the main surface of the housing 51. Furthermore, the right controller 4 is 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 side of the housing 51. The right controller 4, like the left controller 3, is also equipped with a second L button 65 and a second R button 66.
[0049] Furthermore, the right controller 4 is equipped with a terminal 64 for wired communication between the right controller 4 and the main unit 2.
[0050] Figure 6 is a block diagram showing an example of the internal configuration of the main unit 2. In addition to the configuration shown in Figure 3, the main unit 2 includes the components 81-91, 97, and 98 shown in Figure 6. Some of these components 81-91, 97, and 98 may be mounted on an electronic circuit board as electronic components and housed within the housing 11.
[0051] The main unit 2 includes a processor 81. The processor 81 is an information processing unit that performs various information processing operations performed in the main unit 2, and may consist of, for example, only a CPU (Central Processing Unit), or it may consist of an SoC (System-on-a-chip) that includes multiple functions such as CPU function and GPU (Graphics Processing Unit) function. The processor 81 performs various information processing operations by executing information processing programs (for example, game programs) stored in a storage unit (specifically, an internal storage medium such as flash memory 84, or an external storage medium installed in slot 23).
[0052] The main unit 2 includes, as an example of an internal storage medium built into itself, a flash memory 84 and a DRAM (Dynamic Random Access Memory) 85. The flash memory 84 and DRAM 85 are connected to the processor 81. The flash memory 84 is a memory mainly used to store various types of data (which may be programs) stored in the main unit 2. The DRAM 85 is a memory used to temporarily store various types of data used in information processing.
[0053] The main unit 2 is equipped with 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 slot 23 and reads and writes data to a predetermined type of storage medium (for example, a dedicated memory card) installed in slot 23, according to instructions from the processor 81.
[0054] The processor 81 performs the above-mentioned information processing by appropriately reading and writing data to and from the flash memory 84 and DRAM 85, as well as to each of the above-mentioned storage media.
[0055] The main unit 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 external devices via a network (specifically, wirelessly). In this embodiment, the network communication unit 82 communicates with external devices by connecting to a wireless LAN using a method compliant with the Wi-Fi standard as a first communication mode. The network communication unit 82 also performs wireless communication with other main unit 2 of the same type using a predetermined communication method (for example, communication using a proprietary protocol or infrared communication) as a second communication mode. The wireless communication using the second communication mode is possible with other main unit 2 located within a closed local network area, and realizes a function that enables so-called "local communication" in which data is sent and received by communicating directly between multiple main unit 2.
[0056] The main unit 2 includes a controller communication unit 83. The controller communication unit 83 is connected to the processor 81. The controller communication unit 83 communicates wirelessly with the left controller 3 and / or the right controller 4. The communication method between the main unit 2 and the left controller 3 and the right controller 4 is arbitrary, but in this embodiment, the controller communication unit 83 communicates with the left controller 3 and with the right controller 4 in accordance with the Bluetooth® standard.
[0057] The processor 81 is connected to the left terminal 17, right terminal 21, and lower terminal 27 described above. When the processor 81 communicates with the left controller 3 via a wired connection, it 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 the processor 81 communicates with the right controller 4 via a wired connection, it 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 the processor 81 communicates with the cradle, it transmits data to the cradle via the lower terminal 27. Thus, in this embodiment, the main unit 2 can perform both wired and wireless communication with the left controller 3 and the right controller 4, respectively. Furthermore, when the left controller 3 and the right controller 4 are mounted on the main unit 2 as an integrated unit, or when the main unit 2 alone is mounted on 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.
[0058] Here, the main unit 2 can communicate simultaneously (in other words, in parallel) with multiple left controllers 3. Furthermore, the main unit 2 can 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 respective sets of left controllers 3 and right controllers 4. For example, while the first user inputs to the main unit 2 using the first set of left controllers 3 and right controllers 4, the second user can input to the main unit 2 using the second set of left controllers 3 and right controllers 4.
[0059] The main unit 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 signals from the touch panel 13, the touch panel controller 86 generates data indicating, for example, the position where a touch input occurred, and outputs it to the processor 81.
[0060] The display 12 is also connected to the processor 81. The processor 81 displays images generated (for example, by performing the above information processing) and / or images acquired from an external source on the display 12.
[0061] 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 terminals 25, as well as to the processor 81. The codec circuit 87 is a circuit that controls the input and output of audio data to the speakers 88 and the audio input / output terminals 25.
[0062] The main unit 2 comprises 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 in the figures, the power control unit 97 is also connected to various parts of the main unit 2 (specifically, the parts that receive power from the battery 98, the left terminal 17, and the right terminal 21). Based on commands from the processor 81, the power control unit 97 controls the power supply from the battery 98 to the aforementioned parts.
[0063] The battery 98 is also connected to the lower terminal 27. When an external charging device (for example, a cradle) is connected to the lower terminal 27 and power is supplied to the main unit 2 via the lower terminal 27, the supplied power charges the battery 98.
[0064] Figure 7 is a block diagram showing an example of the internal configuration of the main unit 2, the left controller 3, and the right controller 4. Note that the details of the internal configuration of the main unit 2 are shown in Figure 6 and are therefore omitted in Figure 7.
[0065] The left controller 3 includes a communication control unit 101 that communicates with the main unit 2. As shown in Figure 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 by wired communication via the terminal 42 and by wireless communication without using the terminal 42. The communication control unit 101 controls the method of communication that the left controller 3 performs with 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 performs wireless communication with the main unit 2 (specifically, the controller communication unit 83). Wireless communication between the controller communication unit 83 and the communication control unit 101 is performed according to, for example, the Bluetooth® standard.
[0066] The left controller 3 also includes a memory 102, such as flash memory. The communication control unit 101 is composed of, for example, a microcontroller (also called a microprocessor) and performs various processes by executing firmware stored in the memory 102.
[0067] The left controller 3 is equipped with buttons 103 (specifically, buttons 33-39, 43, 44, and 47). The left controller 3 is also equipped with a left stick 32. Each button 103 and the left stick 32 repeatedly output information about the operations performed on them to the communication control unit 101 at appropriate intervals.
[0068] 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 Figure 4). Note that the acceleration sensor 104 may also detect acceleration in 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 Figure 4). Note that the angular velocity sensor 105 may also 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 from the acceleration sensor 104 and the angular velocity sensor 105 are repeatedly output to the communication control unit 101 at appropriate timings.
[0069] The communication control unit 101 acquires information related to input (specifically, information related to operation or detection results from sensors) from each input unit (specifically, each button 103, the 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 processing on the acquired information), to the main unit 2. The operation data is transmitted repeatedly at a rate of once per predetermined time. The interval at which information related to input is transmitted to the main unit 2 may or may not be the same for each input unit.
[0070] When the above operation data is transmitted 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 the left stick 32 based on the operation data. In addition, 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).
[0071] The left controller 3 includes a power supply unit 108. In this embodiment, the power supply unit 108 includes 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).
[0072] As shown in Figure 7, the right controller 4 includes a communication control unit 111 that communicates with the main unit 2. The right controller 4 also includes a memory 112 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 the 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 by wired communication via the terminal 64 and by wireless communication without the terminal 64 (specifically, communication according to the Bluetooth® standard), and controls the method of communication that the right controller 4 performs with the main unit 2.
[0073] The right controller 4 is equipped with the same inputs as the left controller 3. Specifically, it includes buttons 113, a right stick 52, and inertial sensors (accelerometer 114 and angular velocity sensor 115). Each of these inputs has the same function and operates in the same way as the inputs of the left controller 3.
[0074] The right controller 4 is equipped with a power supply unit 118. The power supply unit 118 has the same functions and operates in the same manner as the power supply unit 108 of the left controller 3.
[0075] [Overview of game processing in this embodiment] Next, an overview of the operation of the game processing performed in the game system 1 according to this embodiment will be described. As described above, in the game system 1, the main unit 2 is configured so that the left controller 3 and the right controller 4 can be attached and detached. When playing a game with the left controller 3 and the right controller 4 attached to the main unit 2, the game image is output to the display 12. In addition, when the main unit 2 alone, with the left controller 3 and the right controller 4 removed, is mounted in the cradle, the main unit 2 can also output the game image to a stationary monitor or the like via the cradle. In this embodiment, the latter case will be described as an example. Specifically, the main unit 2 alone, with the left controller 3 and the right controller 4 removed, is mounted in the cradle, and the main unit 2 outputs the game image and the like to a stationary monitor or the like via the cradle.
[0076] [Screen example] Figure 8 shows an example of a game screen generated by capturing the virtual game space, which serves as the setting for the game, with a virtual camera. In this embodiment, the virtual game space is shown as a three-dimensional space, but in other embodiments, it may be a two-dimensional space. Also, in this embodiment, a third-person view screen is shown as an example, but a first-person view screen may also be shown. In Figure 8, a player character object (hereinafter referred to as PC) 201 is displayed. PC 201 is the object that the user interacts with. In this embodiment, a human-shaped object is shown as an example, but in other embodiments, PC 201 does not have to be human-shaped; for example, it may be an object modeled after a quadrupedal animal.
[0077] Furthermore, Figure 8 shows a terrain object with a "step" to the left of PC201. The process described in this embodiment is for controlling whether or not PC201 will overcome this step when it performs a predetermined action. Specifically, PC201 can perform a predetermined action, such as "jumping," based on user operations. The process determines whether or not to overcome the step when the PC jumps towards it, and controls the movement of PC201 accordingly.
[0078] Herein, I would like to add some clarification regarding the "jump" mentioned above. In this embodiment, "jump" is not limited to those performed based on the user's (voluntary) jump operation as described above. For example, it also includes cases where PC201 automatically jumps (is made to jump) by stepping onto a jump pad or spring installed in the virtual space. Furthermore, for example, if PC201 is a bird object and is gliding, actions such as "flapping its wings" to temporarily ascend may also be treated as equivalent to "jump" in this context.
[0079] Furthermore, in this embodiment, for the sake of simplicity, we will describe an example where the direction of movement cannot be changed based on user input while PC201 is jumping. In other embodiments, the direction of movement may be changed based on user input even while PC201 is jumping. In this case as well, the processing described below is applicable.
[0080] The control according to this embodiment will be described below, but first, as a premise for the following explanation, the assumed step will be briefly explained. From the perspective of game design, etc., the above step is assumed to be a step that, from the ground height, the game developers would not want the PC201 to jump over or not be allowed to jump over. In other words, the step can be said to have the role of restricting the range of movement of the PC201 (however, the processing described later will be executed without distinguishing what kind of step it is).
[0081] Next, we will explain the problems with using conventional methods when PC201 jumps towards a step that developers would not want it to cross. Figure 9 is a schematic diagram showing the positional relationship between the step and PC201 in a planar manner (for example, in the xy plane). Here, we assume that the height of the step is slightly higher than the highest point that PC201 can reach with its feet during the jump. In other words, the positional relationship is such that when jumping vertically from the height of the base of the step, PC201 will just barely not reach the top of the step (it should be noted that there are many cases where such a step arrangement is necessary from the perspective of game design and game balance). In such a situation, if PC201's movement is performed using, for example, physics calculations, there was a possibility that the step that PC201 would not want it to cross could be crossed for some reason. For example, if PC201 is made to jump towards this step (for example, with a running start), the movement pattern shown in Figure 10 may occur. Figure 10 shows an example of movement when PC201's feet barely make contact with the corner of a step. In Figure 10, although PC201 briefly gets caught on the corner of the step, the physics calculations that take collision with the step into consideration result in propulsion and other forces acting on PC201, allowing it to continue moving forward. Therefore, if the game balance is adjusted on the premise that this step cannot be overcome, there is a risk that users will not be able to be provided with a game with an appropriate balance.
[0082] Here, regarding the aforementioned "unwanted" ledges, the following methods can be considered to more reliably prevent players from jumping over them. First, as shown in Figure 11, one could simply increase the height of the ledge in the above location. Another method, as shown in Figure 12, is to set the jump performance (maximum reach) of PC201 lower. In other words, this method creates a clear difference between the maximum reach and the height of the ledge. However, with these methods, the jump height becomes relatively low compared to the height of the ledge, and there is a risk that the exhilarating feeling of jumping will be lost. Also, especially if the ledge itself is made higher, there is a concern that the appearance and aesthetics will be compromised from the perspective of map design, etc. Taking these points into consideration, as an alternative method, for example, as shown in Figure 13, one could consider setting an invisible collision, like an "invisible wall," that is higher than the ledge, while keeping the appearance of the ledge the same. This makes it possible to reliably prevent players from jumping over the ledge without changing its appearance. However, in this case, for example, even when jumping from a slightly elevated platform, there is a risk of being blocked by the invisible wall, which can cause users to feel uneasy.
[0083] Therefore, taking the above points into consideration, in this embodiment, the following processing is performed to control the movement of the PC201 so that it does not have to overcome the aforementioned steps, and the movement range of the PC201 is within an appropriate range.
[0084] The outline and principle of the process according to this embodiment will be explained below using Figures 14 to 21. Figure 14 is a schematic diagram showing the positional relationship between PC201 and the step before PC201 jumps. In this embodiment, as an example of a collision set for PC201, a spherical collision centered on the center point of PC201 is shown. The radius of the spherical collision is 16 cm, and it is assumed to be large enough to cover the entire PC201. Furthermore, for the terrain object having the step, it is assumed that a collision matching the mesh model of the terrain object is set.
[0085] From the state shown in Figure 14, when the user performs an operation to make PC201 jump (for example, by pressing button A 53), movement parameters such as the initial velocity and acceleration related to the jump are calculated and set. Then, as shown in Figure 15, PC201 moves (jumps) along a trajectory based on these movement parameters. In this embodiment, the position of PC201's feet at the start of the jump is stored as the first position. Hereafter, this first position will be referred to as the "reference position".
[0086] Here, we will add some details about the "reference position" mentioned above. In this embodiment, we assume a human-shaped object with legs, so the position where the legs are in contact with the ground is used as the reference position. However, if PC201 is an object without legs (for example, a snail), the position where it is in contact with the ground can be used as the reference position. For example, the position approximately in the center of the contact surface of such an object may be used as the reference position.
[0087] As described above, after PC201 begins jumping, let's assume that the collision at the corner of the step and the collision at the base of PC201 come into contact, as shown in Figure 16. When such contact occurs, the contact location is stored as a second position. Furthermore, in this embodiment, it is determined whether the vertical height of the contact location relative to the above reference position (hereinafter referred to as the determination height) is equal to or greater than a predetermined threshold (hereinafter referred to as the height threshold). As an example of this height, in this embodiment, we assume that the height threshold is 35 cm and the height of the highest point reached by the jump is 37 cm (both scales in virtual space). If, as a result of this determination, the determination height is equal to or greater than the height threshold, movement control is performed to prevent PC201 from crossing the step. Specifically, PC201 is forcibly moved in a direction away from the contact location (terrain object) and towards the reference position, causing it to bounce back (hereinafter, this forced movement is referred to as bounce movement). In other words, even if the object could technically (barely) be overtaken without using a height threshold, the system controls the movement to prevent it from overtaking by using rebound movement. On the other hand, if the height used for the above determination is less than the height threshold, rebound movement is not performed, and (normal) movement control is performed based on the collision relationship between the terrain object and PC201.
[0088] Figure 17 shows an example of the rebound movement described above. In this embodiment, the rebound movement is basically performed in the direction normal to the surface of the collision point. However, when determining the direction of movement in such a rebound, the upward component is not reflected. In the example in Figure 17, the direction of travel related to the jump is to the left in Figure 17, and the movement is in the opposite direction to that direction of travel (to the right in Figure 17). In this case, immediately after contacting the corner of the step as in Figure 16, the trajectory is such that it rebounds to the right and falls, rather than rebounding in the upper right direction in Figure 17. Finally, as shown in Figure 18, PC201 lands on the ground.
[0089] Furthermore, consider the case where PC201 (its collision) is in close contact with the wall of the step, as shown in Figure 19, and then jumps vertically, as shown in Figure 20. In this case, PC201 moves upward along the wall while remaining in close contact. As a result, when the vertical height of the contact point between the PC201 collision and the wall, relative to the reference position, reaches a height threshold (for example, when PC201 (its collision) comes into contact with the corner of the step), a rebound movement occurs in the direction of the reference position (to the right in Figure 21), as shown in Figure 21.
[0090] Thus, in this embodiment, the decision of whether or not to perform rebound movement (i.e., prevent overcoming the step) is made based on whether or not the above-mentioned determination height is equal to or greater than the height threshold. Therefore, for example, movement control in which PC201 simply charges forward, hits a wall, and bounces back is not control based on whether or not the above-mentioned determination height is equal to or greater than the height threshold. Such control is different from the control in this embodiment.
[0091] By the way, the above example assumes that PC201 jumps from the ground, but other games that allow jumps called "water surface jumps" are also possible. For example, there may be games in which PC201 can jump from a state where it is floating on the water surface (or swimming), as shown in Figure 22. In this case, the reference position should be the position of PC201's feet. In other words, in the case of a water surface jump, the reference position should not be the water surface, but rather the position of PC201's feet. This makes it possible to use the same height threshold for both ground jumps and water surface jumps. For example, when PC201 is floating on the water surface, let's assume that PC201's feet are 15 cm below the water surface. And let's assume that the height of a water surface jump (maximum reach) is 37 cm (22 cm from the water surface). In this case, if the reference position were the water surface, it would be necessary to use a different height threshold than when jumping from the ground. Therefore, even in the case of water surface jumps, by using the PC201's feet as the reference position, the height (change) of the feet when jumping will be the same as when jumping from the ground, making it possible to use the same height threshold as above for both. This is expected to reduce the development burden.
[0092] Furthermore, in this embodiment, if the landing location after a jump is a "slope," the rebound movement described above is prevented. In this embodiment, a "slope" is defined as an inclined surface (path) where PC201 can land without feeling unnatural. For example, an inclined surface with an angle of inclination of 5 degrees or more and less than 45 degrees. In this embodiment, whether or not a terrain object with such an inclined surface is a "slope" is determined by defining it as such in advance (details of the determination method will be described later). This is because, for example, when jumping and landing on a (somewhat gentle) uphill slope, it is possible that the landing location may be at a position where the "determination height is above the height threshold," as shown in Figure 23. If rebound movement is performed in such cases, it may cause discomfort to the user. Therefore, if the landing destination is a "slope," the determination and control related to rebound movement described above are not performed. In other words, if the landing is on a surface with a sufficiently large angle of inclination (an inclined surface that is too steep to land on unnaturally), the rebound movement described above will occur. This prevents causing discomfort to the user. Furthermore, it prevents restrictions on movement patterns, such as jumping up an incline.
[0093] [Details of the game processing in this embodiment] Next, the game processing in this embodiment will be described in more detail with reference to Figures 24 to 30. Note that this description will mainly focus on the processing related to the jumping motion control, and details of other game processing will be omitted.
[0094] [About the data used] First, we will explain the various data used in this game processing. Figure 24 is a memory map showing an example of the various data stored in the DRAM 85 of the main unit 2. The DRAM 85 of the main unit 2 stores at least the game program 301, player object data 302, reference position information 303, contact position information 304, terrain object data 305, and operation data 306.
[0095] Game program 301 is a program for executing the game processing in this embodiment.
[0096] The player object data 302 is data relating to the PC 201 mentioned above. Figure 25 shows an example of the data structure of the player object data 302. The player object data 302 includes at least position data 321, posture data 322, PC state 323, movement parameters 324, appearance data 325, and animation data 326.
[0097] Position data 321 is data indicating the current position of PC201 within the virtual game space. For example, position data 321 stores the 3D coordinates within the virtual game space. Pose data 322 is data indicating the current pose of PC201. For example, pose data 322 stores vector data indicating the direction PC201 is facing within the virtual game space.
[0098] PC state 323 is data indicating the current state of PC 201 in game processing. In this embodiment, with respect to the jump control described above, at least one of the following states may be set in PC state 323. "Grounding"... PC201 is not jumping. "Jumping"...This indicates that PC201 is in the process of moving by jumping. "Rebound movement in progress"...This indicates that PC201 is in the process of moving (forcibly) based on the rebound movement control described above.
[0099] Next, the movement parameters 324 are parameters used for controlling the movement of PC201. For example, the movement parameters 324 may include parameters that specify the movement speed, such as initial velocity and acceleration, and parameters that indicate the direction of movement.
[0100] The appearance data 325 is data that constitutes the appearance of PC201. For example, it includes 3D model data and texture data of PC201. The appearance data 325 may also include information for setting the shape and size of PC201's collisions.
[0101] Animation data 326 is data that defines the animations for various actions performed by PC201. For example, animation data 326 defines animation data corresponding to the states indicated by PC state 323 above.
[0102] Returning to Figure 23, next, the reference position information 303 is data indicating the coordinates of the reference position described above. The contact position information 304 is data indicating the coordinates of the contact position described above.
[0103] The terrain object data 305 is data for various terrain objects placed within the virtual section. The terrain object data 305 includes 3D model data showing the shape and size of each terrain object, as well as texture data. The terrain object data 305 may also include information for setting collisions for each object. In this embodiment, it is assumed that collisions matching the mesh of each terrain object are set as described above. This allows the user to visually determine to some extent whether or not a step can be jumped over. In other embodiments, the collision and the mesh may not strictly match, and there may be some discrepancies in size and shape. In other words, there may be discrepancies that do not cause the user to feel any discomfort, such as "there is an invisible wall." Even if there are such discrepancies that do not cause the user discomfort, the mesh and collision can be treated as if they "match" in substance.
[0104] Next, the operation data 306 is data obtained from the controller operated by the user. In other words, it is data that indicates the operation performed by the user. Figure 26 shows an example of the data structure of the operation data 306. The operation data 306 includes at least digital button data 361, right stick data 362, left stick data 363, right inertial sensor data 364, and left inertial sensor data 365. The digital button data 361 is data that indicates the pressed state of various buttons on the controller. The right stick data 362 is data that indicates the operation performed on the right stick 52. Specifically, it includes two-dimensional data in x and y. The left stick data 363 is data that indicates the operation performed on the left stick 32. The right inertial sensor data 364 is data that indicates the detection results of the inertial sensors of the acceleration sensor 114 and angular velocity sensor 115 of the right controller 4. Specifically, it includes 3-axis acceleration data and 3-axis angular velocity data. The left inertial sensor data 365 is data showing the detection results of the inertial sensors of the left controller 3, specifically the acceleration sensor 104 and the angular velocity sensor 105.
[0105] In addition, although not shown in the diagram, various data necessary for game processing, such as data related to non-player characters (NPCs), are also stored in DRAM85.
[0106] [Details of the process performed by processor 81] Next, the details of the game processing in this embodiment will be described. Note that the flowchart shown below is merely one example of the processing process. Therefore, the order of each step may be changed if similar results can be obtained. Also, the values of the variables and the thresholds used in the judgment step are merely examples, and other values may be used as needed.
[0107] Figure 27 is a flowchart detailing the game processing according to this embodiment. Note that the processing loop in steps S2 to S5 of Figure 27 is executed repeatedly every frame.
[0108] [Preparation Process] First, in step S1, the processor 81 performs game preparation processing to prepare for starting the game. In this process, a virtual 3D space including the game field is constructed, and various objects such as terrain objects, PC201, and other NPCs are placed. Then, the virtual space with the various objects placed is captured by a virtual camera to generate a game image, and this image is output to a stationary monitor or the like. Initialization of various data used in the following processes is also performed. Here, the PC state 323 is set to "grounded" as its initial value.
[0109] [PC movement control processing] Next, in step S2, the processor 81 executes PC movement control processing. This processing is performed to reflect the user's operations in the movement of PC201. Figure 28 is a flowchart detailing the PC movement control processing. In Figure 28, first, in step S11, the processor 81 determines whether the PC state 323 is "jumping". If the result of this determination is not "jumping" (NO in step S11), then in step S12, the processor 81 determines whether the PC state 323 is "rebounding". If the result of this determination is not "rebounding", then in step S13, the processor 81 obtains operation data 306.
[0110] Next, in step S14, the processor 81 determines whether the jump condition has been met. The jump condition is the condition for PC201, which is in the "grounded" state, to transition to the "jumping" state. Specifically, this occurs when a predetermined jump operation (for example, pressing button A 53) is performed while PC state 323 is in the "grounded" state. In addition, even if no explicit jump operation is performed, the jump condition may be determined to have been met if, for example, PC201 steps onto a jump pad installed in the virtual space.
[0111] If the jump condition is met as a result of the above determination (YES in step S14), then in step S15, the processor 81 sets the movement parameters 324 of the PC 201 related to the jump. That is, the direction of the jump, the speed of movement, and the height of the jump are calculated based on the operation data 306, etc., and set in the movement parameters 324.
[0112] Next, in step S16, the processor 81 sets the above reference position. Specifically, based on the contents of the current position data 321 of PC201, the processor 81 sets the position where PC201's feet are in contact with the ground (the jump position) as the reference position information 303.
[0113] In the case of a "water surface jump" as described above, the position of PC201's feet should be set as the reference position information 303. Also, in this embodiment, the current position of PC201 in the frame in which the jump condition is met is used as the reference position, but in other embodiments, the position of PC201 in the previous frame may be used as the reference position.
[0114] Next, in step S17, the processor 81 sets the PC state 323 to "Jumping". After that, the processor 81 terminates the PC movement control process.
[0115] Next, we will explain the process when the PC state 323 is "jumping" as a result of the determination in step S11 (YES in step S11). In this case, in step S19, the processor 81 executes the jumping process. Figure 29 is a flowchart detailing the jumping process. In Figure 29, first, in step S31, the processor 81 moves the PC 201 based on the movement parameter 324 (i.e., it moves while jumping). In addition, the position data 321 may also be updated accordingly.
[0116] Next, in step S32, the processor 81 determines whether the collision of PC201 has come into contact with a terrain object. For example, if PC201 makes a vertical jump near a vertical wall, it may be determined that PC201 is in contact with the wall (terrain object) during the jump. If the result of this determination is that PC201 is not in contact with a terrain object (NO in step S32), the processor 81 terminates the jump processing.
[0117] On the other hand, if PC201 comes into contact with a terrain object (YES in step S32), in step S33, the processor 81 sets the contact location in the contact location information 304.
[0118] Next, in step S34, the processor 81 determines whether the contacted terrain object is a slope or not. Any method can be used to determine whether the contact point is a slope or not, but for example, the following methods can be used. First, there is a method in which an "attribute" is given as one of the data that makes up the terrain object. This "attribute" is information that indicates what kind of terrain it is, such as "flat land," "slope," or "water surface." Then, when the above contact occurs, there is a method in which the processor determines whether or not it has come into contact with a slope by referring to the attribute of the terrain object. Another method is to cast a ray (straight line) in the downward direction while the PC201 is jumping, and determine whether or not it is a slope or not by the degree to which the length of the ray changes during the jump period. If this change is gradual, it can be determined to be a slope, if the change is abrupt, it can be determined to be a step, and so on.
[0119] If the above determination is made and contact is made with the slope (YES in step 34), then a process is performed to terminate the movement related to the jump (to land on the slope). That is, in step S37, the processor 81 sets the PC state 323 to "On the ground".
[0120] On the other hand, if the PC is not in contact with the slope (NO in step S34), then in step S35, the processor 81 calculates the height difference between the reference position and the contact position in the vertical direction as the height for determination. The processor 81 then determines whether the height for determination is equal to or greater than the height threshold. If the result of this determination is that the height is less than the height threshold (NO in step S35), then in step S36, the processor 81 determines whether the movement related to the jump has ended. For example, the processor 81 determines whether the PC201 has landed on the ground. If the result of this determination is that the movement related to the jump has ended (YES in step S36), then in step S37, the processor 81 sets the PC state 323 to "In Ground".
[0121] On the other hand, if movement related to the jump is still in progress (NO in step S36), in step S38, the processor 81 sets the movement parameters 324 of PC201 based on the collision relationship between the terrain object and PC201. For example, in the case of a vertical jump near a wall as described above, the movement parameters 324 will be set to move PC201 upward along the wall. After that, the processor 81 terminates the jump processing.
[0122] On the other hand, if the determination in step 35 determines that the height for determination is greater than or equal to the height threshold (YES in step S35), the settings for performing the rebound movement described above are made. Specifically, first, in step S39, the processor 81 sets the parameters related to the rebound movement of the PC201. Specifically, first, the processor 81 determines whether the surface at the contact position (hereinafter referred to as the contact surface) is a surface that is close to horizontal. For example, the processor 81 determines whether the vertical component of the normal vector of the contact surface is greater than a predetermined threshold (hereinafter referred to as the upper component threshold). For example, if the length of the normal vector is 1, the upper component threshold may be 0.8. If the vertical component is greater than the upper component threshold, the contact surface is considered to be a surface that is close to horizontal. If, as a result of this determination, the vertical component is not greater than the upper component threshold, the processor 81 sets the vector obtained by removing the upward component from the normal vector of the contact surface as the rebound direction. Furthermore, the processor 81 sets the predetermined initial velocity and acceleration (for a certain period of time) as parameters for the movement speed. For example, parameters such as an initial velocity of 80 cm / s and an acceleration of 300 cm / s² (both scales within the virtual space) may be defined in advance. On the other hand, if the vertical component is greater than the upper component threshold, the rebound direction is set without using the normal vector of the contact surface. That is, the processor 81 calculates the direction from the contact position toward the reference position and sets the rebound direction based on that direction. In this case, the same initial velocity and acceleration settings as above are used for the movement speed. In other words, the method of determining the rebound direction changes depending on whether the contact surface is a nearly horizontal surface or not. This is because, when the contact surface is a nearly horizontal surface, the horizontal vector obtained by subtracting the upward component from the normal vector of the contact surface becomes shorter, and even slight irregularities on the contact surface can greatly change the direction of that horizontal vector.
[0123] Next, in step S40, the processor 81 sets the PC state 323 to "rebounding movement". After that, the processor 81 terminates the jumping process.
[0124] Returning to Figure 28, next we will explain the processing when the PC state 323 is "rebounding movement" as a result of the determination in step S12 (YES in step S12). In this case, in step S20, the processor 81 executes the rebound movement process. Figure 30 is a flowchart detailing the rebound movement process. In Figure 30, first, in step S51, the processor 81 moves the PC201 based on the movement parameter 324. That is, movement control related to rebound movement is performed.
[0125] Next, in step S52, the processor 81 determines whether the rebound movement has finished, that is, whether the series of movements from the start of the jump to the rebound movement has finished. For example, it determines whether PC201 has landed on the ground. If the result of this determination is that the rebound movement has finished (YES in step S52), in step S53, the processor 81 sets the PC state 323 to "grounded" and terminates the rebound movement process. On the other hand, if it has not finished yet (NO in step S52), the process in step S53 is skipped. In other words, the movement control related to the rebound movement continues.
[0126] Returning to Figure 28, once the rebound movement process is complete, the processor 81 terminates the PC movement control process.
[0127] Returning to Figure 27, in step S3, the processor 81 executes various game processes other than the movement control of PC201. For example, it executes operations such as controlling the movement of PC201 based on user instructions other than movement operations, controlling the movement of NPCs, and processing based on contact detection between PC201 and NPCs as appropriate.
[0128] Next, in step S4, the processor 81 generates a game image by capturing the virtual space reflecting the above processing with a virtual camera, and outputs it to a stationary monitor or the like.
[0129] Next, in step S5, the processor 81 determines whether the termination condition for the game process has been met. If the condition is not met (NO in step S5), the process returns to step S2 and is repeated. If the condition is met (YES in step S5), the game process is terminated.
[0130] This concludes the detailed explanation of the game processing according to this embodiment.
[0131] Thus, in this embodiment, based on the relationship between the above-mentioned determination height and the above-mentioned height threshold, control is performed for forced movement that prevents the character from crossing the step, known as rebound movement. This makes it possible to limit the movement range of PC201 to the range intended by the developer without causing any visual inconsistencies by placing terrain objects with steps. Furthermore, since the jump height itself is not adjusted when performing this control, the user's feel of jumping is not impaired. In addition, by exhibiting an unnatural movement that differs from the movement expected when jumping, such as rebound movement, it becomes easier for the user to recognize that the step is one that cannot be crossed by jumping.
[0132] [Differentiation] Regarding the trajectory of the rebound movement described above, it is not limited to moving in the direction toward the reference position as described above. For example, it may be forced to move downward along the terrain object, as shown in Figures 31 and 32. In this case, instead of rebounding in the direction toward the reference position as described above, it may be moved straight down as if it were sticking tightly to the wall, as in the example in Figure 32. Alternatively, it may be shifted slightly toward the reference position along the shape of the step before moving downward.
[0133] Furthermore, in this embodiment, when determining the direction of rebound movement, an example was given in which the direction of rebound movement is obtained by removing the upward component from the normal vector of the surface at the contact position. In other embodiments, the direction of rebound movement may be determined without removing the upward component from the normal vector. In this case, the movement will be such that it rebounds perpendicular to the surface at the contact position. In addition, for example, if the upward component of the normal vector of the surface at the contact position is a positive value (upward vector), it may be set to 0 to determine the direction of rebound movement, and if it is a negative value (downward vector), it may be used as is to determine the direction of rebound movement.
[0134] Furthermore, the above embodiment described a case in which a series of processes related to game processing are executed by a single main unit 2. In other embodiments, the above 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-side device and a server-side device that can communicate with the terminal-side device via a network, some of the processes in the above series may be executed by the server-side device. Moreover, in an information processing system including a terminal-side device and a server-side device that can communicate with the terminal-side device via a network, the main processes in the above series may be executed by the server-side device, and some of the processes may be executed by the terminal-side device. In addition, in the above information processing system, the server-side system may be composed of multiple information processing devices, and the processes to be executed on the server side may be divided and executed by multiple information processing devices. Furthermore, a so-called cloud gaming configuration may also be used. For example, the main unit 2 may send operation data indicating user operations to a predetermined server, where various game processes are executed, and the execution results are streamed to the main unit 2 as video and audio. [Explanation of Symbols]
[0135] 1. Game System 2. Main unit 3 Left controller 4 Right controller 81 processors 84 Flash Memory 85 DRAM
Claims
1. In the computer of the information processing device, The player character moves within the virtual space according to the user's input. If the player character, which was positioned at a first position in the height direction within the virtual space, comes into contact with a terrain object at a second position higher than the first position, regardless of user input, the player character is forced to move in a direction away from the position of contact, and in a direction different from the upward direction in the height direction. If the player character, which was positioned at a third position higher than the first position, comes into contact with the terrain object at the second position, the forced movement is not performed. Information processing program.
2. The information processing program according to claim 1, wherein the second position is a position having a surface on which the player character can land.
3. The information processing program according to claim 1, wherein if the player character positioned at the first position comes into contact with a terrain object at the second position, the program moves the player character in a direction including the downward direction in the height direction, only if it is determined that the terrain object at the second position is not a slope.
4. The information processing program according to claim 1, wherein if the player character, which was positioned at the first position, comes into contact with a terrain object at the second position, the player character is moved based on the collision of the terrain object and the collision of the player character.
5. The mesh of the terrain object and the collision of the terrain object coincide. The information processing program according to claim 1.
6. An information processing device equipped with a computer, The aforementioned computer, The player character moves within the virtual space according to the user's input. If the player character, which was positioned at a first position in the height direction within the virtual space, comes into contact with a terrain object at a second position higher than the first position, regardless of user input, the player character is forced to move in a direction away from the position of contact, and in a direction different from the upward direction in the height direction. If the player character, which was positioned at a third position higher than the first position, comes into contact with the terrain object at the second position, the forced movement is not performed. Information processing device.
7. An information processing system equipped with a computer, The aforementioned computer, The player character moves within the virtual space according to the user's input. If the player character, which was positioned at a first position in the height direction within the virtual space, comes into contact with a terrain object at a second position higher than the first position, regardless of user input, the player character is forced to move in a direction away from the position of contact, and in a direction different from the upward direction in the height direction. If the player character, which was positioned at a third position higher than the first position, comes into contact with the terrain object at the second position, the forced movement is not performed. Information processing system.
8. In the computer of the information processing device, The player character moves within the virtual space according to the user's input. If the player character, which was positioned at a first position in the height direction within the virtual space, comes into contact with a terrain object at a second position higher than the first position, regardless of user input, the player character is forced to move in a direction away from the position of contact, and in a direction different from the upward direction in the height direction. If the player character, which was positioned at a third position higher than the first position, comes into contact with the terrain object at the second position, the forced movement is not performed. Information processing methods.