Priorities

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.

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.

Track configuration encoded as 8 bit value

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...

Milestone 1.0 for the opensourcegames list created

47 issues still to solve and then everything is ready for going public (really advertising it as something of a usable, real thing).

Check the progress at: https://github.com/Trilarion/opensourcegames/milestone/1

FreeRails: Integrated CVS, SVN and Git history from 2000-2017

Typically, there are lots of warnings of changing the history of Git repositories after they were already pushed to the public, but I think that this is one of the typical exceptions from this rule.

After starting with FreeRails I learned a lot about converting CVS and SVN repositories to Git and about using advanced Git history editing commands like git replace or git filter-branch. Therefore I could really include the history of the FreeRails 1&2&3 and Railz 1&2 projects in a single Git repository.

On the other hand, although there are three forks on Github, there has not been done any work on them yet. The chances that somebody did do something and gets into trouble now is rather very slim. However, in this case, I'd be happy to assist. Nothing is lost. It's just a matter of chaining sufficiently many git commands.

Civil: Integrated CVS history from 2000-2004

The project has not progressed much lately but at least I managed to convert the original CVS code repository containing all the development work of 2000-2004 into the Git format and then I could persuade the existing Git repository to prepend these old code changes. Like everything related to Git it wasn't straightforward (conflicts where none should be) but worked in the end.

That brings the project to a whopping 1600 commits since the year 2000. A read-only copy of the CVS converted to Git has also been put on Gitlab.

FreeRails: Next programming steps

I finished quite some substantial changes under the hood, but I'm far from finished. It left me a bit exhausted mentally. Getting your head to solve complex puzzles in your free time is rewarding but also somewhat tiring. That's why I'm currently looking for some easier tasks as well as some planning tasks before returning to the inner workings.

Possible tasks include

• Go through all locations in the code marked TODO and work on the easier ones.
• Make some hard-coded properties of the game model like the economic climates (recession, moderate, boom) or the game rules (can connect to other railroads) serializable and then load their default state from a file when a scenario is loaded
• Go through the code (especially the moves, the move generators and the handler) and identify code that does game logic and move it to the model.
• Add to the design document details of the planned client-server interaction.
• Describe the game model in the design document.

 So, that's what I will do now before starting some major rebuilding like

• Moving Activities from the world to the Trains where they belong
• Replacing CompositeMoves with single step comprehensive Moves and removing undo on the moves (we don't undo anymore)
• Create a Player specific World view, so that the player doesn't always have to specify his Player object (alternatively, store your Player object with your credentials in a context, that then is stored next to the world)

which are all (among others) prerequisites for creating a new and modern looking client.

FreeRails: Still under the hood

Progress was a bit slower in the last couple of months. Time for an update. Work is done mainly under the hood working on the model and the model updates in order to make it simpler and more resilient. The aim is to fully understand the game model, make it error free and easy to maintain and extend. A side effect is unified loading/saving of scenarios and savegames.

Only after this essential work has been finished, one can think about adding a new chassis (client interface). As a reminder, the latest dev progress is shown here.

Dynamic table is online

A dynamic table showing all entries of the open source game database, is online. One can sort the columns as well as limit the number of rows by using a search field.

I also converted a lot of svn/cvs repositories to git lately and put them on Github/Gitlab.com.

Dynamic table showing open source game entries

400 entries in the OS games collections

There are now 400 entries in the collection of open source games on Github.

Also I started creating a dynamic HTML table using Vanilla-Datatables as well as checking the source repositories and converting some sources (cvs, svn, sources only as snapshots in downloads) to git.

All git source repositories can also be cloned and updated automatically. Currently 180 git based repositories requiring 40 GB disc space can be archived with a single click.

Civil: Slow at the moment

The progress of the rescue attempt is a bit slow lately, five months passed without any update to the code base. Reasons might include:

• I'm rather busy with other (more interesting) projects
• The project is in a dynamically typed language (Python) instead of a statically typed language (like Java). This makes refactoring much more difficult. Also dependencies between different section of the code are more difficult to understand. This makes the next task: understand the code base more difficult than really necessary. I'm curious how large and complex Python projects get maintained actually.

However, I think it's fine if it goes slower. The current state is on Github for all to see and continue.