JP7238201B2 - input device - Google Patents

Description

The present invention relates to an input device for executing driving simulation.

A game device that executes a train driving simulation is provided with an input device called a master controller (hereinafter referred to as a master controller) mounted on an actual train (see, for example, Patent Document 1). A master control and a brake lever of the game device described in Patent Document 1 are provided, and acceleration control can be performed by operating the master control, and braking control can be performed by operating the brake lever. In the master controller, it is possible to switch between 1 to 4 stages between "off" and "5", and as the number increases, it is possible to instruct the acceleration to increase sequentially within the range where the maximum speed is not reached. Also, in the brake lever, for example, it rotates in the horizontal direction within a predetermined range, starting from the Yurume position 1 position, in order, 8 regular brake positions, 1 emergency brake position, 1 full braking position, and a total of 11 positions. It is designed to be switched.

JP-A-10-244074

In the game device described in Patent Document 1, the operation of the master controller and the brake lever are combined to control the acceleration and deceleration (braking) of driving. (braking) can be controlled. In order to operate acceleration and deceleration with one master controller, it is necessary to widen the movable range of the lever so that the position can be switched in a greater number of stages. In this case, when the lever is moved to the maximum, the distance between the lever and the surface of the table on which the lever is mounted becomes narrow, and there is a possibility that a part of the player's body or luggage may be caught.

SUMMARY OF THE INVENTION The present invention has been made in consideration of the above circumstances, and its object is to provide an input device which does not cause pinching by the lever even when the movable range of the lever is widened.

In order to solve the above problems, the input device of the present invention includes a lever that rotates in the front-rear direction about a single shaft; a lever housing member integrally formed with the lever so as to cover a portion of the lever on the shaft side by a surface parallel to the lever rotation direction; a member provided on parallel surfaces for defining a movable range of the lever and for defining a plurality of rotational positions of the lever within the movable range; and a portion of the lever not covered by the lever accommodating member. and a base provided with a rectangular opening that exposes a part of the lever housing member, and a part of the lever housing member is exposed from the opening to the surface of the base, and the In a state where the lever is rotated to any position in the movable range of the lever defined by the member within a range in which the lever and the base do not come into contact with each other, there is a gap between the lever and the surface of the base. , the lever accommodating member exposed to the surface of the base is formed to cover the lever.

According to the present invention, it is possible to provide an input device that does not cause pinching by a lever.

1 is a block diagram showing the configuration of a game system according to this embodiment; FIG. The block diagram which shows the functional structure of the game server in this embodiment. FIG. 4 is a diagram showing an example of player data stored in a storage unit according to the embodiment; 1 is a diagram showing an external configuration of a game device according to this embodiment; FIG. 1 is a diagram showing an external configuration of a game device according to this embodiment; FIG. 1 is a diagram showing an external configuration of a game device according to this embodiment; FIG. FIG. 2 is a perspective view showing the configuration of a mascon according to the present embodiment; FIG. 2 is a perspective view showing the configuration of a mascon according to the present embodiment; FIG. 2 is a side view showing the configuration of the master controller according to the embodiment; FIG. 4 is a diagram showing the relationship between the sensor of the master controller and the plate member according to the present embodiment; FIG. 4 is a diagram for explaining the movement of the spring of the master controller according to the embodiment; FIG. 4 is a diagram for explaining a configuration for generating the notch feeling of the master control according to the present embodiment; FIG. 4 is a diagram for explaining a configuration for generating the notch feeling of the master control according to the present embodiment; FIG. 4 is a diagram for explaining a configuration for generating the notch feeling of the master control according to the present embodiment; FIG. 4 is a diagram for explaining a configuration for generating the notch feeling of the master control according to the present embodiment; FIG. 4 is a diagram for explaining a mechanism for detecting a rotational position of an operation lever of the master controller according to the embodiment; FIG. 4 is a diagram for explaining a mechanism for detecting a rotational position of an operation lever of the master controller according to the embodiment; FIG. 4 is a diagram for explaining a mechanism for detecting a rotational position of an operation lever of the master controller according to the embodiment; The figure which shows the combination of detection existence by the sensor of the 2nd board member and the 1st board member in this embodiment. The figure which shows the combination of detection presence/absence of the board member by the sensor in this embodiment. The figure which shows the combination of detection presence/absence of the board member by the sensor in this embodiment. The figure which shows the combination of detection presence/absence of the board member by the sensor in this embodiment. The figure which shows the combination of detection presence/absence of the board member by the sensor in this embodiment. The figure which shows the combination of detection presence/absence of the board member by the sensor in this embodiment. FIG. 2 is a block diagram showing the functional configuration of the game device according to the embodiment; 4 is a flowchart for explaining the overall operation of the game device according to the embodiment; 4 is a flowchart for explaining the overall operation of the game device according to the embodiment; 4 is a flowchart for explaining effect processing according to the present embodiment; FIG. 4 is a diagram showing an example of an operation screen for executing a game displayed on the touch panel according to the embodiment; The figure which shows an example of the screen for a start-of-work inspection in this embodiment. 4 is a flow chart showing operation processing (driver event mode) for a player playing as a driver in this embodiment. The figure which shows an example of the image (screen image) displayed on a display during the driving simulation in this embodiment. The figure which shows an example of the image (screen image) displayed on a display during the driving simulation in this embodiment. The figure which shows an example of the image (screen image) displayed on a display during the driving simulation in this embodiment. The figure which shows an example of the image (screen image) displayed on a display during the driving simulation in this embodiment. The figure which shows an example of the image (screen image) displayed on a display during the driving simulation in this embodiment. The figure which shows an example of the image (screen image) displayed on a display during the driving simulation in this embodiment. The figure which shows an example of the image (screen image) displayed on a display during the driving simulation in this embodiment. The figure which shows an example of the image (screen image) displayed on a display during the driving simulation in this embodiment. The figure which shows an example of the image (screen image) displayed on a display during the driving simulation in this embodiment. The figure which shows an example of the image (screen image) displayed on a display during the driving simulation in this embodiment. The figure which shows an example of the image (screen image) displayed on a display during the driving simulation in this embodiment. The figure which shows an example of the image (screen image) displayed on a display during the driving simulation in this embodiment. The figure which shows an example of the image (screen image) displayed on a display during the driving simulation in this embodiment. 4 is a flowchart showing operation processing (conductor event mode) for a player who plays as a conductor in this embodiment. The figure which shows an example of the screen image at the time of conductor event occurrence in this embodiment. 4 is a flowchart showing processing (diorama creation processing) by the game server in this embodiment. The figure which shows the initial state of the diorama data in this embodiment. The figure which shows the base stand of the diorama data in this embodiment. The figure which shows an example of the diorama parts in this embodiment. 4 is a flowchart showing diorama parts lottery processing by the game server according to the present embodiment.

BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, embodiments of the present invention will be described with reference to the drawings.
FIG. 1 is a block diagram showing the configuration of the game system according to this embodiment. As shown in FIG. 1, in the game system of this embodiment, a game server 10 is connected to a system of a plurality of stores 14-1, . ing.

For example, at a store 14-1, a plurality of (eight in FIG. 1) game devices 20 are interconnected via a network such as a LAN (Local Area Network). The game device 20 according to the present embodiment can perform solo play by one player, cooperative play by two players, and a competitive game in which players of other game devices 20 compete against each other. Also, the plurality of game devices 20 are connected to the network 12 via the host device 21 . Therefore, the game device 20 can communicate with the game server 10 and can transmit and receive various data. It should be noted that the configuration may be such that the game device 20 can directly communicate with the game server 10 through the network 12 .

Although FIG. 1 shows an example in which eight game devices 20 are provided in the store 14-1, one or more game devices 20 are provided in the stores 14-2, . . . , 14-x. shall be At a store 14-1 where a plurality of game devices 20 are installed, a game can be played in the battle mode between the game devices 20 within the store.

The game devices 20 of the stores 14-1, .

The game executed by the game device 20 in this embodiment is a driving simulation game for simulating a vehicle such as a train. A simulation game for driving a train will be described below. In addition to trains, it is also possible to target vehicles such as automobiles, vehicles such as airplanes and ships. For example, when the route on which the train is to run is selected, the game device 20 in the present embodiment causes the display to display an image representing the scenery in front of the driver's seat when the train runs on the selected route. The player is made to perform operations to run the train according to the train operation schedule and operations to deal with various events, evaluate the operation details, and perform performance processing such as screen display and voice output according to the evaluation results. Execute and score.

The game device 20 in this embodiment is provided with an operation device called a master controller, which imitates an input device mounted on a real train, for example, as an input device for receiving input operations of the player.

The game server 10 manages various data related to games executed by the game devices 20 in the stores 14-1, . . . , 14-x. Details of the data managed by the game server 10 will be described later (FIG. 3).

The mobile terminal 16 is realized by, for example, another electronic device provided with a touch screen as an input device operated by a player, such as a personal computer, a smart phone, a slate PC, a mobile phone, a portable game machine, and the like. The mobile terminal 16 can communicate with the game server 10 via the network 12 to receive game data and execute the game. In addition, the mobile terminal 16 can be used to pre-register in the game server 10 data used when the player plays a game on the game device 20 . For example, the portable terminal 16 can be used for a driving simulation game executed by the game device 20 to display diorama data for displaying an image representing a train running course (track) and scenery in front of the driver's seat. can be created by and registered in the game server 10 . By accessing the game server 10 by executing a dedicated application program for registering data in the game server 10, the portable terminal 16 can register arbitrarily created diorama data in advance. Details of the diorama data will be described later. The data to be registered in the game server 10 from the portable terminal 16 is not limited to diorama data, but also data related to objects (such as buildings in the landscape, trains), game results executed on the portable terminal 16 (game achievements, etc.). (data indicating the conditions for

FIG. 2 is a block diagram showing the functional configuration of the game server 10. As shown in FIG. As shown in FIG. 2 , the game server 10 has a control section 30 , a storage section 31 and a communication interface 32 .

Based on the programs and data stored in the storage unit 31, the control unit 30 controls the entire game server 10, manages data stored in the storage unit 31, and communicates with the game device 20 and the mobile terminal 16. 32, and executes various processes such as data transmission/reception. The control unit 30 implements various functions by executing a game data management program 31a stored in the storage unit 31 using a processor (CPU (Central Processing Unit) or DSP (Digital Signal Processor)).

Functions realized by the control unit 30 include, for example, a player data processing unit 30a, a game data processing unit 30b, and a diorama data processing unit 30c.

The player data processing unit 30a processes various data related to the game played by the player for each card ID (identification data) of a card for identifying the player presented to the game device 20 by the player. The player data processing unit 30a processes various data (player management data) set for each card ID, and executes various processes such as recording and updating game results received from the host device 21 (game device 20). The player data processing unit 30a can add and edit player management data according to instructions from the mobile terminal 16 connected via the communication interface 32. FIG.

The game data processing unit 30b processes game data for executing a game on the mobile terminal 16 or the game device 20, distributes game data to the game device 20 or the mobile terminal 16, and distributes the game data to the host device 21 (game device 20). Perform additional recording of game results uploaded from . The game data includes, for example, images (video), sounds, and data related to various events that occur during the game.

The diorama data processing unit 30c executes processing related to creation of diorama data in the portable terminal 16 (diorama creation processing, diorama parts lottery processing). The diorama data processing unit 30c receives an instruction from the mobile terminal 16, adds diorama data, and To edit.

The storage unit 31 stores programs and data for controlling the game server 10 . The programs stored in the storage unit 31 include a basic program (OS (Operating System)) and a game data management program 31a for managing various data for executing a game on the game device 20 .

The game data management program 31a includes a player data processing program 31a1 for realizing the player data processing section 30a, a game data processing program 31a2 for realizing the game data processing section 30b, and a game data processing program 31a2 for realizing the diorama data processing section 30c. A diorama data processing program 31a3 is included.

The data recorded in the storage unit 31 includes player data 31b, game data 31c, and the like.

FIG. 3 is a diagram showing an example of player data 31b stored in the storage unit 31. As shown in FIG. As shown in FIG. 3, the player data 31b includes data 41-4m for each card ID corresponding to each of the players 1-m. FIG. 3 shows player management data 41a, diorama data 41b, and event record data 41c as data 41 corresponding to player 1, for example.

The player management data 41a is data stored when a player executes a game by designating a card ID, and includes various data related to the game set for each card ID. For example, the player management data 41a includes card ID (identification information), store ID, play area, player name, custom image, player experience value, class, level, title, acquired item, acquired train (my train), player performance, Data such as ticket types and lottery points are included.

The card ID is for identifying the player, and is read from the game card (storage medium) owned by the player by the game device 20 and notified to the game server 10 . The shop ID is for identifying the shop where the game device 20 is installed, and is notified from the game device 20 together with the card ID, for example. The play area indicates, for example, an area including the store indicated by the store ID, and is represented by prefectures, for example. The player name is used to identify the player, and is represented by, for example, a character string arbitrarily specified by the player when the game card (card ID) is newly registered. A custom image is an image (avatar, character) created by the player that represents the player, or a train image used in a driving simulation game. configured in combination. Each part that makes up the custom image can be acquired (purchased) by the player by consuming points, acquired as prizes in event play different from normal games, or acquired after playing a specific number of times. can.

The player experience value, class, level, title, acquired item, and player performance data are, for example, data updated based on the results of the game executed on the game device 20 .

The player experience value is a parameter added by the player playing the game. The player experience value is added according to the number of times the game has been played, and is also added according to the opponent and the result of the battle in the battle mode. For example, if a player achieves a game objective such as strictly observing the operation time or stop position, or if he or she wins against another player whose class or level is higher than the player's class or level, more experience points are added.

The level is a parameter obtained by increasing the player's experience value to a predetermined level. The class classifies the player's level, and is classified into, for example, a beginner class, an intermediate class, an advanced class, and a master class. Classes are defined so as to be promoted when a condition determined for each player's level, for example, a driving simulation game of a predetermined difficulty level (mode), is evaluated a predetermined number of times or higher.

Classes are referred to for player-specific control, such as restricting routes that can be selected by the player and scenarios (difficulty, etc.). A title is obtained when a game result satisfying a specific condition is obtained, and is represented by a specific character string (for example, 15 characters). A title is used to identify a player together with a player name, and a plurality of levels (for example, 10 levels) are defined. The higher the level of the title, the more rare and valuable it is, making it more difficult to acquire. Game results that meet specific conditions for obtaining titles include the number of times driving simulations for routes with a certain difficulty level have been cleared, and winning top rankings, etc. Title levels are defined according to each condition. ing.

Acquired items indicate items acquired by the player. Items can be obtained, for example, after the game is over, when the game is leveled up, when an event is achieved, or the like. Items can be collected, for example, as a collection or used during game execution. By using it during game execution, for example, it is possible to change the game content so that it is advantageous to the player, or to execute the game in a play style different from normal play (for example, a different vehicle can be selected). . In addition, by setting items so that they can be used during the game before the game starts, input operations required of the player can be changed to simple operations, input operations can be judged in favor of the player, and hints can be provided. presenting, etc.

The player's results are various data related to each game played by the player, such as the date and time of game execution, the routes and difficulty levels selected as game targets, and the history of points and evaluations obtained as game results. Acquired trains (my trains) are given when a game result on the game device 20 or the portable terminal 16 satisfies a predetermined condition, and indicate trains that the player can arbitrarily use in the operation simulation game. The ticket type indicates the format in which the game fee is paid in advance using electronic money. A limited number of tickets) or a ticket that can be used for a specific period (for example, one month) (commuter pass). For a ticket that can be used for a specific period, it is assumed that predetermined usage conditions are set, such as an upper limit on the number of times the ticket can be used in one day. The lottery points are used for the diorama parts lottery process, and indicate points earned by playing games or the like on the portable terminal 16 . When the lottery points reach a predetermined point, a lottery is executed to provide the player with data (parts such as objects, etc.) that can be used in diorama data, for example.

The diorama data 41b is data representing a diorama created by the player's operation on the portable terminal 16. FIG. The diorama includes the route (course) on which the train runs in the driving simulation, and diorama parts representing the background such as buildings and topography around the route. The diorama data 41b can be created for each of a plurality of routes, and can be selected when using the game on the game device 20. FIG.

The event record data 41c is video and audio data of the player that is recorded, for example, when an event occurs while the player is playing the game on the game device 20 . When the game device 20 executes the driving simulation game, the player can participate in the game as a driver or a conductor. Therefore, the event recording data 41c includes data of driver events recorded when the driver and conductor events recorded when the conductor. The data (video, audio) recorded in the event recording data 41c can be uploaded to SNS (Social Networking Service) through the network 12, for example.

The player management data 41a is used when displaying player information on the game device 20 (for example, a player matching screen, a game start/result display screen, and a ranking display screen when executing the battle mode).

The player data processing unit 30a also stores, as player data 31b, data 42 to 4m similar to those of the player 1 shown in FIG. .

The communication interface 32 controls data communication with the mobile terminal 16 and the game device 20 (host device 21) via the network 12. FIG.

4, 5, and 6 are diagrams showing the external configuration of the game device 20 in this embodiment. 4 is an external perspective view of the housing 50 of the game device 20, FIG. 5 is an external view showing the external appearance of the operating unit housed in the housing 50 of the game device 20, and FIG. 6 is the operating unit of the game device 20. 4A and 4B are perspective views showing the appearance of a driver's cab 60 provided in .

As shown in FIG. 4, the housing 50 of the game device 20 in this embodiment has a substantially box-like shape, with side plates 52A and 52B forming part of the front, a side plate 51R forming the right side, and a side plate 51L forming the left side. covering. No side plate is provided on the front side of the housing 50 , for example, on the right side, and an entrance 53 is formed for the player to enter and exit the housing 50 . Although the doorway 53 is shown in an open state in FIG. 4, an opening/closing member (gate) may be provided so that it can be opened when a player passes through. The side plates 52A, 52B, 51R, 51L are provided with windows 52Aa, 52Ba, 51Ra made of a transparent member such as glass or an acrylic plate, respectively. As a result, even from the outside of the housing 50, the state of the player operating the cab 60 inside the housing 50, the image displayed on the display, and the like can be visually recognized.

A card reader 54 is provided near the doorway 53, for example, on the side plate 52B. The card reader 54 is provided, for example, at a position about the height of the player's waist so that the player can easily read the player identification card with the card reader 54 . The card reader 54 reads data from a game card (storage medium) that stores card-specific data (card ID) by non-contact proximity wireless communication. The player can read the card ID recorded on the game card by bringing the game card close to (holding) the game card against the card reader 54 before entering the housing 50, for example. An LED panel 55 is provided on the front upper portion of the housing 50 . The LED panel 55 displays, for example, a game title, a game execution state, and the like.

It should be noted that the housing 50 can be configured to be separable into a front side and a rear side. As a result, the transportation and installation work of the game device 20 can be facilitated.

As shown in FIG. 5, a cab 60 is installed in the center of the front inside the housing 50, a display 62 is provided in the upper center of the cab 60, a display 63R is provided on the right side of the display 62, and a display is provided on the left side. 63L is installed. The game device 20 can display the scenery in front of the driver's seat during the driving simulation game on the three displays 62, 63R, and 63L, and can also individually display images with different contents depending on the game situation. It is possible.

Inside the housing 50, for example, a plurality of lights (lights 56a1, 56a2, . A plurality of lights are used for normal illumination, and also used for lighting/blinking effects before the start of a game, for example. Further, inside the housing 50, there are a camera (camera 65 shown in FIG. 25) for photographing the state of the player by, for example, video with sound, and a motion sensor (motion sensor 66 shown in FIG. 25) for detecting the movement of the player. etc. are provided.

As shown in FIG. 6, a master controller 72, a brake lever 73, a coin slot 74, and an electronic money unit 75 are provided on the operating surface of the cab 60. As shown in FIG.

The master controller 72 is operated by the player when the driving simulation game is executed, and is configured to imitate a master controller mounted on an actual train. A single master controller 72 can control the acceleration and deceleration (braking) of the train. A detailed configuration of the master computer 72 will be described later. The brake lever 73 is provided in imitation of an actual train.

The coin slot 74 is for the player to insert coins as a game fee. The electronic money unit 75 is used to pay the game fee with electronic money (card). The electronic money unit 75 is used not only for the payment of one game fee, but also for the payment of tickets (excursion ticket, number-limited ticket, commuter pass, etc.) for which the game fee is paid in advance.

A touch panel 77 is provided at the center of the upper front portion of the cab 60 . The touch panel 77 displays various information representing the state of the train, such as pressure gauges, speedometers, other signal states, warning lights, interior air conditioning, destinations, on-board guidance, images representing buttons and switches, etc., during execution of the driving simulation. do. The touch panel 77 can detect touch operations by the player. Different images can be displayed on the touch panel 77 for each train, for example, according to the train running on the game route selected by the player.

Speakers 78R and 78L are provided on the left and right sides of the upper front portion of the cab 60, respectively. A seat 57 for the player to sit on is provided on the front side of the cab 60 (on the inside of the side plate 52B of the housing 50). For example, two speakers (speakers 78BL and 78BR shown in FIG. 25) are provided on the left and right positions near the player's head when the player sits on the seat 57 inside the housing 50 of the side plate 52B. The game device 20 can output sound effects similar to those when the train is actually running from speakers provided in front of and behind the player. A pedal 79 operated by the player's foot is provided at the bottom of the cab 60 .

Next, the details of the master controller 72 will be described.
7 and 8 are perspective views showing the configuration of the master controller 72, and FIG. 9 is a side view of the master controller 72, respectively. 7 and 8 are perspective views seen from different directions.

The master controller 72 is formed with an operating lever operated by the player. The control lever includes, for example, a grip portion 72a that the player grips for operation, and a shaft 72b that supports the grip portion 72a. The control lever rotates on one shaft 72f, and can be moved in the front-rear direction by the player's operation. The operating lever (shaft 72b) is housed in a master console base 72z (operating surface of the driver's cab) with the side where the grip portion 72a is not provided is covered with a lever housing member 72c. The lever accommodating member 72c is formed integrally with the operating lever, and covers a portion of the operating lever on the shaft 72f side with an arc-shaped outer peripheral surface centered on the shaft 72f and a surface parallel to the rotating direction of the operating lever. is formed as The master controller base 72z has an operation lever not covered by the lever housing member 72c and a portion of the lever housing member 72c (including the portion housing the shaft 72b), which is exposed on the operating surface of the cab. is provided with a rectangular opening 72d. The lever accommodating member 72c has a shape that covers the operating lever (shaft 72b) with an arc-shaped outer peripheral surface and a surface parallel to the rotating direction of the operating lever. The shape of the exposed part becomes the same.

That is, even if the angle between the shaft 72b and the operation surface of the cab (masscon base 72z) is reduced by rotating the operation lever most forward or rearward, there is a gap between the shaft 72b and the operation surface. Since the lever accommodating member 72c is always present, there is no risk of pinching a part of the player's body or luggage by operating the operating lever. Therefore, even if the movable range is widened in order to increase the number of stages in which the operation lever can be moved, safety can be ensured. Further, since the arc-shaped member is slid with respect to the opening 72d, even if the lever accommodating member 72c is rotated in accordance with the operation of the operating lever, the lever accommodating member 72c itself does not move into the opening 72d. No chance of getting caught.

7(B) and 8(B) show the configuration of the master controller 72 from which the master controller base 72z is removed.
As shown in FIGS. 7(B) and 9, two shaft holding members 72e1 and 72e2 for holding a shaft 72f for rotating the operation lever (shaft 72b) are arranged vertically on the lower surface of the master controller base 72z. A lever accommodating member 72c is arranged between the shaft holding members 72e1 and 72e2.

In the master controller 72 of the present embodiment, when the operating lever is rotated forward (first direction) from a reference position (neutral position) within the rotatable range of the operating lever, the operating lever , and urges the operating lever to return to the reference position when it is rotated rearward (second direction) opposite to the first direction from the reference position.

That is, as shown in FIGS. 7B and 7C, on the right side of the operating lever is a torsion spring 72m (torsion spring) wound around a shaft 72f for biasing the operating lever to return to the reference position. ) (hereinafter simply referred to as a spring 72m). The spring 72m has one end (first end) fixed and the other end (second end) (the portion corresponding to the arm of the spring 72m) movable. The shaft 72f pushes the other end of the spring 72m in a direction that decreases the angle of both ends of the spring 72m in conjunction with the rotation of the shaft 72f when the operation lever is rotated backward from the reference position. An actuating member 72u is provided (details shown in FIG. 11).

The master controller 72 also includes a plurality of plate members 72j (third plate member 72j1, first plate member 72j2, A second plate member 72j3) and a plurality of sensors 72k (a third sensor 72k1, a fourth sensor 72k2, a first sensor 72k3, and a second sensor 72k4) for detecting rotation of the position member are provided.

As shown in FIGS. 7(B), 7(C) and 9, on the right side of the operating lever is a third plate that rotates parallel to the rotating direction of the operating lever in order to detect the rotating position of the operating lever. A member 72j1 (sensor blade), a third sensor 72k1 that detects the rotation of the third plate member 72j1, and a third sensor 72k1 arranged in the rotation direction of the operating lever that detects the rotation of the third plate member 72j1. A fourth sensor 72k2 is provided. The third sensor 72k1 and the fourth sensor 72k2 are supported by a support member 72e3 fixed to the shaft holding member 72e1.

A defining member 72g shown in FIG. 7C is a member provided on a surface of the shaft holding member 72e1 facing the lever housing member 72c. The regulating member 72g is a member provided to position the operating lever at a predetermined position and to generate a notch feeling when the operating lever is operated. Details of the regulating member 72g will be described later (FIGS. 12(B) and 14).

The third plate member 72j1 is fixed via the shaft 72f and the support member 72h, and rotates in conjunction with the rotation of the operating lever. The third sensor 72k1 and the fourth sensor 72k2 are, for example, photosensors, and detect the light shielding state/light transmitting state that changes with the movement of the third plate member 72j1. FIG. 10A shows the arrangement of the third sensor 72k1 and the fourth sensor 72k2 and the positional relationship of the third plate member 72j1. The details of the shape of the third plate member 72j1 will be described later (see FIG. 16).

As shown in FIGS. 8(B), 8(C), and 9, on the left side of the operating lever, a sensor for detecting the rotating position of the operating lever is provided. A first plate member 72j2 that rotates in parallel with the rotation direction, a second plate member 72j3 that is arranged with a predetermined spacing from the first plate member 72j2, and a first plate member 72j2 that detects the rotation of the first plate member 72j2. A sensor 72k3 and a second sensor 72k4 for detecting the rotation of the second plate member 72j3 are arranged side by side with the first sensor 72k3 in the direction of the shaft 72f with a predetermined gap therebetween. The first sensor 72k3 and the second sensor 72k4 are supported by a support member 72e4 fixed to the shaft holding member 72e2.

A defining member 72q shown in FIG. 8C is a member provided on a surface of the shaft holding member 72e2 facing the lever housing member 72c. The regulating member 72q is a member provided to position the operating lever at a predetermined specific position and to generate a notch feeling at the specific position. Details of the regulating member 72q will be described later (FIGS. 13B and 15).

The second plate member 72j3 is fixed to the shaft 72f and rotates in conjunction with the rotation of the operating lever. The first plate member 72j2 is spaced apart from the second plate member 72j3 by a support member 72s. The first sensor 72k3 and the second sensor 72k4 are, for example, photosensors, and detect the light-blocking state/light-transmitting state that changes as the corresponding first plate member 72j2 and second plate member 72j3 move. FIG. 10B shows the arrangement of the first sensor 72k3 and the second sensor 72k4 and the positional relationship between the first plate member 72j2 and the second plate member 72j3. The details of the shapes of the first plate member 72j2 and the second plate member 72j3 will be described later (see FIGS. 17 and 18).

The rotational position of the operating lever is determined by whether or not the first sensor 72k3 detects the first plate member 72j2 (light shielding/transmitting), whether or not the second sensor 72k4 detects the second plate member 72j3 (light shielding/transmitting), It is detected by a combination of whether or not the third plate member 72j1 is detected by each of the third sensor 72k1 and the fourth sensor 72k2 (light blocking/transmission). In this embodiment, for example, the position of the operating lever is detected in 15 steps: an emergency stop position, a braking position (8 steps from B1 to B8), a neutral (off position), and an acceleration position (5 steps from P1 to P5). do. Therefore, every time the operation lever is rotated by a predetermined amount, the combination of whether the plate member (sensor blade) is detected by the first sensor 72k3, the second sensor 72k4, the third sensor 72k1, and the fourth sensor 72k2 is different. As described above, the first plate member 72j2, the second plate member 72j3, and the third plate member 72j1 are formed in different shapes, each having a range that is detected by the sensor and a range that is not detected.

Further, if 15 steps are to be detected, four plate members may be fixed to the shaft 72f and four sensors arranged in the corresponding axial direction may be used for detection. When the sensors are arranged in the axial direction, the size of the unit becomes large. In this embodiment, one third plate member 72j1 is detected by two third sensors 72k1 and a fourth sensor 72k2 arranged in the rotation direction of the operation lever, thereby increasing the unit size. 15 stages of position detection are possible.

In this embodiment, 15 stages of position detection are performed, but it is also possible to adopt a configuration in which the number of plate members and sensors is increased in order to detect positions of a greater number of stages. In this case, as described above, it is possible to arrange a plurality of sensors separately in the axial direction and in the rotation direction of the operating lever.

Next, a mechanism for returning the operating lever to the reference position (neutral position) will be described with reference to FIGS. 9 and 11. FIG. FIG. 11 is a diagram for explaining the movement of the spring 72m, excluding the members around the spring 72m. 11A is a side view of the master controller 72, and FIGS. 11B and 11C are perspective views of the master controller 72 viewed from different directions from below.

As shown in FIG. 11, a spring 72m (torsion spring) is wound around the shaft 72f, and one end (first end) is fixed by a fixing member 72w attached to the shaft holding member 72e1. there is Also, the portion corresponding to the arm 72ma of the spring 72m including the other end (second end) is made movable. However, the shaft holding member 72e1 is attached with a fixing member 72v that defines the movable range of the arm 72ma of the spring 72m. The fixing member 72v defines the movable range of the arm 72ma of the spring 72m so that the spring 72m does not bias the operating lever (shaft 72f) when the operating lever is in the neutral to braking operation range.

As shown in FIG. 9, an operating member 72u is attached via a connecting member 72t fixed to the shaft 72f. The operating member 72u is at the position indicated by the dashed line in FIG. 11 when the operating lever is at the emergency stop position and the braking position (eight stages B1 to B8). That is, since it is located away from the spring 72m, the operating lever is not biased by the spring 72m (the position of the arm 72mb shown in FIG. 11). On the other hand, when the operating lever is turned to the acceleration position (five steps P1 to P5) (pulled forward by the player), the actuating member 72u moves as indicated by the arrow in FIG. In conjunction with the rotation of the shaft 72f, the arm 72ma of the spring 72m is pushed in the direction to reduce the angle of both ends of the spring 72m. Therefore, the spring 72m biases the operating lever in the direction of returning it to the neutral position. Further, when the operation lever is returned to the neutral position by the force of the spring 72m, the arm 72ma of the spring 72m contacts the fixing member 72v, so that the force of the spring 72m on the operation lever is released. Therefore, the operating lever stops at the neutral position.

In this manner, when the control lever is configured to operate acceleration and braking (deceleration), it is possible to return the control lever to the neutral state only in the operation range for acceleration.

Next, a configuration for generating a notch feeling at a predetermined rotation position when rotating the operating lever will be described with reference to FIGS.

FIG. 12(A) is a side view of the right side of the lever housing member 72c, and FIG. 12(B) is a side view showing a surface of the shaft holding member 72e1 facing the lever housing member 72c.

As shown in FIG. 12A, the lever housing member 72c is provided with two projecting members 72c1 and 72c2 on the surface facing the shaft holding member 72e1. The protruding members 72c1 and 72c2 are arranged on a radial line from the shaft 72f. The projecting member 72c1 is provided at a position close to the radial shaft 72f, and the projecting member 72c2 is provided near the outer peripheral surface of the lever housing member 72c with a gap from the projecting member 72c1. The protruding members 72c1 and 72c2 have a curved surface on the top of the head, and are configured to change their height (slightly lower) by applying force to the top of the head from the side.

As shown in FIG. 12B, a defining member 72g is provided on the surface of the shaft holding member 72e1 corresponding to the lever housing member 72c. FIG. 14 shows a perspective view of the defining member 72g. The regulating member 72g is provided with a plurality of holes through which the projecting members 72c1 and 72c2 can be attached and detached along paths through which the projecting members 72c1 and 72c2 pass as the operation lever rotates. A regulating member 72g shown in FIG. 12B is provided with 15 holes 72g1 along the path through which the projecting member 72c2 passes, and two holes 72g2 and 72g3 along the path through which the projecting member 72c1 passes. is provided. The fifteen holes 72g1 are for defining fifteen positions of the operating lever. The hole 72g2 is arranged on the same radial line of the shaft 72f as the hole corresponding to the braking position B8 (one before the emergency stop position) among the fifteen holes 72g1. The hole 72g3 is arranged on the same radial line of the axis 72f as the hole corresponding to the neutral (cutting position) among the fifteen holes 72g1. Therefore, when the operating lever is at the braking position B8 (one position before the emergency stop position) and at the neutral (off position), the two projecting members 72c1 and 72c2 are simultaneously fitted into the holes. As a result, the operating lever is held in a stronger position than when it is in another position. As a result, the player can easily recognize that the operating lever is at a specific position, ie, the position immediately before the emergency stop position where the braking force is the largest and the neutral position, based on the operational feel of the operating lever.

As shown in the front view of FIG. 9, the regulating member 72g is provided with a space that allows it to be attached to and detached from the holes 72g1, 72g2, and 72g3 by moving the projecting members 72c1 and 72c2 as the operation lever is rotated. , and the projecting members 72c1 and 72c2. Therefore, by rotating the operation lever, the projecting members 72c1 and 72c2 are repeatedly attached and detached to and from the plurality of holes in order, and a notch feeling can be generated.

In FIGS. 12 and 14, the radial distance between the hole 72g1 and the holes 72g2 and 72g3 is the same. The force required to rotate the operating lever can be changed. In this case, it is necessary to provide projection members corresponding to the holes 72g2 and 72g3 having different radial intervals. This makes it possible to change the notch feel depending on the position of the operating lever. Further, in the regulating member 72g shown in FIG. 14, the holes 72g1 are arranged at regular intervals, but they may be arranged at irregular intervals depending on the position where the operation lever is fixed (held).

FIG. 13A is a side view showing the left side of the lever housing member 72c, and FIG. 12B is a side view showing a surface of the shaft holding member 72e2 facing the lever housing member 72c.

As shown in FIG. 13A, the lever housing member 72c is provided with two projecting members 72c3 and 72c4 on the surface facing the shaft holding member 72e2. The protruding members 72c3 and 72c4 are arranged on a radial line from the shaft 72f. The projecting member 72c3 is provided near the radial shaft 72f, and the projecting member 72c4 is provided near the outer peripheral surface of the lever housing member 72c with a gap from the projecting member 72c3. The protruding members 72c3 and 72c4 have a curved surface on the top of the head, and are configured so that the height is changed (slightly lowered) by applying force to the top of the head from the side.

As shown in FIG. 13B, a defining member 72q is provided on the surface of the shaft holding member 72e2 corresponding to the lever housing member 72c. FIG. 15 shows a perspective view of the defining member 72q. The regulating member 72q is provided with a plurality of (two in FIG. 15) holes 72q3 and 72q4 through which the projecting member 72c3 can be attached and detached along the path through which the projecting member 72c3 passes as the operating lever is rotated. . Further, the regulating member 72q is provided with a guide groove 72q1 and a hole 72q2 along the path through which the projecting member 72c4 passes while holding the projecting member 72c3. A projection member 72c4 is inserted into the hole 72q2 to hold the position of the operating lever when the operating lever is rotated to the emergency stop position. Since the projection member 72c4 is always inserted into the guide groove 72q1 at any rotating position other than the emergency stop position, it stabilizes the rotation of the operating lever and rotates the operating lever to the emergency stop position. The notch feeling can be strongly generated only at times. The two holes 72q3 and 72q4 provided along the path through which the projecting member 72c3 passes are provided at relatively the same positions as the holes 72g2 and 72g3 provided in the defining member 72g. That is, when the projecting member 72c1 is attached to the holes 72g2 and 72g3, the projecting member 72c3 is similarly attached to the holes 72q3 and 72q4. Therefore, when the operating lever is at the braking position B8 (one position before the emergency stop position) and at the neutral (off position), the two projecting members 72c3 are mounted in the holes 72q3 and 72q4. As a result, the operating lever is held in a stronger position than when it is in another position.

In the above description, the maximum number of protruding members to be mounted (inserted) at the same time is two for both the defining member 72g and the defining member 72q. In the case where there are more than one projection member, the intervals between the holes into which the different projection members are inserted may not be constant.

Next, a mechanism for detecting the rotational position of the operating lever will be described. 16 is a plan view of the third plate member 72j1, FIG. 17 is a plan view of the first plate member 72j2, and FIG. 18 is a plan view of the second plate member 72j3.

The first plate member 72j2, the second plate member 72j3, and the third plate member 72j1 are attached to the shaft 72f and are rotated simultaneously in conjunction with the rotation of the operating lever. are detected by corresponding four sensors (third sensor 72k1, fourth sensor 72k2, first sensor 72k3, second sensor 72k4). The first plate member 72j2, the second plate member 72j3, and the third plate member 72j1 are formed in different shapes, each having a range that is detected by the sensor and a range that is not detected. In the drawing, "1" shown in the arc-shaped portion indicates the range not detected by the sensor (light-transmitting state), and "0" indicates the range detected by the sensor (light-shielding state). FIG. 19 shows a combination of presence/absence of detection by the sensors of the second plate member 72j3 and the first plate member 72j2.

20 to 24 show combinations of presence/absence of detection of the plate member (sensor blade) by the third sensor 72k1, fourth sensor 72k2, first sensor 72k3, and second sensor 72k4 according to the rotational position of the operating lever. ing. As shown in FIG. 20(A), in this embodiment, the position of the operating lever is detected by 15 stages, and the operating lever is rotated from the most forwardly rotated state (emergency stop position) to the most hand side. The combination of presence/absence of detection by the four sensors is different until the state (acceleration position P5). Note that A, B, C, and D shown in FIG. 20A indicate states detected by the second sensor 72k4, the first sensor 72k3, the third sensor 72k1, and the fourth sensor 72k2, respectively.

FIGS. 20B and 20C show the operating lever rotated to the emergency stop position. As shown in FIGS. 20B and 20C, none of the sensors detects the plate member (light-transmitting state "1"), so A to D are all "1". FIGS. 21A and 21B show a state in which the operating lever is rotated to the braking position B5. As shown in FIGS. 21A and 21B, when the plate member is rotated to the braking position B5, the plate member is detected by the first sensor 72k3 and the third sensor 72k1 (light shielding state "0"). , A to D are "1001". FIGS. 22A and 22B show a state in which the operating lever is in neutral (off position). As shown in FIGS. 22A and 22B, in the neutral (off position) state, only the first sensor 72k3 does not detect the plate member, so the combination of A to D is "0100". FIGS. 23A and 23B show a state in which the operating lever is rotated to the acceleration position P3. As shown in FIGS. 23A and 23B, when the plate member is rotated to the acceleration position P3, the plate member is detected by the first sensor 72k3 and the fourth sensor 72k2. It becomes "1010". FIGS. 24A and 24B show a state in which the operating lever is rotated to the acceleration position P5. As shown in FIGS. 24A and 24B, when the plate member is rotated to the acceleration position P5, the plate member is detected by the second sensor 72k4 and the fourth sensor 72k2. becomes "0110".

In this manner, the three plate members each having a different shape and the four sensors make it possible to detect the respective rotational positions of the operating levers.

Further, as shown in FIG. 20A, by rotating the position of the operating lever by one step, only the detection state of any one sensor is changed. Therefore, it is possible to stably execute the control according to the switching of the operation lever. That is, for example, when the detection states of the two sensors change due to switching by one step, the detection state ( combination of presence/absence of detection) may occur. In such a case, if the control state is changed according to the detection of the sensor, there is a possibility that an erroneous control (for example, switching from acceleration→deceleration→acceleration, etc.) is temporarily executed. In the present embodiment, since such a situation does not occur, smooth and stable control is possible.

Next, control of the game device 20 in this embodiment will be described.
FIG. 25 is a block diagram showing the functional configuration of the game device 20 according to this embodiment. As shown in FIG. 25, the game device 20 has a control unit 90, a storage unit 92, a display controller 93, a touch panel controller 94, a sound controller 95, a lighting controller 96, an input interface 97, a communication interface 98, and a coin sensor 99. are doing.

The control unit 90 controls the entire game device 20, and executes each unit by executing a basic program (OS (Operating System)) and various application programs (including the game program 92a) stored in the storage unit 92. Control. The control unit 90 is controlled by a processor (CPU or DSP) executing a game program 92a stored in the storage unit 92 according to an input operation (detection state of the sensor 72k) with respect to the operation lever of the master computer 72. Realize various functions for running the game.

Functions realized by the control unit 90 include a start processing unit 90a (demonstration processing unit 90a1, game preparation processing unit 90a2, effect processing unit 90a3), player matching processing unit 90b, game processing unit 90c (game screen display processing unit 90c1 , an operation determination processing unit 90c2, a battle processing unit 90c3, a game sound processing unit 90c4, a message processing unit 90c5), a game result processing unit 90d, a player data processing unit 90e, and an input control unit 90f.

The start processing unit 90a executes start processing until the game is started. The demonstration processing unit 90a1 executes demonstration processing for displaying a game screen for demonstration. The game preparation processing unit 90a2 executes processing such as new registration of game cards, reading of data (card ID) from game cards, game mode selection processing (normal mode, iron man mode, experience driving mode, battle mode), and the like. do. When the card ID is read from the game card, the effect processing section 90a3 executes the pre-game effect processing (FIG. 28) corresponding to the card ID (player).

The player matching processing section 90b executes matching processing for determining an opponent when the player instructs execution of the battle mode. In the game device 20 according to the present embodiment, in addition to a 1 (driver) vs. 1 (driver) fight, a 2 (driver, conductor) vs. 2 (driver, conductor) fight can be executed in the battle mode. do.

The game processing section 90c controls the game in the game mode designated by the player based on the game data 92b. The game processing section 90c includes functions of a game screen display processing section 90c1, an operation determination processing section 90c2, a battle processing section 90c3, and a game sound processing section 90c4.

Based on the game data 92b, the game screen display processing unit 90c1 displays an image representing the scenery in front of the driver's seat on the route for driving simulation, various information related to the game, demonstration images, production images, and the like on the displays 62 and 63L. , 63R, and various information related to the player's input operation are displayed on the touch panel 77 (display 77a).

The operation determination processing section 90c2 includes a determination function of performing input determination based on an input operation to the master computer 72 and the display contents of the screen displayed by the game screen display processing section 90c1. The operation determination processing unit 90c2 determines, for example, in a driving simulation whether the vehicle has traveled according to the timetable, whether the stop position is correct, or operation determination such as re-acceleration in the station premises or emergency braking stop. In addition, the operation determination of the player (driver, conductor) for various events occurring in the driving simulation, etc. is executed. In addition, the operation determination processing unit 90c2 calculates a driving evaluation score based on the result of the operation determination as the final result of the driving simulation.

The battle processing unit 90c3 controls the battle mode, and performs transmission of data indicating the game situation in the own device, reception of data indicating the game situation executed by another player (another game device) as an opponent, and the like. Execute.

The game sound processing section 90c4 controls sound output during game execution. The game sound processing section 90c4 controls sounds output from the speakers 78L, 78R, 78BL, 78BR and the headphone terminal 58b through the sound controller 95. FIG. The game sound processing unit 90c4 also drives an acoustic vibration module (bass shaker) 78BS provided on the seat 57 on which the player sits. For example, the game audio processing unit 90c4 outputs to the acoustic vibration module 78BS an audio signal corresponding to the timing and strength of vibration generation in the driving simulation set in the game data 92b, and causes the acoustic vibration module 78BS to acoustically vibrate to generate a feeling of vibration. to the player.

The message processing unit 90c5 processes various messages sent and received with another game device 20 as an opponent when the game is executed in the battle mode. The messages sent and received between the game devices 20 include the player's voice, text data according to the player's operation on the touch panel 77, and message data (image, text, voice, etc.) predetermined for a specific game situation. )and so on. When the message processing unit 90c5 receives a message from another game device 20, the message processing unit 90c5 outputs the message (display, voice output, etc.) during game execution.

The game result processing unit 90d executes processing on the game result by the game processing unit 90c. The game result processing unit 90d displays the evaluation result as an intermediate result during the driving simulation and as a final result at the end of the game.

The player data processing unit 90e executes processing for various types of data related to the player. 10, such as transmission (registration).

The input control unit 90 f controls input data from the master computer 72 a (sensor 72 k ) and the pedal sensor 79 a provided on the pedal 79 in accordance with the player's operation input through the input interface 97 . The input control unit 90 f also processes video (and audio) data captured by the camera 65 and data detected by the motion sensor 66 , which are input through the input interface 97 .

The storage unit 92 stores programs and data for controlling the game executed on the game device 20 . The programs stored in the storage unit 92 include a game program 92a for executing a game on the game device 20 in addition to the basic program. The game program 92a can realize each function of the control unit 90 by being executed by a processor or the like.

The data stored in the storage unit 92 includes game data 92b, player management data 92c, opponent player management data 92d, event recording data 92f, and diorama data 92g.

The game data 92b includes data related to the driving simulation executed by the game device 20. FIG. The player management data 92 c is data received from the game server 10 based on the card ID read from the game card by the card reader 54 . The player management data 92c corresponds to the player management data 41a stored in the game server 10 in association with the card ID. The opponent player management data 92d includes player management data of the opponent player in the battle mode and data indicating the game situation acquired by the battle processing section 90c3 during the battle. The event record data 92f is video and audio data of a player (driver, conductor) that is captured during the execution of the game, for example, when an event occurs. The diorama data 92 g is data received from the game server 10 based on the card ID read from the game card by the card reader 54 . The diorama data 92g corresponds to the diorama data 41b stored in association with the card ID in the game server 10, and can be selected as a route to be driven in the driving simulation.

Under the control of the control unit 90, the input interface 97 inputs data (detection data of the sensor 72k) corresponding to the operation of the operation lever of the master computer 72a and data from the pedal sensor 79a corresponding to the operation of the pedal 79. Control. Also, the input interface 97 inputs video (and audio) data captured by the camera 65 and data detected by the motion sensor 66 .

The touch panel controller 94 controls the touch panel 77 under the control of the control section 90 . The touch panel 77 includes a display 77a and a touchpad 77b.

The sound controller 95 controls sound output from the speakers 78L, 78R, 78BL, 78BR and the headphone terminal 58b under the control of the control section 90 (game sound processing section 90c4). The sound controller 95 stops sound output from the speakers 78L, 78R, 78BL, and 78BR when a headphone plug is attached to the headphone terminal 58b. Also, the sound controller 95 is connected to the acoustic vibration module 78BS provided in the sensory acoustic vibration unit 50d. The sound controller 95 outputs an audio signal corresponding to the vibration intensity to the acoustic vibration module 78BS in accordance with the timing of generating vibration in association with the image displayed on the display 62, for example. Also, the volume button 58 and the microphone 59 are connected to the sound controller 95 . The volume button 58 is provided, for example, on a control panel for an administrator of the game device 20 housed inside the housing, and is used for adjusting volume balance and the like. The microphone 59 is used for inputting the voice of the player playing as the conductor, for example, when the driving simulation is executed by two people (two-person mode).

Under the control of the control unit 90, the lighting controller 96 controls lighting/blinking of the plurality of lights 56a1, 56a2, . For example, the lighting controller 96 lights or blinks the lights 56a1, 56a2, . Switch the display pattern, etc.

The coin sensor 99 detects a coin inserted from the coin slot 74 and notifies the control section 90 (start processing section 90a).

The communication interface 98 controls communication with other game devices 20 in the store and the host device 21 and communication with the game server 10 via the network 12 .

Next, the operation of the game device 20 according to this embodiment will be described.
26 and 27 are flowcharts for explaining the overall operation of the game device 20 according to this embodiment.

When the power is turned on, the game device 20 activates the game program 92a and starts processing by the start processing section 90a. First, the start processing unit 90a executes demonstration processing by the demonstration processing unit 90a1 (step A1). For example, the demonstration processing unit 90a1 repeatedly displays demonstration screens on the displays 62, 63R, and 63L, and also controls the LED panel 55 and the lights 56a1, 56a2, . . . , 56am. The demonstration processing unit 90a1 provides, for example, a logo display screen displaying the manufacturer's name, a news screen displaying a news screen (an image prepared in advance or an image received from the game server 10), a game title screen, and an explanation of how to play the game. A tutorial screen, a route list screen displaying a list of routes that can be used in a driving simulation game, and the like are repeatedly displayed while being sequentially switched after a predetermined time has elapsed or after the display of all the display contents is completed. Since the housing 50 is provided with a plurality of 52Aa, 52Ba, and 52Ra, the demo screen can be viewed even from outside the housing 50. FIG. As a result, it is possible to encourage the player to use the game by displaying the demo screen. It should be noted that by dimming the illumination inside the housing 50 during the demonstration display, the display contents of the displays 62 , 63 R, and 63 L can be easily viewed from the outside of the housing 50 .

When the coin sensor 99 detects the insertion of a coin or when the electronic money unit 75 detects the receipt of electronic money (step A2, yes), the game preparation processing section 90a2 controls the display 62 (or the touch panel 77), for example. Then, a card authentication screen including a message such as "please touch the card to the reader" is displayed to display a card authentication screen for player identification (step A3). Here, the card may be read by a card reader 54 provided outside the housing 50, or the card reader 54 may be installed on the driver's cab 60 so that the card can be read on the operator's cab 60. You can set it.

After the card authentication screen is displayed, for example, if the card is not read by the card reader 54 even after a certain period of time has passed (step A4, none), the game preparation processing section 90a2 notifies the player of the advantages of using the card. A screen for explanation is displayed (step A5). After that, when the coin sensor 99 detects that a fee required to start using the game has been inserted, or when the electronic money unit 75 detects payment of electronic money (step A6, yes), the game is ready. The processing unit 90a2 instructs the game processing unit 90c to start game processing.

On the other hand, when the card ID is read by the card reader 54 before the insertion of coins by the coin sensor 99 or the receipt of electronic money by the electronic money unit 75 is detected (step A2, none), the game preparation processing section 90a2 Authenticate whether the card can be used. When the card is authenticated as usable (step A7, Yes), the game preparation processing unit 90a2 transmits the card ID to the game server 10 and confirms the player registration corresponding to this card ID.

The game server 10 determines whether player data corresponding to the card ID received from the game device 20 is recorded. If the player data corresponding to the card ID is not recorded, the game server 10 notifies the game device 20 that the player is a new player. Player management data is transmitted to the game device 20 .

When the game server 10 notifies the game preparation processing unit 90a2 that the player is a new player (step A9, none), the game preparation processing unit 90a2, for example, reads, "This card is a card that has not been registered in this game device. A new player registration screen containing the message "Are you sure?" is displayed to prompt the player to register, for example, a player name (step A10). Here, when execution of new registration is instructed, the game preparation processing unit 90a2 displays an operation screen for player registration on the touch panel 77, and performs player registration by the player's operation on the touch panel 77. FIG. The game preparation processing unit 90a2 transmits the data of the card ID read from the new card and the player name input by the player's operation to the game server 10 for recording.

In response to reading of the card ID by the card reader 54, the effect processing unit 90a3 executes effect processing corresponding to the player (player management data corresponding to the card ID) in parallel with the above-described processing (step A12). . Details of the effect processing will be described later.

On the other hand, when the game preparation processing unit 90a2 receives the player management data from the game server 10, that is, when the player is already registered (step A9, Yes), the player information regarding the player included in the player management data is For example, it is displayed on the display 62 (touch panel 77) (step A11). For example, the player information includes player names, custom images, levels and titles, obtained items, and player results included in the player management data.

Note that, in the same manner as described above, the effect processing unit 90a3 performs effect processing corresponding to the player (player management data corresponding to the card ID) in parallel with the processing described above in response to reading of the card ID by the card reader 54. Execute (step A12). Details of the effect processing will be described later.

In addition, in this embodiment, the driving simulation game can be executed by two players. After the card ID is read by the card reader 54 (step A7, Yes) and before credit is established (step A6, No), the game preparation processing unit 90a2 reads the card ID (different from the previous one) by the card reader 54 again. is read (step A8, Yes), the two-person mode is set (step A13). In the two-person mode, the driving simulation can be performed by dividing roles between the driver and the conductor.

When the two-player mode is set, the game preparation processing section 90a2 displays player information corresponding to each card ID. Here, which player is in charge of the driver or the conductor may be set by the player's operation on the touch panel 77 . The player whose card ID is first read by the card reader 54 may be set as the driver, and the player whose card ID is read next may be set as the conductor. may be assigned.

Here, the effect processing in this embodiment will be described with reference to the flowchart shown in FIG.
If there is player registration (step C1, Yes), the effect processing unit 90a3 turns on (blinks) lighting, outputs sound, and displays the screen for effects before the start of the game, based on the player management data corresponding to the registered player. etc. (step C2). If there is no player registration (step C1, No), the effect processing unit 90a3 executes illumination lighting (blinking), sound output, screen display, etc. for pre-game pre-set effects (step C1, No). C3). If the 2-player mode is set (step C4, Yes), the effect processing unit 90a3 turns on (blinks) lighting and sounds for a preset effect before starting the game in the 2-player mode. Output, screen display, etc. are executed (step C5).

The contents of the presentation may be changed according to, for example, the player's experience value, class, level, etc. included in the player management data, or may be changed according to the player's performance. Further, the game server 10 may be configured so that the player can register data indicating the details of the performance as player management data in association with the card ID from the mobile terminal 16 in advance, and the performance corresponding to the registered details can be performed. good.

In addition to changing the effect content based on the player management data, it is also possible to illuminate the driver's seat as if it were illuminated by the setting sun during the game playing time, for example, in the evening. . In addition, it is also possible to represent not only the time zone but also the season or the difference in weather. As for the sound, it is also possible to output sounds (BGM or voice messages) representing the state of the platform depending on the difference between rush hours and nighttime.

Further, when an opening/closing member (gate) is provided at the entrance/exit 53, the effect processing section 90a3 opens/closes the opening/closing member in response to the card ID being read by the card reader 54, thereby allowing the player to enter the housing 50. It is possible to produce a performance that passes through the inside of the.

By causing the card reader 54 provided outside the housing 50 to read the card ID in this way, the effect processing is executed before the game starts, so that the player can feel that the driving simulation is about to start. can be provided to The player can enter the housing 50 through the doorway 53, sit on the seat 57, and wait for the start of the driving simulation game while the effect processing is being executed. Therefore, it is possible to enhance the excitement of playing the game even before the game starts.

When the card ID is read by the card reader 54, the game preparation processing unit 90a2 detects that the coin sensor 99 has inserted the necessary fee to start using the game (step A6, Yes). It determines that the credit condition is satisfied, and instructs the game processing unit 90c to start the game processing.

Also, the start processing unit 90a can start the game when the game fee is paid using electronic money instead of coins. Electronic money can be used not only to pay the game fee for one game, but also to pay the game fee in advance and record the ticket type indicating the payment method in the game server 10 (purchase a ticket). The game preparation processing section 90a2 displays a list of ticket types that can be purchased, for example, on the touch panel 77, and allows the player to select one of the ticket types by a touch operation.

After the ticket type is selected, the game preparation processing section 90a2 sells the ticket when the electronic money is deposited through the electronic money unit 75. FIG. Ticket types include, for example, a ticket that allows unlimited rides on a specific route (excursion ticket), a ticket that can be used for a predetermined number of times (for example, 5 times) (limited number of tickets), or a specific period (for example, one month). There are regular tickets available. A different game charge is set according to the ticket type, and the game charge corresponding to the ticket type is paid from electronic money through the electronic money unit 75 .

In addition, for example, for limited number of tickets, if it falls under a preset period (period corresponding to spring vacation, summer vacation, winter vacation), change the amount to be deposited as game fee, such as making the game fee lower than other periods It is possible to Moreover, even if the ticket type is the same, the amount of money to be deposited is changed according to, for example, the target route for an excursion ticket, and the valid period (3 months, 6 months, etc.) for a regular ticket. When a ticket is purchased using electronic money, the game preparation processing unit 90a2 transmits data indicating the type of ticket sold and the card ID to the game server 10, and stores the ticket type in the player management data corresponding to the card ID. Record the data indicating

When a ticket has been purchased in advance, and when player management data corresponding to the card ID read by the card reader 54 is received from the game server 10, electronic money is used in the player management data to pay the game fee in advance. It contains data indicating the ticket type indicating that

When the ticket type satisfies the credit condition, the game preparation processing unit 90a2 displays the ticket type (excursion ticket, number-limited ticket, commuter pass) on the touch panel 77, for example, for the player to confirm. When the ticket type is confirmed by the player's touch operation on the touch panel 77, the game preparation processing section 90a2 determines that the credit condition is satisfied, and instructs the game processing section 90c to start the game processing. In this way, the game charge required for using the game can be paid in advance. There is no need to have the game read by 75 or to insert coins, making it possible to easily pay the game fee.

When the ticket type is an excursion ticket or a commuter pass, the game preparation processing unit 90a2 determines whether the credit condition is satisfied based on the conditions of use set for each ticket type. For example, with respect to regularity, the number of times the game device 20 can be used in a day is set, and it is determined that the credit condition is satisfied when this number of times of use is reached. The number of times the game device 20 has been used is recorded (updated) in the game server 10 as player management data associated with the card ID. The usage condition can be not only the number of times of use, but also the total playing time (for example, within 2 hours), and the elapsed time since the previous play (for example, 20 hours must be left). Also, in the case of a number-limited ticket, each time the ticket is used, the remaining number of uses is recorded (updated) in the game server 10 as player management data associated with the card ID.

When the two-player mode is set, the game preparation processing unit 90a2 adds data indicating the type of ticket that satisfies the credit conditions in the player management data corresponding to the card ID read by the card reader 54 by each player. If it is recorded, it is determined that the game can be started. When the two-player mode is set, the game preparation processing section 90a2 determines that the player management data corresponding to the card ID read by the card reader 54 by at least one of the players includes data indicating a limited number of times ticket. If there are two remaining times, it is also possible to determine that the credit condition is satisfied.

Further, the game preparation processing unit 90a2 can accept cancellation of the ticket type recorded in the game server 10 by the player's operation on the touch panel 77, for example. For example, if data indicating a ticket (commuter pass) that can be used for a specific period is registered in the game server 10, cancellation is accepted before the expiration of the period. When the cancellation of the ticket type is instructed, the game preparation processing unit 90a2 requests the game server 10 to cancel the ticket type together with the card ID. The game server 10 also deletes the data indicating the ticket type in the player management data corresponding to the card ID in response to a request from the game device 20 (game preparation processing section 90a2).

In addition, the game preparation processing unit 90a2 executes processing for refunding part of the prepaid game fee according to the remaining period until the end of the period, for example. That is, the game preparation processing section 90a2 causes the touch panel 77, for example, to display the refund amount and to display a screen instructing to bring the electronic money card close to the electronic money unit 75. FIG. In addition, the game preparation processing section 90a2 notifies the electronic money unit 75 of the refund amount and causes the refund to be executed. The electronic money unit 75 pays out the amount of money notified from the game preparation processing section 90a2 to the electronic money card when the electronic money card is approached. In addition, for excursion tickets and limited-use tickets, the corresponding refund conditions are set in advance, and if the refund conditions are met, the amount calculated based on the prescribed refund calculation will be paid out. can be

When the credit condition is met (step A6, yes), the game processing unit 90c causes the touch panel 77 to display a mode selection screen for selecting a game mode (step A14). Game modes that can be selected on the mode selection screen include, for example, normal mode, iron man mode, experience driving mode, and battle mode. Normal mode is a general mode in which you can run until the allotted time (described later) reaches zero. The iron man mode has a shorter time than the normal mode, and is a mode in which the player's operation for an event or the like is severely judged. The experience-running mode is a beginner's mode that guarantees a certain section of running even if the player makes an operation error. The battle mode is a mode in which players who play simultaneously on other game devices 20 compete against each other.

When the battle mode is selected on the mode selection screen (step A18), the player matching processing unit 90b executes player matching processing for setting an opponent to play against (step A19). In the player matching process, for example, the game device 20 that is first instructed to execute the in-store competitive play among the plurality of game devices 20 in the store becomes the host player, and the other game devices 20 are recruited as opponents (guests). do. If there is no competition request within a predetermined fixed time, it is determined that the competition game cannot be executed, and the mode selection screen is displayed again. On the other hand, when there is a competition request, the player matching processing unit 90b performs processing for preparation of the competition game, and then shifts to processing for starting the game (from step B1).

On the other hand, when any one of the normal mode, the iron man mode, and the experience driving mode is selected, the game processing unit 90c associates the card ID read from the card reader 54 with the diorama data recorded in the game server 10. In this case, diorama data is received from the game server 10 . Details of diorama data recording will be described later (FIGS. 48 to 52).

The game processing unit 90c causes the touch panel 77 to display a route selection screen including a route list for allowing the player to select a route for driving simulation, and allows the player to select one (step A21). Note that when diorama data has been received from the game server 10, the route based on the diorama data is also displayed as an option on the route selection screen.

When a route is selected, the game processing unit 90c selects a timetable including a list of departure stations on the route, departure direction (inward/outward in the case of a circular route), and a list of timetables (scheduled operations) according to differences in difficulty. A screen is displayed on the touch panel 77, and the player is made to select one (step A22).

Next, the game processing unit 90c starts processing for preparing to execute the driving simulation. The game processing unit 90c causes the touch panel 77 to display an operation screen for game execution as shown in FIG. 29, and causes the display 62 to display a start-of-work inspection screen as shown in FIG. 30 (step B1).

The operation screen for executing the game shown in FIG. 29 displays images representing, for example, a pressure gauge 77a, a speedometer 77b, a train information screen 77c, a signal display section 77d, a door closing light 77e, and a dimming switch 77f. In each area, the display contents are changed in real time according to the situation change of the driving simulation.

30, in order to detect the home (reference) position of the operation lever of the master computer 72, the player is instructed to operate the operation lever to the emergency braking position (emergency stop position) as the home (reference) position. is displayed. The game processing unit 90c receives data indicating that the operating lever has been moved to the emergency brake position (emergency stop position) from the master computer 72, performs a start-of-work inspection, and then starts driving simulation. That is, the game processing unit 90c causes the game screen display processing unit 90c1 to display a route map (current position, travel section) to be traveled, and then displays an image of the route viewed from the driver's seat corresponding to the route to be traveled. Display is started (step B2). After that, the game processing unit 90c executes a simulation of running a train in response to the player's operation of the master controller 72, pedal 79, etc., while performing input corresponding to the operation corresponding to the event (evaluation point) provided during the game. is received and evaluated (step B3).

The driving simulation in this embodiment sets the duration according to the game mode, target route, timetable, difficulty level, player management data (player experience value, class, level, etc.), etc., and events that occur during the game (evaluation If you perform an operation (success) that corresponds appropriately to the point), add the time limit, and subtract the time limit if you perform the wrong operation (failure), until the time limit becomes zero. This is a game to run a train to the destination station.

Evaluation points include, for example, call points, whistle points, dimming points, and constant speed points. At the call-out point, for example, the user touches the corresponding location (region) on the touch panel 77 at the timing at which pointing and calling should be performed to determine success/failure. At the whistle point, a human model is displayed around the railroad tracks on the screen image, and a whistle is output to the human at appropriate timing to determine success/failure. At dimming points, the headlights are normally kept in high beam mode, but when passing a train running on the next track, they are temporarily switched to dimming (low beam) at the appropriate timing to judge success/failure. do. At the constant speed point, the vehicle is made to run at a preset constant speed from a preset position on the route, and success/failure is determined. At each evaluation point, the game processing unit 90c outputs a display (for example, the characters "good" in the case of success) or a voice (sound effect, message, etc.) representing the determination result according to the determination result of success/failure. Let

FIG. 31 is a flow chart showing operation processing (driver event mode) for a player playing as a driver. A specific example of the operation of the player who is the driver will be described below. 32 to 44 are diagrams showing examples of images (screen images) displayed on the displays 62, 63R, 63L during the driving simulation. It should be noted that FIGS. 32 to 44 show screen images for explaining specific situations, and all the displayed contents are not the same as those displayed when the driving simulation is actually executed.

As shown in FIG. 32, the screen image during the driving simulation in this embodiment includes, for example, the route name, master control position (acceleration position, braking position), door closing light, time (time of arrival at the next station, current time). It includes time, speedometer, signal sign, distance to stop position, distance between stop position and target position, dimmer switch, designated speed, current speed, error speed, and so on. It should be noted that not all of these items are displayed all the time, but include information that is always displayed and information that is displayed only when necessary such as when an event occurs.

First, as shown in FIG. 32(A), the game processing unit 90c displays a screen image during a stop at a station (doors open for boarding/alighting). In the screen image, a door closed light is displayed, indicating that the boarding/alighting door is open. Next, the game processing unit 90c generates a driver event (calling point) for confirming that the passenger door is closed (step D1, Yes).

For the driver event, for example, whether or not the driver's (player's) actions are to be recorded by video (and audio) (event to be recorded) is set. In the case of an event to be recorded, the game processing section 90c starts recording data of video (and audio) captured by the camera 65 (step D3).

As shown in FIG. 32B, the game processing unit 90c changes the display of the door closed light to indicate that the passenger door is closed, and instructs the player (driver) according to the driver event. A screen image indicating that confirmation of insertion is necessary is displayed (step D4). In the case of this calling point, the player needs to touch the door closing light 77 e displayed on the touch panel 77 . The game processing unit 90c determines whether or not there is a touch operation (input of touched position data) on the area corresponding to the door closing light 77e of the touch panel 77 within a predetermined time after the occurrence of the event (step D5).

The game processing unit 90c determines success/failure of the event operation based on the presence or absence of the touch operation on the touch panel 77 and the touched position, and outputs an effect according to the determination result. For example, when the game processing unit 90c determines that the event operation has succeeded (step B4, success), as shown in FIG. A voice (sound effect) saying "OK!" is output (step B5). In this case, the game processing unit 90c adds a predetermined time (for example, 1 second) to the time limit (step B6). On the other hand, when the game processing unit 90c determines that the event operation has failed (step B4, failure), as shown in FIG. output (step B7). In this case, the game processing section 90c subtracts a predetermined time (for example, 1 second) from the time limit (step B8).

When the driver event ends (step D6, Yes), the game processing unit 90c waits for the next driver event to occur. If the video is being recorded for the event to be recorded, the recording is terminated, and the game processing unit 90c converts the video (and audio) shot during the driver event as the event recording data 92f. Record (step D7).

In the above description, the success/failure of the player's operation for the driver event is determined based on the touch operation on a specific area of the touch panel 77, but other methods may be used for determination. For example, it is possible to detect the movement of the player through detection by the motion sensor 66 and determine whether or not there is a predetermined operation (such as moving the arm to point) at a predetermined timing. Alternatively, the movement of the player photographed by the camera 65 may be detected by existing image processing, and the movement may be determined.

Specific examples of other driver events will be described below.
The game processing unit 90c generates a driver event of pointing and confirming when a traffic signal and a speed limit sign appear in the screen image that changes with the operation of the train. FIG. 34(A) shows a screen image at the time of a driver event when a traffic light appears. As shown in FIG. 34A, the game processing unit 90c causes the player (driver) to display a screen image indicating that the player (driver) needs to point to the traffic light. When the difficulty level is high, the game processing unit 90c can set hidden evaluation points without clearly displaying the driver event (step B9), as shown in FIG. 34(B).

The game processing unit 90c determines success/failure based on the player's operation and operation timing, and the current control state of the train (game control state). Perform subtraction. FIG. 35A shows a screen image when the player's operation is determined to be unsuccessful. In this case, a sound effect indicating the failure of the driver event is output. If the player's operation is determined to be successful, "good" can be displayed in the same manner as in FIG. 33(A).

For example, for a speed limit sign, for example, it is determined whether the touch operation on the speedometer 77b of the touch panel 77 is performed at the correct timing, and the current speed of the train is maintained within the allowable range of speed indicated by the speed limit sign. Determine whether or not Similarly, for a signal, for example, it is determined whether the action of pointing in the direction of the traffic signal displayed on the display 62 has been executed at the correct timing, and furthermore, the current running state of the train is the state indicated by the traffic signal. determine whether there is If it is determined that all determinations are correct, the game processing section 90c determines that the player's operation was successful.

In addition, the game processing unit 90c generates a driver event (horn point) for sounding a horn when a person appears around the railroad track in the screen image that changes with the operation of the train. FIG. 35 shows a screen image during a driver event when a worker appears on the left side of the track. In this case, if an operation to sound the horn (for example, an operation to touch the horn button displayed on the touch panel 77) is performed at a predetermined timing (for example, within a range of 50m to 5m in front of the position where the person is present), it is considered successful. be judged. It should be noted that the timing of sounding the horn and the duration of sounding the horn may be changed according to the position and movement of the person appearing on the screen image. For example, when there is a person moving in the direction of the railroad track, if the operation of sounding the horn at an early timing for a long time is judged to be successful (or the evaluation point is high), and if there is a person representing a railway fan etc., Sounding an alarm whistle in an unusual pattern (intermittently twice, etc.) can also be determined as success (or high evaluation points).

In addition, the game processing unit 90c generates a driver event (constant speed point) that causes the train to travel at a preset constant speed when the train enters a constant speed range as the train runs. FIG. 36 shows a screen image at the time of a constant speed driving driver event. As shown in FIG. 36, the game processing unit 90c displays the specified speed, current speed, and error speed on the screen when the vehicle approaches the constant speed range (for example, 100 meters before). The player operates the master computer 72 so that the speed of the train becomes the designated speed. As a result, if the speed can be adjusted within the allowable range in the constant speed range, the game processing unit 90c determines that the driving event was successful. In this case, as shown in FIG. 37A, the game processing unit 90c displays "good" indicating success and outputs sound effects. When the game processing unit 90c determines that the driving event has failed, the game processing unit 90c outputs a sound effect indicating that the driving event has failed, and displays a display according to the determination result, as shown in FIG. 37(B). do not.

Although not shown, the game processing unit 90c, in the screen image that changes with the operation of the train, when a train running on the next track is approaching (dimming point), at an appropriate timing In order to temporarily dim the light (low beam), the light dimming switch 77f of the touch panel 77 is touch-operated. At the timing when the trains have passed each other, the light dimming switch 77f of the touch panel 77 is touched again to switch to the high beam state. The game processing unit 90c determines that the driving event is successful when a series of operations on the dimming switch 77f are performed at correct timing. As described above, the game processing section 90c outputs an effect according to the success/failure determination result.

Further, when the operation to stop the train is performed at the next station (step B11, Yes), the game processing section 90c evaluates the stop position and the arrival time. FIG. 38 shows a screen image when the train is stopped. The game processing unit 90c displays the distance to the stop position at the right corner of the screen image when the train is running, as shown in FIG. 39(A). , displays the distance between the stop position and the target position. In addition, the game processing unit 90c displays the range of less than 2 m from the target position and the range of less than 1 m from the target position as acceptable ranges. Display as "overrun" as shown in .

If the stop position is within 50 cm or less from the target position (step B12, less than ±50 cm), the game processing section 90c outputs a GOOD effect indicating a good stop operation (step B13). Further, when the overrun is 50 cm or more (step B12, overrun), the game processing section 90c outputs a stop position correction effect (step B14).

The game processing unit 90c also evaluates the arrival time when the train stops. While the train is running, the game processing unit 90c updates the display of the current time as time elapses, as shown in FIG. 40(A). As shown in FIG. 40(B), when the train is stopped, the game processing unit 90c determines if the difference between the next station arrival time (target time) and the current time (arrival time) is less than 1 second (step B15). , less than ±1 second), and outputs a GOOD effect indicating that the operation is good (step B16). If the delay is one second or more (step B15, delayed arrival), the game processing section 90c outputs a delayed arrival effect (step B17).

Note that, in the present embodiment, the game processing unit 90c instructs the player, as shown in FIGS. It is also possible to display a help screen to prompt appropriate operations. FIG. 41(A) is a help screen for prompting acceleration by operating the master controller 72, FIG. 41(B) is a help screen for prompting constant speed running, and FIG. 42 is a deceleration operation when the stop position approaches. is an example of a help screen for notifying that the It should be noted that the help screen can be displayed at any timing other than the one described above.

Also, the driving event described above is an example, and a sudden event (for example, a situation requiring an emergency stop) or a sudden change in weather (rain, snow, wind) other than the normal driving operation may occur. It is possible to request an operation according to each situation.

When the evaluation due to the stop of the train is completed, the game processing section 90c causes the display 62 (or the touch panel 77) to display an intermediate result (evaluation result) (step B18). FIG. 43 shows a display example of intermediate results. In the intermediate result display shown in FIG. 43, evaluation contents and evaluation results (number of seconds added/subtracted to the time limit) are displayed for a plurality of items such as timetable, stop position, re-acceleration in the station premises, and emergency braking stop. there is In this way, by displaying the intermediate result, it is possible for the player to easily understand the evaluation status of the driving up to that point by increasing or decreasing the allotted time.

The game processing unit 90c refers to the time limit added/subtracted according to the driving event so far (step B19), and if the remaining time limit is less than 1 second (step B20, less than 1 second), A final result is displayed and the driving simulation is ended (step B22). FIG. 44 shows a display example of the final result. In the final result, for example, the accuracy of the timetable, the accuracy of the stopping position, the brakes (ride comfort), obeying the traffic lights and signs, safety considerations, the caring driver, the distance traveled / (number of continuations + 1), the remaining time. For a plurality of items such as , based on the operation content for the driving event, the score calculated using the calculation formula set for each item is displayed. Also, in the final result, the sum of multiple items is displayed as an overall evaluation.

Note that the game processing unit 90c can, for example, provide items, classes, levels, titles, and the like to the player when the overall evaluation reaches a predetermined criterion.

On the other hand, if the time limit is 1 second or longer (step B20, 1 second or longer) and the terminal has not been reached (step B21, No), the game processing unit 90c causes the train to proceed to the next station as described above. start a driving simulation to drive (step B3~). Also, even if the time limit is 1 second or more (step B20, 1 second or more), if the end point is reached (step B21, Yes), the game processing unit 90c determines the final game as described above. A result is displayed and the driving simulation is terminated (step B22).

After the final result is displayed, the game processing unit 90c registers the player data provided to the player, including the item, class, level, title, etc., in the game server 10 by the player data processing unit 90e in association with the card ID. (step B23).

In the above description, the object is the driving process (driver event mode) for the player playing as the driver. Then, the operation processing (conductor event mode) for the player who plays as a conductor is executed. FIG. 45 is a flow chart showing operation processing (conductor event mode) for a player playing as a conductor.

When a conductor event occurs during the driving simulation (step E1, Yes), the game processing unit 90c determines whether the conductor event is an event to be recorded (step E2, Yes). , and the video (and audio) of the conductor captured by the camera 65 is recorded. The game processing unit 90c displays a screen corresponding to the content of the conductor event and receives an input operation corresponding to the conductor event (step E5). The screen corresponding to the content of the conductor event is displayed, for example, on the display 63R so as not to hinder the operation of the driver. The game processing unit 90c determines whether a correct input operation (response) has been performed based on the player's (conductor's) input corresponding to the conductor event (step B10). The game processing section 90c outputs an effect according to the determination result in the same manner as the driver event (steps B5 to B8).

For the conductor event, the degree of difficulty and determination criteria are set according to the player management data (player experience, class, level, etc.) corresponding to the player who is the conductor corresponding to the card ID. That is, the degree of difficulty and criteria for determination of the driver event and the conductor event are made different. Thus, even when two players with different proficiency levels play the game in the two-player mode, they can enjoy the game at their respective levels. It is also possible to set the degree of difficulty and criteria for determination based on the player management data of either the driver or the conductor.

When the conductor event ends (step E6, Yes), the game processing unit 90c ends the recording if the conductor event is being recorded (step E7), and stores the card ID and They are recorded in the storage section 92 in association with each other.

FIG. 46 is a diagram showing an example of a screen image when a conductor event occurs. The conductor event shown in FIG. 46 is to make an announcement in the train when the train is near the station. The game processing unit 90c displays the content of the in-vehicle announcement in text, and changes the display color of the text according to the timing of the utterance. For example, a text such as “Next is Yokohama, Yokohama. The exit is on the right. The player (conductor) vocalizes in accordance with the change in the display color of the text and inputs the voice from the microphone 59 .

Based on the sound input from the microphone 59, the game processing unit 90c determines whether the input is correct. It should be noted that it is also possible to simply determine that the voice has been input at the correct timing without identifying the content of the occurrence by performing voice recognition processing here. In addition, the game processing unit 90c detects that a predetermined action such as holding a microphone 59 (for example, a handheld microphone) is performed by the image input from the camera 65 or the motion sensor 66, and determines the action of the conductor. You can make it work. Also, a conductor event may be included that requests the conductor to perform other actions.

Note that the conductor event can be generated by arbitrary contents other than those described above. It is assumed that the conductor event requires a different operation content at a different timing than the driver event, for example. In addition, it is also possible to determine that the operation for the event has been successful when each player, the driver and the conductor, cooperates and performs the correct operation for one event that is suddenly generated. . As for the conductor event that occurs suddenly, the text may not be displayed as described above, but the player (conductor) may be allowed to input the voice of the in-car announcement by ad-lib.

In the above explanation, two players are supposed to perform operations corresponding to events for the driver and the conductor, respectively. It is also possible to configure so that operations corresponding to events for hands and conductors are performed.

In this way, in the game device 20 according to the present embodiment, a plurality of players (drivers, conductors) can simultaneously enjoy a driving simulation game.

The above-mentioned conductor event is assumed to be executed when the two-person mode is set (when card IDs are read from two cards), but one player (driver) performs the driving simulation. During execution, it may be generated regardless of the evaluation of the game. For example, as described above, the screen image shown in FIG. 46 is displayed at a predetermined timing during the driving simulation, and the player's friends (the number of friends may be unspecified) participate in the game as conductors. be able to. Even in such a case, a plurality of players can simultaneously enjoy the driving simulation game.

Note that the evaluation by the conductor event may be calculated separately from the evaluation of the driver described above, or additional points may be provided according to the cooperation with the driver, or the evaluation of the two-player play may be calculated. You can do it. The evaluation result can be registered in the game server 10 in association with the card ID corresponding to each player.

When the battle mode is selected, input operations corresponding to the driving simulation are executed in each of the game devices 20 participating in the battle, as described above. When the two-player mode is set, a battle is executed by driving simulation executed in the two-player mode. On the displays 62, 63R, 63L, for example, an image of a train run by the opponent is also displayed simultaneously in a partial area of the display. In the battle mode, trains running on the same route may compete against each other, or trains on different routes running in parallel may compete against each other.

Next, the operation for creating diorama data in the game system according to this embodiment will be described.
A player using the mobile terminal 16 can create diorama data by executing a game provided by the game server 10 on the mobile terminal 16 to obtain diorama parts for creating a diorama according to the game result. can.

FIG. 47 is a flow chart showing processing (diorama creation processing) by the game server 10 when executing a game on the mobile terminal 16 .

When the game server 10 receives a game execution request together with the card ID of the player identification card possessed by the player from the portable terminal 16 (step F, Yes), the game server 10 records the data as player management data corresponding to the card ID. Data such as the player's item and acquired train (my train) are transmitted to the portable terminal 16 (step F2). The portable terminal 16 executes a game using, for example, the items and acquired train (my train) received from the game server 10 and transmits the game result to the game server 10 .

When the game result received from the portable terminal 16 satisfies a preset clear condition, the game server 10 selects selectable diorama parts according to the clear content (step F4). The game server 10, if there are diorama parts corresponding to the contents of clearing and diorama data registered in advance by the player, transmits the diorama data to the portable terminal 16 (step F5). In addition to the diorama data for the cleared content, train-related vehicle parts (for example, decorations such as head marks and wrapping) that can be used in the driving simulation of the game device 20 are selected and transmitted to the mobile terminal 16 . You can make it work.

The portable terminal 16 creates diorama data using the diorama parts received from the game server 10 and transmits the data to the game server 10 . The game server 10 receives the diorama data from the portable terminal 16 (step F6), and records it for each route in association with the player's card ID (step F7).

Here, creation of diorama data executed in the portable terminal 16 will be described. In the initial state of the diorama data, for example, as shown in FIG. 48, a circular track 200 (and station) on which trains run and a base 210 with a grid set over the entire surface are included. As shown in FIG. 49, the base 210 has a minimum grid (1×1) 220 on which one diorama part can be placed.

Regarding the placement of diorama parts on the grid, there is a mode in which individual diorama parts representing buildings and railroad tracks can be placed in detail on a grid basis, and a mode in which diorama parts that combine multiple parts can be placed together. and FIG. 50(A) shows an example of diorama parts arranged in one grid, and FIG. 50(B) shows an example of vaorama parts in which a plurality of parts are combined.

In addition, small parts (basic parts such as small buildings such as houses and roads), medium parts (parts such as multi-tenant buildings, stations, condominiums, supermarkets, small parks, etc.), large parts (large apartments, schools, parts of commercial facilities such as department stores), oversized parts (parts of large commercial facilities, amusement parks, factories, gas tanks, airports, etc.), landmarks (actual landmarks that are more elaborate than others) ), etc. shall be provided. The player of the portable terminal 16 can create diorama data by arranging the diorama parts in a required number of grid ranges according to the size of the diorama parts.

In the above description, the diorama parts are provided from the game server 10 according to the contents of the game executed by the portable terminal 16, but the diorama parts may be provided by other methods. . FIG. 51 is a flowchart showing diorama parts lottery processing by the game server 10 . In the diorama parts lottery process, points are added based on the physical position of the portable terminal 16, and when the points satisfy conditions, a lottery for selecting diorama parts is executed and provided.

When the game server 10 is accessed from the mobile terminal 16 (player) together with the card ID of the card for identifying the player (step G1), it receives the current position (GPS data) of the mobile terminal 16 (step G2). The game server 10 determines whether the current position of the mobile terminal 16 is within a preset target range, for example, the vicinity of a railway station (step G3). That is, the game server 10 determines whether the player has visited near the actual station and accessed from the portable terminal 16 .

Here, when it is determined that the current position is within the target range, the game server 10 adds points to the lottery points of the player management data corresponding to the player's card ID (step G5). Therefore, the player can earn points by visiting multiple stations.

When the lottery points reach the preset points (step G6, Yes), the game server 10 sends a lottery ticket to the mobile terminal 16 indicating that the diorama parts lottery can be executed. Send. By using the lottery ticket received from the game server 10, the mobile terminal 16 can request the game server 10 to draw a lottery for diorama parts at any timing.

When the mobile terminal 16 requests the game server 10 to execute the lottery (step G8, Yes), the game server 10 executes a lottery for diorama parts and selects one of a plurality of prepared diorama parts (step G9). . The game server 10 transmits the diorama data corresponding to the player's card ID and the diorama parts selected by lottery to the portable terminal 16 (step G10).

Based on the diorama data and diorama parts received from the game server 10, the portable terminal 16 can create diorama data by setting the placement positions of the diorama parts as described above.
When receiving the diorama data from the portable terminal 16, the game server 10 records the diorama data in association with the player's card ID.

In this way, the game server 10 can register the diorama parts created by the player using the portable terminal 16 in association with the player (card ID). As described above, the diorama data can be used as options for train routes when the player executes a driving simulation on the game device 20 . That is, since the route used by the player on the game device 20 can be arbitrarily created in advance as diorama data, it is possible to change the course for the driving simulation so that the player is interested.

It should be noted that the present invention is not limited to the above-described embodiments as they are, and can be embodied by modifying constituent elements without departing from the scope of the present invention at the implementation stage. Further, various inventions can be formed by appropriate combinations of the plurality of constituent elements disclosed in the above embodiments. For example, some components may be omitted from all components shown in the embodiments. Furthermore, components across different embodiments may be combined as appropriate.

Further, the control method described in the embodiment can be executed by a computer as a program (software means), such as a magnetic disk (flexible disk, hard disk, etc.), an optical disk (CD-ROM, DVD, MO, etc.), a semiconductor It can be stored in a storage medium such as a memory (ROM, RAM, flash memory, etc.), or can be transmitted and distributed via a communication medium. The programs stored on the medium also include a setting program for configuring software means (including not only execution programs but also tables and data structures) to be executed by the computer. A computer (for example, personal computer, home game machine, smart phone, mobile phone, television, car navigation system, etc.) that implements this device reads a program stored in a storage medium, and in some cases, uses software means according to a setting program. is constructed, and the above-described processing is executed by controlling the operation by this software means. It should be noted that the storage medium in this specification is not limited to those for distribution, and includes storage media such as magnetic disks and semiconductor memories provided inside computers or devices connected via a network.

Claims (2)

a lever that rotates forward and backward on one axis;
It is integrally formed with the lever so as to cover a portion of the lever on the shaft side by an arc-shaped outer peripheral surface centered on the shaft and a surface parallel to the rotation direction of the lever. a lever receiving member formed in the
a member for defining a movable range of the lever and defining a plurality of rotational positions of the lever within the movable range;
a base provided with a rectangular opening that exposes a portion of the lever that is not covered by the lever housing member and a portion of the lever housing member;
A portion of the lever accommodating member is exposed from the opening to the surface of the base, and the lever is positioned at any position within the movable range of the lever defined by the member within a range in which the lever and the base do not come into contact with each other. The input device is formed such that the lever accommodating member exposed up to the surface of the base covers the lever even when the lever is rotated. . The member is a projecting member,
Further, the projecting member is detachably attached to a path through which the projecting member passes along with the rotation of the lever, which is arranged at a position facing a surface of the lever housing member parallel to the rotation direction of the lever. 2. The input device according to claim 1, further comprising a regulating member provided with holes for regulating a movable range of said lever and for regulating a plurality of rotational positions of said lever within said movable range.

Images