I need to prioritize things a bit more, otherwise there will be too many started, but unfinished projects.
Top priority should have now the Android Coloring App for Kids. I want to have it published within 1-2 months with at least 50 coloring templates ready.
Sharing top priority is version 1 of the Opensource Games Library including making advertisement about it, which I want to have done within one month.
There is the Hale project, a Java RPG, which I want to have in a state that there is a Windows installer and it's also running on Linux and the most obvious current glitches are removed. Would be nice to have this done within the next 3-4 months.
And there is the FreeRails project which needs design, further rewrite of the model core and a new GUI which would be nice to have in 5-6 months.
I'm tempted to do a bit here and a bit there, especially when I'm frustrated with one thing, but that doesn't really finish anything, so I should stop doing that and instead focus on a single project at a time.
Gathering information about and improving open source games.
Friday, October 5, 2018
Thursday, October 4, 2018
FreeRails: Are we on the right track?
Track management is among the most often performed actions within any railroad simulation. It's also very close to the heart of the programming and design of any railroad simulation. Lately, I was interested in getting a better overview about how the track management in FreeRails work as well as possibly streamlining it and documenting it properly.
The map consists of an rectangular grid consisting of square-sized tiles. Each tile (except those at the border) have exactly eight neighbors which can be uniquely identified by compass points (north, north-east, ...) given the current center tile or by grid positions (row, column).
The total track on the map consists of many track pieces, where each piece connects two neighboring tiles (diagonal connections have ~1.41 (square-root of 2) times the length of horizontal or vertical connections).
Path finding of the trains works on a graph where the tiles are nodes and the track pieces connecting neighboring tiles are the edges.
Building and removing track works by adding and removing track pieces. In particular, the planning of a longer piece of newly built track is done by path finding again.
The track itself is visualized by rendering each tile according to its track configuration. The track configuration is an 8 bit value indicating if there is a connecting to one of the 8 neighbors from the current tile. See the attached image for some examples.
The track configurations are not independent from each other. For every connection on a tile towards a neighboring tile, this neighboring tile must also have a connection to this tile. This invariant must be obeyed by not allowing to change track configurations directly, but only by allowing adding or removing of track pieces at a time.
Track pieces have no direction, any train can go on them both ways. However, a train can change direction at every tile at most by 90 degree, effectively inducing some kind of directionality.
Track pieces can be single tracked or double tracked. There can only be one running train on each track piece (and trains have a certain extent, also measured in track pieces). However, stopped trains do not count as obstacles.
The track configuration of a tile is sufficient to draw it uniquely on the tile. Not all possible 8 bit values are valid.
Bridges and stations are a special case. Stations have a orientation and only allow track parallel to their orientation. Bridges span a water tile (other track cannot be put on water) and consist of two track pieces resulting in a parallel configuration.
That should be all for now. There is of course more (like trains). FreeRails currently follows the concept outlined above quite well. For some reason the track configuration is a 9 bit value (center part is also encoded and used to indicate no track at all) where I think that 8 bits would be sufficient and it's possible to change track configurations directly, whereas it's better to only change track pieces and change the track configuration only at a single place in the model.
Will be continued...
The map consists of an rectangular grid consisting of square-sized tiles. Each tile (except those at the border) have exactly eight neighbors which can be uniquely identified by compass points (north, north-east, ...) given the current center tile or by grid positions (row, column).
The total track on the map consists of many track pieces, where each piece connects two neighboring tiles (diagonal connections have ~1.41 (square-root of 2) times the length of horizontal or vertical connections).
Path finding of the trains works on a graph where the tiles are nodes and the track pieces connecting neighboring tiles are the edges.
Building and removing track works by adding and removing track pieces. In particular, the planning of a longer piece of newly built track is done by path finding again.
The track itself is visualized by rendering each tile according to its track configuration. The track configuration is an 8 bit value indicating if there is a connecting to one of the 8 neighbors from the current tile. See the attached image for some examples.
 |
| Track configuration encoded as 8 bit value |
Track pieces have no direction, any train can go on them both ways. However, a train can change direction at every tile at most by 90 degree, effectively inducing some kind of directionality.
Track pieces can be single tracked or double tracked. There can only be one running train on each track piece (and trains have a certain extent, also measured in track pieces). However, stopped trains do not count as obstacles.
The track configuration of a tile is sufficient to draw it uniquely on the tile. Not all possible 8 bit values are valid.
Bridges and stations are a special case. Stations have a orientation and only allow track parallel to their orientation. Bridges span a water tile (other track cannot be put on water) and consist of two track pieces resulting in a parallel configuration.
That should be all for now. There is of course more (like trains). FreeRails currently follows the concept outlined above quite well. For some reason the track configuration is a 9 bit value (center part is also encoded and used to indicate no track at all) where I think that 8 bits would be sufficient and it's possible to change track configurations directly, whereas it's better to only change track pieces and change the track configuration only at a single place in the model.
Will be continued...
Subscribe to:
Posts (Atom)