FAQ

How is this different from the average city builder game?

There are indeed existing simulation games for transportation networks, with 3D-Public-Transport-Simulator being a close neighbour. However, this project distinguishes itself in key ways.

Most existing simulators focus on city-building mechanics or general logistics rather than specifically transit optimization. They often compromise on physics, AI complexity, and realism to provide a broader entertainment experience. In contrast, this project is fully focused on public transit systems. We are creating a realistic simulation that captures the nuances and complexities of real-world networks. Despite using 2D graphics for simplicity, we aim to push the boundaries of simulation accuracy.

Furthermore, many city builders, like Cities: Skylines 2, are commercial products. Even detailed simulators like Subway Builder are often paid and closed-source. These titles are less suitable for researchers or planners who need to modify and/or inspect the code to meet their requirements.

By creating a free and open-source project, we democratize access. Transit planners, researchers, and enthusiasts can experiment with designs without licensing fees or restrictions, hopefully fostering innovation in the field.

Why use MonoGame instead of a game engine?

I (smallketchup82) previously contributed to osu!(lazer), which was based on osu-framework. Developing for osu! is the only experience I have so far in game development, so I'm used to its constructs, concepts, and structure. I've become used to writing scene graphs with code, using a drawable system, using multiple threads, and using an attribute based DI system.

While developing with a full production-ready game engine like Unity or Godot would be much faster, I feel like over time it will hinder development. Having to use both a visual editor and JetBrains Rider at the same time is not a workflow I'm familiar with, or enjoy. Because of that, I've decided that the best way to build this simulator is to ensure it is entirely programmatic, with the only tools required being an IDE, Git, and the .NET SDK.

If osu-framework is the inspiration for the game's engine, why not just use osu-framework itself?

This is something I've deliberated over, and still do. The decision isn't solid, and I may scrap everything to use osu-framework if I believe it's better. These are the factors I'm considering at the moment:

Pros:

• Is familiar to me
• Is mature, having undergone years of testing & debugging
• Would allow us to focus solely on building & maintaining the simulator without having to first build & maintain an engine.
• Has a very powerful visual testing system
• Lovely drawable system, with great positioning, scaling, and transformation systems.

Cons:

• Touches low-level system features more than MonoGame
  • For example, the fact that osu-framework calls SDL directly & uses BASS.
• Is built for rhythm games, which this project isn't.
• Includes systems which we may not use, possibly resulting in application bloat & longer build times.
• Is maintained by the osu! developers, which also have to maintain osu!(lazer).
  • If we wish to make changes to the engine, we either have to:
    • Fork it and use our fork. Adding our changes to the fork and backporting them to upstream.
    • PR all of our desired changes & features to upstream, which can take months to get reviewed & merged.
• Very basic documentation, leaving many features to require reading the framework's source code.
• No way to define your own threads to use (e.g. we don't need the Audio thread)

While I'm at a standstill when it comes to continuing development on our engine, or dropping it for osu-framework, you can let me know what you think over in the GitHub Discussions.

Why is the simulator 2D

Visually, this game draws inspiration from Mini Metro. Mini Metro's use of simple shapes for transit vehicles is something I've always loved. I also admire the minimalistic UI & HUD.

Physically speaking, the only thing we lose out on by going 2D is the ability to simulate topography (i.e. trains going slower/faster when going uphill/downhill). However this is a minor compromise in realism, as the benefits from going 2D--namely better performance & easier development--outweighs the downsides of going 2D.