The simulator program purpose is to simulate railroad operations. In volume of C++ code, the largest simulation will be the graphics, physics and user interface for steam, electric and diesel locomotive operation and other train components. The remaining railroad simulation will be accomplished with AngelCode scripts, run in the simulation during idle time.

When developing code for this simulation, the C++ routines will be limited to discrete operations. For example C++ code will be developed for moving a railroad switch for one position to another, but a CTC simulation that operates the switch, in manual or AI mode, will be developed in AngelCode script and scheduled to run when triggered in the route/path database design. By using script for the operational details of the railroad the route designer is able to control, modify or correct the simulation of his route.

The simulation will be included for the train crew (engineer, conductor, brakeman and the era dependent fireman, head brakeman and flagman), yard drill (engineer, conductor and brakeman), yardmaster, switchmen and freight agent. Other possible simulation roles are hostler, power desk or roundhouse foreman, dispatchers, towerman and block operators, trainmasters and rules examiners (See “Designing Model Railroad Operations” NMRA). These user simulations are created by assign control of communication and control assets of the route simulation to a defined user role (yardmaster etc.). Each game player may take control of the more then one role in the simulation.

Each route will have provisions for a simulation including information of location, era, industries served and paths. The route will generate passenger and industrial volume for the simulator and user roles. The route will include baseline schedules and an automatic operation for demos and test of the route.

• Simulator-User – game player Train-Crew – Roles attached to a specific locomotive and train consists.
• Yard-Drill – Roles attached to a specific locomotive and yard.
• Yardmaster – Role attached to a specific yard.
• Switchman – Role attached to a specific yard.
• Freight-agent – Role attached to a specific yard.
• Hostler – Role attached to a specific locomotive.
• Power-Desk – Role attached to a group of locomotives.
• Roundhouse-Foreman – Role attached to a group of locomotives.
• Dispatcher – Role attached to section of the mainline.
• Towerman – Role attached to a group of switches.
• Block-Operator – Role attached to a section of the mainline.
• Trainmaster – Role attached to a section of a route.
• Rules-Examiner – Role attached to a railroad route.
• Tasks – Runs and schedules scripts.

• Change a path.
• Light signal lamps.
• Extinguish signal lamps.
• Open traffic gates.
• Close traffic gates.
• Advance clock.
• Freeze the game.
• Save the game state.
• Restore the game state.
• Read an initial game state.
• Network chat.
• Synchronize game state with network group.
• Load a route.
• Synchronize route with network group.
• Evaluate user and group network reputation.
• Play sound.
• Display a menu.
• Exit a menu.
• Play music.
• Load models.
• Animate models.
• Load cameras
• Animate cameras.
• Run simulation models.
• Replace roles with AIs.
• Read user input.
• Display errors.
• Display variables.
• Edit variables.
• Run real time tests.
• Identify intellectual prosperity rights.
• Test program integrity.

• Script System – ITask simulation interface.
• Sound System – ISound simulation interface.
• Graphics System – IGraphics simulation interface.
• Network System – INetwork simulation interface.
• Menu System – IGui simulation interface.
• System – ISystem simulation interface.
• Factory – IFactory simulation interface.
• Simulation – ISimulation interface.
• AI – IAi simulation interface.
• Input – IInput simulation interface.
• Console – IConsoleClient simulation interface.
• Tweak – ITweaker simulator interface.
• Test – ITest simulator interface.
• Property Management – IPropertyManager simulation interface.

IFactory is the simulation interface used to generate game entities. This is an abstract class to insure a common interface for the use of the ISystem classes. This class is interface between the xml route data files and the simulator interface classes (IGraphics, ITask etc.).

A game entity represents not only in the case of the railroad simulation, a train or other moving or fixed object, but also events and triggers. For example, the train engine crossing a point on the track path generating an event for a user script, is a game entity. Game entities can also represent test and tweaker objects used to maintain or adjust the railroad simulation.

In keeping with the design of the Ogre 3D graphics system a game entity should be made up of a composite of objects that represent the entities effects on the train simulator. The IFactory interface should make available to the scripting system a general purpose object that can create a composite object that will be registered with the appropriate interfaces of the simulator. For example, the game entity for a locomotive simulation would include objects to be registered with the IGraphics, ITask, and ISound interfaces. In addition, IFactory could be used to create and attach to the composite entity a locomotive cab simulation with graphics, sound and animation.

The IFactory interface should be driven by an ITask script reading from the route/path database. This script could be developed as an AngelCode script initially and later be converted to a single script call to a C/C++ routine. For the purpose of the Fly-by-wire Demo and development the task should be maintained as an AngelCode script.

The System Class is the interface class for the railroad simulation game and essentially is the game program itself. The class is implemented in the …/src/simulator/system.cpp file. This class is created in main.cpp and includes the entire railroad simulator game. The System class maintains the game state and dispatches the main game loop to the current foreground state. The System class also executes the background state for each state in the system state vector for every pass of the game loop.

Each interface class of the game is a sub-class of ISimulatorComponent abstract class and includes three interfaces startup(), operator() and shutdown(). The System class calls the various interfaces of the ISimulatorComponent sub-classes as it moves from state to state. The last (back) state in the state vector is the current state and its operator() is called. Only the last (back) state can modify the system state vector.

The member System::operator() dispatches the game loop thread to a background or foreground system states. The simulator is shutdown when the system state vector is empty. System: operator() also calls the Ogre messagePump() for the Windows and Linux message processing. The messagePump call is made through the IGraphics interface.

The System state machine is defined in system.cpp as a template. The current game states are: State<STARTUP>, State<GUI>, State<ROUTESTARTUP>, State<ROUTESHUTDOWN>, State<SIMULATION> and State<SHUTDOWN>. Each system state has four members, startup, shutdown, background and operator() (foreground state). The foreground operator() is responsible for moving the train/railroad simulator state machine from state to state by pushing or popping a state from the end of the system state vector.

At this time the ISystem interface supplies platform dependent utilities (so far only getFrameMilliseconds from the IGraphics interface) to the ISimulatorComponent sub-classes making up the railroad simulation. ISystem can supply a pointer to any ISimulatorComponent class used in the game engine for the use of any other interface. ISystem holds a class singleton of each interface and is responsible for creating and destroying each of these interfaces. Every ISimulatorComponent sub-class is initialized with a pointer to the ISystem interface class.

Abstract

OSRail will maintain property rights and players reputation through a F2F (Friend to Friend) peer network that has both individual and group management protocols. The network will maintain intellectual property rights through management protocols and group democratic processes. Individual property rights owners will retain veto rights on the use of their property by the group and will have membership in any group for that limited purpose. Player reputation is maintained automatically with network participation and group use of player art/media asset. Player reputation can also be modified through group democratic processes.

Introduction

The primary purpose of the network is to enable network play of the Game/Simulation. The size of the group playing the game is assumed to be small, in the range of two to at most a few hundred. The general group members are divided into smaller groups having varying authorities related to the sub-group's purposes.

Database

Network

Network connections are established when one player publishes an IP/Port address reachable by the other players. This can be done with the others players public keys, either with e-mail or a web site connection. Once a connection is established to all players’ an IP/Port is exchanged. All idle time is filled with the exchange of group database information used to bring the players subversion repositories into synchronization.

Player Organization

• Chairmen of the Board
  

  The owner of the group can be removed only by a unanimous vote of the general group membership. In practices the more likely scenario is the group general membership will dwindle until there is no useful group willing to play with the chairman.

• Board Members
  

  The group leadership, a member can be removed by a majority vote of the other board members with the chairmen only voting to break ties. The board members will propose and vote on the group social and operation rules. Board members must consider proposes for rule addition or changes from the general membership. This is enforced by the automatic accumulation on the board members reputation.

• Railroad President
  

  This position is awarded through game play and represents the best economic or the most profitable player among the railroad division chiefs. The Railroad President can be changed anytime by majority vote of Board Members.

• Division Chiefs and Master Mechanic/Chief Engineer
  

  These positions are awarded through game play and represent the best Track/Road Masters, Yard Masters, Station Agents, Shop Foreman, Engineers, Fireman and Conductors of the railroads operating divisions.

Artist/Media Organization

• Owner
  

  The originator of an art/media asset – The owner has veto power over the use of any asset that is placed in the system by that owner. Permission can be added or withdrawn from any group network wide. The owner's reputation is automatically updating on the basis of his consistent behavior and the maintenance of his art/media assets.

• Route Master
  

  The originator of the collective art/media/data then makes up a route - The Route Master has veto power over the use of his route. Permission can be added or withdrawn from any group network wide. The Route Master's reputation is automatically updated on the basis of his consistent behavior and the maintenance of his route assets.

• Activity Master
  

  The originator of the collective data then makes up a route activity - The Activity Master has veto power over the use of his route activity. Permission can be added or withdrawn from any group network wide. The Activity Master's reputation is automatically updated on the basis of his consistent behavior and the maintenance of his activities.

• Era Master
  

  The Era Master is appointed by nomination and vote of the Board Members. The Era master has group wide veto power over the use of routes and equipment by the group. The Era Masters reputation is automatically updated on the basis of uses out of era equipment by the group.