Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Current situation up to 0.6
- GUI and simulation logic are mixed up (although I tried to separate them and make them talk through signal/slot mechanism, it is not always as clear). The monolithic construction of TS2 makes it hard for a newcomer to understand how it works.
- Namespaces are just awful. Just don't ask me why a file is inside a folder and not another one. And we have circular references which have been worked around in a very ugly manner...
- It's quite impossible to have several coders work at the same time on TS2 code.
- We all see the interest of having a software with a lot of interfaces so that it can be used as it is now (a signalling simulation game), but there are ideas of interfacing it with real model trains for example.
New architecture (v0.7 onwards)
So after we have released v0.6, my idea is to split up the software following this arch starting from v0.7:
TS2 sim server
This is the central piece of the software. It is shipped with the TS2 release.
It can be run:
- Locally for a standalone game (as it is now)
- Remotely on another PC or even on a cloud server for multi-player gaming
The TS2 sim server tasks are
- To centralize the game data, that is:
- Scenery layout (The track items, and how they are connected to each other, their states, etc.)
- Possible and set routes
- Services and Trains
- To enforce interlocking by calling in turn the appropriate managers on :
- Route setting/unsetting
- Change of points position
- Update of signals aspects
- Make the clock tick
The TS2 sim server communicates with other TS2 components through websocket.
Initial game data can be downloaded from TS2 data server (through standard http, like it works now) or uploaded from client (e.g. saved game), depending on user choice
The TS2 sim server has no UI and will not depend on Qt or any of its binding. Programming language to be defined.
See also TS2 Sim Server Specifications
TS2 clients will be in charge of user interface:
The reference client will be a PyQt client adapted from the current TS2 software.
Other clients can be imagined :
- Webclient (at least to display time tables or make presentations)
- Android/iOS clients
- "Near reality" clients in order to have the look&feel of real signalling centres, depending on countries/technologies
The launcher will be in charge of:
- starting all components necessary to play ts2 (i.e. a ts2 sim-server, a client and necessary managers)
- locally managing simulation files, and resource files (such as .tsl)
The editor is not really a client since it does not need to communicate with the ts2 sim server. However, I will probably keep it inside the PyQt client since they share many classes.
These will be independent services that are in charge of simulating all the inputs that we have in real life and that are not in a simulation.
There are different managers, and each can have different implementations. The implementation to use will be defined in the simulation JSON definition.
Each manager will be able to register to specific events at the TS2 sim server to be notified only when necessary.
The managers have no UI and will not depend on Qt or any of its binding. Programming language to be defined for each.
This manager is in charge of calculating the trains positions at each clock tick from data sent by the TS2 sim server and send the info back to the sim server.
The reference train manager will be derived from the current TS2 implementation.
Other implementation may include getting the info of position from a model train set or even from real railway timetables.
This manager's main task is to send back the status of a trackitem after a command. It is both :
- an output interface through which every command to track items are sent
- an input interface for the feedback, which enable simulating breakdowns
Eg. When the TS2 sim server will be requested to move points, it will send the command to the trackitems manager. The latter will respond with the points position (potentially after a delay of a few seconds).
Each type of track item can use a different implementation of trackitems manager.
The reference implementations will be:
- A signalItem manager derived from the current signalLibrary mechanism in TS2 for signals
- An 'always return True' manager for other items (no breakdown) at first.
Other implementations can include :
- Sending the output to model railway through arduino
- Responding with more or less breakdown probability
This manager's tasks are:
- To enforce route interlocking by responding to the TS2 sim server whether the route can be set/unset or not after request.
- To destroy the route after train passes if the route is not persistent
The reference implementation will be derived from the current TS2 software.
This is the 'Automatic Routing System' manager. It is a software by itself which looks up in the TS2 sim server for info and sets up routes according to its built-in rules.
Several implementations of ARS can be imagined to reflect different countries/technologies.
TS2 data server
This is the server for storing/exchanging simulation files. It is the extension of ts2-data repository.
This part of the project is not impacted by the new architecture.