Someone invited me to post about my project on these forums! It seems appropriate, given that there is a lot of engineering, programming and art stuff involved.

So me (and my team) are making a very detailed metro train simulator. It's based around ex-USSR metro trains, primarily focusing on certain 70's-80's trains which are still widely used and largely regarded as legendary in the eastern europe. The trains are fully simulated - every component, electric relay, wire, all pneumatics and so on. Essentially, the model inside the computer is absolutely the same as the real thing, down to very subtle details of its operation.


This simulator is available as both an industrial version and as a game version (to be released on steam sometime soon). There are three distinct parts to the project:
1) The rendering is done by Unreal Engine 4. I'm doing all the core C++ stuff and all of the textures and technical art.

2) Train physics are done by a physics engine I wrote which solves the rail vs wheel contact (so the trains stay on rails entirely due to dynamic forces that act between the wheel profile and the rail profile). The physics are integrated with PhysX, which solves suspension and other rigid body stuff.

3) Internal system simulation is also done by me. I've reverse engineered the entirety of the 81-717 train (and some others too, to an extent) - the simulation is based on all the real schematics and various engineering data I recovered from a ton of sources. Old books, photos, various schematics etc. The simulation runs realtime and calculates stuff like how electric relay contacts move under influence of electric current, all processes in the power and control circuits and so on. Based on a framework I made for simulating aircraft & spacecraft systems.


81-717 train (that is one of the most fun ones to drive) is a DC, rheostat-based train. The control systems are entirely based on electric relays. It's very sturdy and reliable, the first ones were built around 1979 - and these trains are still widely in use! Here's most of the electric circuits of the 81-717 train: http://i.imgur.com/1dosMkg.jpg

I'm afraid I can't any nice screenshots just yet (we have not announced the project), though there's some stuff on our development blog at http://devblog.foxworks.cz

The project is based on a prototype that was an addon for Garry's Mod. It was also simulating pretty much all of the electric circuits of an older type E metro train ( https://steamcommunity.com/sharedfiles/filedetails/?id=261801217 ).


Don't know what else to describe without making the post overly long, so feel free to ask any questions. I can answer just about any technical or other questions that don't have to do with stuff like "when is it going to be released". 'Subtransit' is the name of specifically the public game version (and no, it will not be significantly different from the industrial version, all of the train systems and simulation will be available in full detail in the game).

(and by the way, if anyone has interesting questions, I might just make a tech post in the blog as an answer. I've got a ton of things queued there, but haven't had time to type everything up!)

Hey this looks pretty neat!
Is it like an advanced Train Simulator?
Also, what is the minimum hardware recommended to run this game?
Could you port it to the TI 84 Plus CE?
Also, welcome to Cemetech!

It's more of a simulation of the entire metro system (and trains in great detail). While Train Simulator is more like playing with model trains, this is more like... mmm... DCS World comes to mind, with detailed simulation that is focused on few select vehicles in great detail rather than a lot of different model trains that all generally behave the same way.

The recommended hardware to run the game is currently set as:


I've never actually had a TI calculator, but the way simulation is built demands at least 4 cores (or 4 processors) and an efficient multi-tasking OS, so probably not.

Welcome to Cemetech, Black Phoenix! When you get a chance, please Introduce Yourself in the appropriate thread. It was I who encouraged Nik to invite you here, because between low-level programming, game programming, art, and trains, you're pushing all my buttons (and hitting quite a few topics on which Cemetech focuses). To seize on one particular aspect that you mentioned in your first post, namely guiding trains using the physics between the wheels and the rails: long ago, I was working with Cemetech administrator elfprince on modifying, and later rewriting, the venerable virtual LEGO-like game Blockland, which you may or may not have heard of. I desperately wanted driveable trains in the game, so I made a few trains, and I also went as far as trying to make the wheels' collision meshes play well with rail pieces' collision meshes. Of course, this was a physics engine from over 12 years ago (specifically in the Torque game engine), but I found that anything other than straight rails was quite problematic. Specifically, the discretization of any curves into sequences of small straight pieces would cause physics computations to rocket my train into space. Is this something you'd had to deal with, especially since from the screenshots on your blog it looks like your curved tracks are currently not the smoothest?

Also, since we were discussing it last night on IRC, and I have experience driving real and virtual trains (and a pair of degrees in Electrical Engineering), I'm curious if you can explain more about the problem you were describing in this diagram:

This looks really, really nice, and of all the projects I've seen on Cemetech, probably the one I'm most excited about - even if I never get to play this, as 1.73 GHz i7 and Nvidia 3-hundred-and-something on my laptop are nowhere near enough. And I don't even play many games, other than Minetest where, surprise surprise, over the past few years I have built a world consisting of a relatively big subway network, complete with ticketing system and everything, with a relatively smaller city on top Of course, the train simulation there (the mod I'm using is https://github.com/orwell96/advtrains , in case anyone is interested) doesn't have even 5% of the realism you seem to be aiming for, nor does the Minetest engine allow for it.

I'm way more interested in the operation of the network as a whole (stations, signaling, automation, etc.) than specifically in the trains, so I hope you put as much detail into that as you seem to be putting into the trains.

I'm wondering if your idea for this project is to make a fixed-world simulation (where you can interact with the trains and signals and so on, but can't really dig new tunnels, or build new lines and stations), or to give more freedom to the players, letting them control all aspects of the world, both at a small and big scale? I understand that the latter is certainly much harder and thus out of the scope of your project, but I assume that at least support for mods and custom maps is one of your long-term goals?

I was going through your development blog and found this...

To offer a bit of a different perspective, I ride the Lisbon Metro more or less once per week. There, the trains are sturdy, relatively reliable, and are now about 20-25 years old. There are no schedules and the trains are spaced 4 to 4+randint(30) minutes apart, and the ETA displays, that we only got three years ago or so, remind us of the Windows copy dialog from 20 years ago, with the estimate jumping around. The whole transport network, being heavy rail, is quite expensive to build and maintain, and is incredibly inefficient - all trains stop at all stations, nothing is automated (there was an automated line, which no longer is because the automation was obsolete and because of worker's union pressure), and in stations, many escalators are broken. Ticket options are also a mess, and not cheap, to top it off I may have exaggerated for comedic effect but the truth is that whenever I go down there, there's always something wrong.

It seems that your product will be able to simulate a network down to trains stopping due to engine failure, I wonder if it will also be able to cause passengers the same anger and stress as real ones. Such realism, much wow

Actually I believe you've been looking at the screenshot from the prototype version of the game. It was built in Source engine and used Havok as its physics engine with specifically craft collision box for the wheels:


The gauge was widened in the turns to permit for hunting free motion of the wheels. From physics point of view, the wheels are sliding along the track (Havok has serious issues when objects spin at high angular velocity - for the train wheels it was an equivalent of 30 km/h). That's in Metrostroi - the old prototype.

The actual new simulator has rails which can be as smooth as needed or as bendy as required:


The new simulator physics are based around computing full collision between the modified conic wheel and modified flat top rail, then computing the dynamic forces which happen due to that. In this context, "modified" means that while the baseline collision detection is done on cone vs flat rail shape (done so for performance reasons, it's the fastest and simplest collision method), the collision point is then re-computed into effective pressure/contact point between profiled wheel and rail.

In other words, the simulator finds fast collision with the rail, then recomputes results of fast collision detection into an equivalent full collision (in reality wheels are not cones, they have a specific profile to them):


If you don't know why the wheels have that specific shape (conic), then you're welcome to check out this video: https://www.youtube.com/watch?v=y7h4OtFDnYE

So now the interesting part. The rails are not discretized in any way! The collision detection is parametric and provides absolutely smooth rails. The physics engine treats left and right rails independently. The rails are actually a parametric curve of a special kind (lets call it railway curve) interpolated using splines for performance reasons (so the rail consists of small splines).

These splines can be ideally smooth... but in reality, that produces for an ideal train motion! The physics engine is sensitive enough to every single subtle effect in the rail shape. Which is why physics engine actually bends the rails around to simulate uneven rail layout, simulate differences in rail shape (due to wear or manufacturing tolerances), simulate thermal expansion, simulate tunnel drift and rail drift (when rails get offset from their normal positions).

The rail joint model provides mechanical response to train passing over a rail joint - with elastic/offsetting response from the two rails that make up the joint. Currently this part is under development, but the basic model is already present.

Now there's actually a defect in the engine right now... the rails look too smooth! Currently for performance and optimization reasons left & right rails are rendered as a single model that is tied to the tunnel axis rather than their physics locations. This means that actual physics rails are all bendy and stuff... but they seem perfect on the screen.

I have a couple ideas on how to fix this defect, though it will require additional performance sacrifice (basically, the physics engine will encode displacements into all of the rails, compensating for the difference between physics and rendering).

The physics engine runs at a high rate (120 Hz usually), which is good enough for a game. All of the hunting motion and train-suspension-bogey response mechanics are present. The train is double-suspended (more on that later) with both primary and secondary suspension properly simulated.





The diagram above is the diagram of trains power circuits in braking mode. The basic purpose of this circuit is to convert mechanical energy into heat using the rheostat, smoothly bringing train to a halt.

But that diagram is full of various things that don't have to do with what those arrows mean. Instead, here's a simplified conceptual diagram of braking:


or in more detail




Point 1: this is a self-excited braking circuit. When train is moving, any random thermal noise will cause electric current to rapidly grow in this circuit. In order to prevent voltage from exceeding a dangerous threshold, the four motors (there are four of them) are connected in two parallel groups. This limits braking voltage to well within ~800 volts.

Point 2: stators of motor group 2-4 are connected in series with rotors of motor group 1-3. Stators of motor group 1-3 are connected with rotors of motor group 2-4. This means that whenever one motor group starts producing more or less electric current for some reason, the other group will follow (as they are cross-coupled together).

But... that only works when the electric current is balanced to within about 5% between the two branches (then this circuit acts as a power bridge, with all current flowing through the rheostat with high resistance).


Now... imagine a situation where one of the trains wheels gets jammed, a reductor gear gets jammed or the wheel experiences slip and is mechanically forced to a very low speed (it slips and keeps braking until reaching very low velocity).

Normally, each engine group generates voltage that balances out the other group. This means that difference in voltage between two groups is negligible and all current flows through rheostat. After an engine has suddenly stopped, it is no longer generating voltage and the balance is disrupted: one branch can no longer hold back the electric current generated by the other branch.

The resulting effect is called an 'overturn' - as one engine group overpowers the other, the electric current stops flowing through the rheostat. Instead, it all flows through very low resistance windings of both engines. Suddenly, all energy is effectively short-circuited. This leads to a positive feedback loop in which electric current jumps to thousands of amperes extremely fast.

This electric current starts arcing through the motors, damaging everything in them, risking welding all of the power contacts shut, burning insulation and so on - until a few dozen milliseconds later the overload relay finally moves in place and disengages the power circuit.

The train is protected by three power protection devices: the differential protection (it reacts to difference in electric current between two branches), the fast-acting switch (reacts to excess power draw from third rail) and the overload relay (reacts to excessive currents in the power circuit). Only differential protection and overload relay are acting during braking and both will have issues when excessive electric current passes through them (in some cases, the electric current might be so strong that electromechanical protection devices just don't trigger properly).

So overturn is an effect where all electric current suddenly flows through one engine branch and not the rheostat, causing major damage to the electric circuits. On the diagram in your post, green arrows indicate normal flow of current, while red indicates flow during overturn.





The infrastructure will be simulated and eventually open for exploring (to a great extent, it may be too big to ever completely cover it all. Right now all ventilation shafts/other service objects are marked and visible as you drive by them, but their doors are locked and they lead to nowhere). I've actually reverse engineered electric schematics to typical signalling boxes (which drive the signalling lights) and we've got plenty of engineering data to fully replicate the operation of ARS (train safety & speed regulation system).





We will release modding tools sometime after the games release. There is one thing that might surprise people who are used to making maps in games like Trainz...

As I mentioned earlier, the game's railroad system is stored as parametric railway curves. A railway curve is a set of straight lines, arcs and transition curves (in horizontal plane) and a set of arcs and straights (in vertical plane). The source format using which the 3D curve is built is... effectively same as real construction schematics. You've got to specify either partial or full sets of construction geometry parameters.

For example, making an arc requires specifying track markers of arc start & end, arc length, arc angle, arc bisection and some other parameters. Although the parsing engine will also build arcs given only radius & length, radius & angle or length & angle etc, it will complain to you that you forgot some values.



Eventually we will include some passenger response modelling, but that is a feature for after the game is initially released.

We've announced our game and posted it on greenlight! The links to everything interesting are here: http://subtrans.it/

I'm going to make a post on devblog about how the teaser was made (the train is running in there using physics, though I animated the camera manually)

Great! I'll be sure to vote for it!

Congratulations on the Greenlight campaign and the ridiculously good-looking teaser video. Are you therefore indeed planning to allow players to walk around in the world, not just in the cab, Train Simulator World-style, the way that camera movement suggested?

Yes, absolutely. While many areas will be locked up at first, some members of our team love exploring underground infrastructure and various tunnels and stuff. Luckily, UE4 is great for making anything walking.

I see some comments on Steam that are, too, asking about whole-world exploration and big rail networks complete with depots and station interiors, but you replied that it would be hard to have big levels because of multiplayer.
Are there technical limitations to how train/network simulation is implemented that make big levels hard to sustain even in single-player mode, or does it just come down to how level loading is handled in multiplayer mode (I suppose that maybe the whole level needs to be available at once, causing long loading times)? Or is it something else entirely?

By the way: the teaser and screenshots look (and sound) really nice and they really highlight the graphic quality. After reading your blog and your posts in this thread, I understand that your simulation is much more detailed in terms of train internals than the typical simulator. However, I don't think that shows in the teaser, and Subtransit may come off as yet-another-dumb-subway-simulator.
Yes, I know that the level of detail is described in the description - but my personal experience is that 90% of the people won't read even 10% of what one writes At the same time, I'm not sure of what you could put in the teaser to make it more obvious, and I assume you don't have much to show in terms of game-play yet. I suppose that problem will solve itself as you get closer to a finished product, in the meantime let's just hope people don't dismiss it prematurely.

There are currently a couple technical limitations on making a single huge world:
1) The MP dedicated server has to load the entire game world - every single map (but no textures, no model LODs). Currently it's not clear on how much RAM use and how big loading times that would create.
2) The dedicated server will create physics cells to distribute physics over several processors and to work around floating point precision errors (UE4 runs on floats, though our physics internally runs on doubles). Obviously there's a limit on number of physics cells, which puts a limit on how big a world can be (bigger world requires more physics cells for precision reasons)
3) Each metro line has a fairly large number of trains. Letting server simulate all trains on all lines is pretty intense and puts unnecessary load on the server (almost nobody will interact between two different metro lines, it would make much more sense to put them on different servers).

That being said, it's totally possible to put all metro lines on a single map in singleplayer. But I'm not sure if we want to keep two copies of game world. It's totally a MP issue, in singleplayer we can make levels of any size!

Of course, there are ways to implement networking that are far different to server-takes-charge priority we use, so in the future this might all change.

We decided to go for a pretty teaser (in which btw the train runs on proper physics and all - I wanna make a blog post about that later) because majority of people are going to only check the graphics out really. We've considered putting a fully gameplay teaser as well as some technical teaser, but entirely due to marketing reasons it seemed better to put a fancy teaser instead.

All the ideas that would show off more of gameplay or physics/technical stuff came off as kinda dry and potentially less attractive. I guess the problem can be described as "almost nobody is an expert on these trains".

I was going to suggest that when nobody's watching, you could replace the highly-detailed simulations with very simple ones that are there just to satisfy the signaling code and anything that may depend on having moving trains. But then I realized this would probably be incompatible with certain simulation features you might have in mind, such as each component having a small chance of breaking at any time/under certain circumstances. (the "dumb trains" would not be able to simulate these failures, so everything would run perfectly forever if "nobody's watching")


The metro networks I know have means of switching trains between lines, and it's something that happens regularly (for example, when increasing/decreasing capacity before/after peak hours). I can see some story lines involving that. Of course, you could always unload one line and load another as the train goes from one to another... or maybe the game is already rich enough even without such complex activities, I don't know

All that stuff can be done in the future, potentially, yeah



The trains only travel between lines in some special cases (e.g. when the metro line is new and does not have a dedicated depot, or when there's some sort of an unusual accident). It happens once in a while and there will be missions in singleplayer that involve crossing onto another line, but generally due to logistic reasons all trains start their day already on the metro line.

Ah, this explains it. In Lisbon there are only two (or even just one, I don't know how's the situation right now) active depots, and while part of the rolling stock "sleeps" in stations and line ends, another part (possibly smaller, especially now that it is operating with bare minimum amounts of stock) needs to switch lines frequently. I guess bigger networks with longer lines and higher train frequencies can't afford all the line switcharoo and respective extra traffic.

Could we have any more gifs/screenshots? I'm actually pretty interested in this, and screenies would be pretty cool! (Even if they aren't 100% working!)

Yeah! I've made a new post at the devblog (http://devblog.foxworks.cz/?p=202), there are some short segments there:

These are amazing, and incredibly graphically detailed! *bows down to Black Phoenix

Those look great, as always, and I didn't even notice the brake releasing sequence was at one texture pass before you mentioned it. Also, I really enjoy reading these blog posts.

Since the trailer had the full simulation going on, I understand that sound effects were also being generated at runtime? Based on the few Metrostroi streams I watched and after playing around a bit with some subway simulators, I think the sound quality in Subtransit is way above average.
Just a few days ago I realized there's a whole world dedicated to sound engineering for games and noise generation for engines in cars, motors in trains, etc. - with not much detail available online, most answers come down to "it's super expensive to make".
I understand that engines are recorded at different speeds and then sounds are mixed based on the physics simulation. I guess that in Subtransit, certain things are easier, for example: does having the track shape defined parametrically help with knowing when to add those grinding noises in curves? I think in some games, it's hardcoded/built into the world data: "in this curve, if the train is going at over 50 km/h, play noise". It works, but it's not the full simulation experience we are hoping to waste CPU cycles on!

Based on my experience with recording subway trips (for a environment sound recognition/digital signal processing/machine learning project I'm very very slowly working on), it's basically impossible to get any kind of clean sound once the train starts moving, even with great recording equipment. Then there are big differences between the sound the motors make, and the metal grinding noises, as they are produced vs. how they are perceived inside the cars (with attenuation and all, with modern trains being slightly better at silencing them, or at least certain frequencies). Unlike they do with cars sometimes, you can't really bring a train into a studio and record it there (or can you? ). Perhaps here's a topic for a future devblog post?

I read your post on aerodynamics. If it is hard to model on single-track tunnels, I'm guessing it can only be much more complex in tunnels with two tracks (as I'm most used to). The airflow is probably not as strong, since the air has more places to go when a train moves through (Bernoulli's principle, etc. etc.), and ventilation shafts and other tunnel features might not cause as big of a disturbance. However, it's probably much harder to model since you need to account for an additional possibility: trains going in opposite directions (in different tracks, preferably...). Based on all the shaking and loud impact noises, there are definitely some funny things going on when trains meet

Runtime noise generation at this point is not useful for realtime application. We record our sounds from the real trains, more on this below. The sounds in the trailer are triggered by physics events.



There are many recorded samples of all sorts of sounds (engine noise, movement noise and so on) which are mixed together by many parameters (for example the motor sound consists of many sounds recorded at many different RPM's mixed together in runtime, with additional filters added that respond to physics parameters).




Most definitely gonna write a devblog about this topic, but we record our sounds both on the real moving trains and in the depot (for the sounds of various electric relays etc). We use really nice portable HQ audio recording tools and most sounds can pretty much be recorded off the actual device that produces them (e.g. an electric relay). Some sounds are harder to trigger than others and we didn't get to them just yet (the trains have a control circuit check mode that permits running train circuitry without high voltage).



Our metro systems use only single-track tunnels for ventilation purposes and other reasons. Two-track tunnels exist, but are very rare. But we'll recompute the coefficients for those tunnels too if it'll be of any significance and those tunnels will be on a metro line we're making.

Vent shafts cause enough of a disturbance to feel the train chassis getting a bit of impact - also all of the doors and flaps and other things will suddenly get pulled/pushed by the changing air pressure, making a noise.