The signals are similar to path signals in OpenTTD, if you are familiar with that. (There is nothing like block signals.)
In Distributrains, trains work by reserving a path towards their destination. A train has to wait if the path it tries to reserve overlaps with the reservation of another train. If they see (the front side of) a signal while trying to reserve a path, then they stop reserving there. In essence, signals are used to shorten the path reservations to reduce conflicts.
There are two signal types: One-way Signals can never be passed from the back side, and Back-traversable Signals are ignored from the back side.
The rules are simple, and trains will never crash, but using signals optimally can be difficult. The game has a couple tutorials about this. Active path reservations are always drawn on the tracks, there is a pathfinding visualiser, and an option to draw signal direction arrows on the tracks.
I don't know that you can ignore them, but in my experience (which might be skewed because I'm comfortable with OpenTTD signals) the fact that they're "path-like" signals means that in most circumstances all you really need to do is drag a line of signals down a track in the direction you want trains to go on that track.
I checked using the current version of the itch.io app and I don't see any issues. To be clear, there is only one download, and it is marked as supporting both Windows and Linux:
It contains the following binaries:
Distributrains32 - For 32-bit Linux (x86)
Distributrains64 - For 64-bit Linux (amd64)
Distributrains32.exe - For 32-bit Windows (x86)
Distributrains64.exe - For 64-bit Windows (amd64)
If you are on a supported platform and the download doesn't show up then you might need to talk to itch.io support.
- I'm noticing that the pathfinding sometimes does really weird things. I can figure out how to post screenshots or saves if helpful, but it's stuff like trains taking longer paths, I guess because the best path is blocked by another train, but in a way that's nonsensical because the longer path is basically just going in a big loop before proceeding along the original best path—that is, the new path is strictly worse, there's no apparent reason for the detour. This often makes trains clog up side stations and such, which were admittedly not perfectly designed but never had any reason for many trains to be going through them.
- Maybe this is something you want to leave to players to discover, but a tutorial that gives a little more detail about what different train types are best at and how combining them can be good might be nice. ('players' is me; I'm still figuring this out)
- This feels mean, but I liked the old icons better. Would an option to use them be possible?
Trains will consider longer detours the longer they are stuck. Sometimes the end result is they take a strictly worse loop because the alternative path they come up with ends up also being blocked, so they revert to the original path at some point. They do not remember the past or predict the future, all they want is to reserve path that will lead to the target.
I can change the parameters to make them less eager to take longer detours, but I don't really want to place any hard limits as this will result in them failing to find actually viable alternative paths in many cases. It could perhaps be user configurable.
You can, however, remedy this in two ways. #1 is to fix your congestion issues so your trains do not get stuck and start thinking about nonsensical detours. #2 is to change your track layouts so that those nonsensical detours are just not available to them in the areas where congestion might occur.
I'm not sure if a locomotive use case tutorial belongs inside the game, but I'll look into it. In general, you want trains that are as cheap as possible to run, while having just enough traction and top speed to avoid causing congestion. To make a good choice you need to consider what the weight of the train will be, the speed of other trains on the line, and how often it has to climb a sloped tile.
When engines are combined, they only contribute to traction below their engine top speed, and the speed of the whole train is limited by the lowest max. safe speed. The typical use of combining engines is including a slower engine to help in climbing long slopes. A couple other uses would be including a weak/fast engine to increase the top speed on long flats, or combining electric and combustion engines for traversing partially electrified railways.
You are seeing high resolution icons because of your UI scale setting. If you want to see upscaled low resolution icons instead, you should delete the icons in the "hires" folder.
The problem I think I'm seeing is that they're reserving detours that just lead them back to the same blockage—it's as though they're going "oh boy, clear track!" without regard to the fact that the clear track in question is just a longer route to the same blocked track they're trying to route around. I hope I'm not missing what you meant—my sticking point is that it doesn't seem like there's any "past" or "future" planning required to see that both routes end up at the same bottleneck, and to then prefer the route that's shorter before the bottleneck.
This screenshot has a good example. If one train is in the station, the next will pause at the signal just before the station, then embark upon the much longer loop, even though the end result is that the train is stuck waiting for the same blockage to clear even farther from the station. Just after building this, I even saw the second train wait before the station, and when the train occupying the station left, going around the entire loop rather than just go into the soon-to-be-empty station. I think it's hard to avoid this behavior when I have multiple stations coming off a main line. I recognize that this is a nontrivial problem which you've thought about a lot more than I have, but isn't there any way the pathfinding can recognize when an alternate route doesn't actually help with a given obstacle?
Mainly, it just isn't generally true that we should always want trains to avoid longer paths to the same blocked track like in your idea. Given a layout like you have in your screenshot, it is entirely reasonable to *want* the second train to use the loop as a buffer if there is a blockage: If the second train is long, then taking the loop will free up track behind it, which might be important to avoiding jams in the rest of your network. I would not be content to add heuristics that take away opportunities like this.
I am, however, working on an option to modify how a train considers detours when it is stuck in traffic. I believe this will help for your playstyle.
It does, but you need a power that would have been relatively powerful for the era. The computer I tested it on has an AMD Athlon 64 X2 CPU and an ATI Radeon HD 4670 GPU.
I'm a fan of your games, but I have to point out that Distributrains has quite a few grammatical errors during the tutorial scenarios. Nothing major, but it was very confusing to read "you can to" and try to understand what does that mean. Text in this game is a lot more important than your previous, and I suggest looking over it again or asking a native english speaker to help out. Other than that, I'm loving the game and I get excited every update that comes in on my inbox.
It reminds me of Transport Tycoon, everything looks so cool! I love these kinds of games, I'm going to have to play them. It looks amazing, congratulations to the developers of this gem!
This is an awesome middle ground between OpenTTD's janky half-baked systems and Factorio's life-consuming complexity. I've been wanting to play exactly this game for a while. And I appreciate how quickly you implemented some of my suggestions on Steam.
If I could get away with a few more- It would be nice to have a tooltip (or just an explanation) of what exactly the tradeoff I'm making is when I set lumber camp tree preservation, and it would be nice to have a visual of the max range of farms and lumber camps when placing them. for optimization.
And a question: are the rain/wind/sun indicators in the lower right meant to be the same scale, i.e. if rain is 4.0-6.2 and sun is 3.0 to 5.0, then generally dams are better on this map? I can't be sure but I just generated a few maps and it seems like sun is generally higher-valued and more consistent? Is the tradeoff that solar requires semiconductors, or maybe just is worse without upgrades? I'm kind of confused about how dams work in general; it's not clear what a kilowatt-hour is in the context of this game's timescale.
The tradeoff with the tree preservation setting is lower values are more productive but lead to deforestation. The deal is you can choose to manage the forest sustainably or thin it out and then move the camp.
Wind and sun are on the same scale in that a fully upgraded solar farm has about the same output as a fully upgraded wind farm if their weather numbers are the same. Without upgrades, a wind farm is about 50% better.
Rain is a different matter. Dams are meant to be used as batteries for other power plants. When only powered by rain, they can be good early game, but building only dams is generally a poor choice.
The KWh unit is calculated under the assumption that a cycle is a month. This means with 1 MWh you can run a 1 MW engine for roughly one real second. Maybe there's a better way to present this information, but it's just the amount of energy stored in the dam.
In map generation, wind is likely to be lower than sun and rain, while sun and rain are inversely correlated. You are meant to choose your power plants based on a several factors including the climate, your resources, the terrain, and what cards appear in the shop.
Thanks. I think my issue was that I couldn't understand why I would avoid deforestation...
Maybe it's silly, but it's weird to have a unit of resource that doesn't clearly correspond to any of the units it's consumed in, so maybe there should be a way to see a train's consumption in MWh/cycle or something, just so that number has any frame of reference. Or maybe I'll just get used to it.
edit: another suggestion with logging camps... it would be cool if trains could automatically recognize a "moved" logging camp as the same one, so that I don't have to find each train that was going to the old location and update its orders.
I added a MWh/cycle tooltip in the train build menu, and will continue working on improvements. But for now I encourage you to see the added management effort as a cost of deforestation.
This looks 100% up my alley and the music absolutely slaps, but I really wish you would provide some kind of demo or trial! I know it's not always easy with these kinds of games, but I think it would really help sales/exposure.
./Distributrains64: error while loading shared libraries: libsoundio-ca.so.2: cannot open shared object file: No such file or directory
Checking the linux64 (and linux32) folders, there doesn’t appear to be a libsoundio-ca.so file in either (though the 32bit and 64bit dlls were present)
Running with wine works perfectly fine, however. Fun game :)
It does not, sorry. The itch.io version comes with the game files and executables for 32- and 64-bit Windows and Linux. It has all the same features (except steam integration), will receive the same amount of support, and you can play multiplayer with Steam users.
← Return to game
Comments
Log in with itch.io to leave a comment.
Question before buying, how complex is the signal system?
The signals are similar to path signals in OpenTTD, if you are familiar with that. (There is nothing like block signals.)
In Distributrains, trains work by reserving a path towards their destination. A train has to wait if the path it tries to reserve overlaps with the reservation of another train. If they see (the front side of) a signal while trying to reserve a path, then they stop reserving there. In essence, signals are used to shorten the path reservations to reduce conflicts.
There are two signal types: One-way Signals can never be passed from the back side, and Back-traversable Signals are ignored from the back side.
The rules are simple, and trains will never crash, but using signals optimally can be difficult. The game has a couple tutorials about this. Active path reservations are always drawn on the tracks, there is a pathfinding visualiser, and an option to draw signal direction arrows on the tracks.
I am barely familiar with the signals in OpenTTD, and hearing that is not filling me with confidence. But it seems that signals can be ignored.
I have never actually tried completing a run without signals, I would guess it's possible but probably difficult, heh
I don't know that you can ignore them, but in my experience (which might be skewed because I'm comfortable with OpenTTD signals) the fact that they're "path-like" signals means that in most circumstances all you really need to do is drag a line of signals down a track in the direction you want trains to go on that track.
The itch desktop client doesn't think there is a valid download option for Linux.
I checked using the current version of the itch.io app and I don't see any issues. To be clear, there is only one download, and it is marked as supporting both Windows and Linux:
It contains the following binaries:
If you are on a supported platform and the download doesn't show up then you might need to talk to itch.io support.
I have a few more thoughts/suggestions:
- I'm noticing that the pathfinding sometimes does really weird things. I can figure out how to post screenshots or saves if helpful, but it's stuff like trains taking longer paths, I guess because the best path is blocked by another train, but in a way that's nonsensical because the longer path is basically just going in a big loop before proceeding along the original best path—that is, the new path is strictly worse, there's no apparent reason for the detour. This often makes trains clog up side stations and such, which were admittedly not perfectly designed but never had any reason for many trains to be going through them.
- Maybe this is something you want to leave to players to discover, but a tutorial that gives a little more detail about what different train types are best at and how combining them can be good might be nice. ('players' is me; I'm still figuring this out)
- This feels mean, but I liked the old icons better. Would an option to use them be possible?
Trains will consider longer detours the longer they are stuck. Sometimes the end result is they take a strictly worse loop because the alternative path they come up with ends up also being blocked, so they revert to the original path at some point. They do not remember the past or predict the future, all they want is to reserve path that will lead to the target.
I can change the parameters to make them less eager to take longer detours, but I don't really want to place any hard limits as this will result in them failing to find actually viable alternative paths in many cases. It could perhaps be user configurable.
You can, however, remedy this in two ways. #1 is to fix your congestion issues so your trains do not get stuck and start thinking about nonsensical detours. #2 is to change your track layouts so that those nonsensical detours are just not available to them in the areas where congestion might occur.
I'm not sure if a locomotive use case tutorial belongs inside the game, but I'll look into it. In general, you want trains that are as cheap as possible to run, while having just enough traction and top speed to avoid causing congestion. To make a good choice you need to consider what the weight of the train will be, the speed of other trains on the line, and how often it has to climb a sloped tile.
When engines are combined, they only contribute to traction below their engine top speed, and the speed of the whole train is limited by the lowest max. safe speed. The typical use of combining engines is including a slower engine to help in climbing long slopes. A couple other uses would be including a weak/fast engine to increase the top speed on long flats, or combining electric and combustion engines for traversing partially electrified railways.
You are seeing high resolution icons because of your UI scale setting. If you want to see upscaled low resolution icons instead, you should delete the icons in the "hires" folder.
Thanks for the thorough response.
The problem I think I'm seeing is that they're reserving detours that just lead them back to the same blockage—it's as though they're going "oh boy, clear track!" without regard to the fact that the clear track in question is just a longer route to the same blocked track they're trying to route around. I hope I'm not missing what you meant—my sticking point is that it doesn't seem like there's any "past" or "future" planning required to see that both routes end up at the same bottleneck, and to then prefer the route that's shorter before the bottleneck.
Mainly, it just isn't generally true that we should always want trains to avoid longer paths to the same blocked track like in your idea. Given a layout like you have in your screenshot, it is entirely reasonable to *want* the second train to use the loop as a buffer if there is a blockage: If the second train is long, then taking the loop will free up track behind it, which might be important to avoiding jams in the rest of your network. I would not be content to add heuristics that take away opportunities like this.
I am, however, working on an option to modify how a train considers detours when it is stuck in traffic. I believe this will help for your playstyle.
Does the game work on Windows XP?
It does, but you need a power that would have been relatively powerful for the era. The computer I tested it on has an AMD Athlon 64 X2 CPU and an ATI Radeon HD 4670 GPU.
My Nvidia GeForce GT710 is better than ATI Radeon HD 4670.
My Intel Pentium E2180 processor is comparable in performance to an AMD Athlon 64 X2 Dual Core 4000+.
I'm waiting for a demo version of the game.
I'm a fan of your games, but I have to point out that Distributrains has quite a few grammatical errors during the tutorial scenarios. Nothing major, but it was very confusing to read "you can to" and try to understand what does that mean. Text in this game is a lot more important than your previous, and I suggest looking over it again or asking a native english speaker to help out. Other than that, I'm loving the game and I get excited every update that comes in on my inbox.
Will this come to android?
It will not come to android, sorry.
hi! do you plan on posting the OST separately? my boyfriend started playing the game a few days ago and I'm having the best naps to the music there
created account there just to ask you this :')
I have uploaded the files for you here https://oddwarg.com/Music/Distributrains%20OST/
I will probably put it on bandcamp in the future
It reminds me of Transport Tycoon, everything looks so cool! I love these kinds of games, I'm going to have to play them. It looks amazing, congratulations to the developers of this gem!
Skugg plushie when
This is an awesome middle ground between OpenTTD's janky half-baked systems and Factorio's life-consuming complexity. I've been wanting to play exactly this game for a while. And I appreciate how quickly you implemented some of my suggestions on Steam.
If I could get away with a few more- It would be nice to have a tooltip (or just an explanation) of what exactly the tradeoff I'm making is when I set lumber camp tree preservation, and it would be nice to have a visual of the max range of farms and lumber camps when placing them. for optimization.
Oh, and a tooltip with production chains for resources so a newbie can see what e.g. a plastic plant will require before buying a card.
And a question: are the rain/wind/sun indicators in the lower right meant to be the same scale, i.e. if rain is 4.0-6.2 and sun is 3.0 to 5.0, then generally dams are better on this map? I can't be sure but I just generated a few maps and it seems like sun is generally higher-valued and more consistent? Is the tradeoff that solar requires semiconductors, or maybe just is worse without upgrades? I'm kind of confused about how dams work in general; it's not clear what a kilowatt-hour is in the context of this game's timescale.
The tradeoff with the tree preservation setting is lower values are more productive but lead to deforestation. The deal is you can choose to manage the forest sustainably or thin it out and then move the camp.
Wind and sun are on the same scale in that a fully upgraded solar farm has about the same output as a fully upgraded wind farm if their weather numbers are the same. Without upgrades, a wind farm is about 50% better.
Rain is a different matter. Dams are meant to be used as batteries for other power plants. When only powered by rain, they can be good early game, but building only dams is generally a poor choice.
The KWh unit is calculated under the assumption that a cycle is a month. This means with 1 MWh you can run a 1 MW engine for roughly one real second. Maybe there's a better way to present this information, but it's just the amount of energy stored in the dam.
In map generation, wind is likely to be lower than sun and rain, while sun and rain are inversely correlated. You are meant to choose your power plants based on a several factors including the climate, your resources, the terrain, and what cards appear in the shop.
Thanks. I think my issue was that I couldn't understand why I would avoid deforestation...
Maybe it's silly, but it's weird to have a unit of resource that doesn't clearly correspond to any of the units it's consumed in, so maybe there should be a way to see a train's consumption in MWh/cycle or something, just so that number has any frame of reference. Or maybe I'll just get used to it.
edit: another suggestion with logging camps... it would be cool if trains could automatically recognize a "moved" logging camp as the same one, so that I don't have to find each train that was going to the old location and update its orders.
I added a MWh/cycle tooltip in the train build menu, and will continue working on improvements. But for now I encourage you to see the added management effort as a cost of deforestation.
This looks 100% up my alley and the music absolutely slaps, but I really wish you would provide some kind of demo or trial! I know it's not always easy with these kinds of games, but I think it would really help sales/exposure.
I will likely develop a demo version at some point, yes.
Launching on Linux I got the following error:
./Distributrains64: error while loading shared libraries: libsoundio-ca.so.2: cannot open shared object file: No such file or directory
Checking the linux64 (and linux32) folders, there doesn’t appear to be a libsoundio-ca.so file in either (though the 32bit and 64bit dlls were present)
Running with wine works perfectly fine, however. Fun game :)
Thanks for the report! I don't know what possessed me to make this mistake, but it's fixed now.
It looks like rollarcoaster tycoon but I don't have money for this
Does a purchase here come with a steam key?
It does not, sorry. The itch.io version comes with the game files and executables for 32- and 64-bit Windows and Linux. It has all the same features (except steam integration), will receive the same amount of support, and you can play multiplayer with Steam users.
Sounds fair to me, thanks!