For the last few months, I’ve been slowly putting together the next version of the freight train operations game that an N-Scale modular club I belong to has been using for a few years. This new version, which I’ve been tentatively calling Freight Commander, is a complete rewrite that moves away from ASP.NET and MS SQL and instead is built on open source software. Additionally, I’m releasing the program as an open source project so anyone can use or modify it and adapt it to their needs. I’m planning to release it in two versions: one is electronic where a smartphone or small tablet replaces the clipboard and paper car cards for game interaction. The second uses a thermal receipt printer to print switch list instructions on demand.
Freight Commander is a significant improvement over the original train game platform. The biggest change is that the game is designed to be state-aware. The game itself knows how many players there are, how many cars are in service, and where those cars are going to. A much needed change was the logic behind how shipments between industries occur. The former system did a simple mapping where every producing industry would match to an applicable consuming industry, except itself. This lead to very high traffic at some industries and almost no traffic at other industries, depending on what was available on the layout at the time.
The new matching system uses a statistical algorithm where activity levels can be defined in advance and industries with high activity levels will be picked more often for shipments than those with low activity levels. The new matching system is also dependent on player activity. A single, busy industry can be chosen multiple times for shipments, but will quickly become saturated and unavailable for new orders if players are not there to transport products.
Freight Commander, like its predecessor, is a database driven game and is in the very early stages of development. In fact, what’s coded so far is only core game logic and database schema. I am in the process of crafting the database interface for the front-end client. If you’re interested in seeing how a project like this comes together, I encourage you to take a look at the codebase. The language being used for all game logic is structured query language, specifically MySQL. Check out the Freight Commander Manual for development notes. Then look through the MySQL code folder. The entire project is available on GitHub.
MySQL Code Folder: https://github.com/tbdye/FreightCommander/tree/master/MySQL
- Tables.sql: Contains relational entities for game logic
- Procedures.sql: Gameplay logic
- Functions.sql: Helper functions for stored procedures and client interaction
- Data.sql: All data defining a small modular layout
- Tests.sql: Unit tests for checking program flow
- Views.sql: Database to client interface (unwritten)
Original Train Game written for the 4dNtrak Modular Railroad Club: http://4dntrak.azurewebsites.net/Game/Default.aspx