FreeRails: Back to the drawing board

This is a bit technical post.

Now is the time to go back to the drawing board, write down the existing design and even change it. One such issue is the overall design of the client/server framework. Looking at what is there and what is regarded as modern design I came up with this proposal.

Schematic of the proposed Client/Server design in FreeRails

The client is basically a Model-View-Presenter scheme with the View being very passive and easy to change if for example and Android or Web port is attempted. The presentation logic is in the presenter which updates the view and reacts on user input. The presenter/controller is a big black box here and needs to be detailed later. The client also contains a full copy of the model/game world, making him a thick client. He acts upon changes in the model and proposes changes to it. However, the model just reroutes these proposed changes to the server.

The server checks the proposed change for applicability and either accepts it or rejects it. It then applies the change to itself and sends it to all clients so they can apply it to their copy of the model and the user will see them. It follows that this way all the client models will be in sync with the server model, although they may lag behind. To make sure they don't miss anything, the broadcasted, accepted changes will be enumerated or similar.

One can see nicely, how the information flows in a circle, from the view (user input) through presenter, local client model, server model, local client model again, presenter again and finally a change is displayed.

I think this requires the lowest amount of coding effort while still delivering robust performance and good separation of concern and modularity.

P.S. For drawing the design diagrams I use draw.io which is an excellent tool and works for me like a charm.

FreeRails: Replacement of world differences object

In the last week I could refactor the current code in such a way that generic differences of world objects and actions that update world objects with these differences aren't needed anymore. I replaced the uses of these powerful but also very complex objects by a series of more primitive updates on the world. This also allowed me to remove code that tracked changes between nested lists (needed to represent differences of the world object).

I could reduce the size of the code base considerably without changing the functionality except for a small bit on the client side when displaying user messages which can be repaired later.

This step should make it easier to understand and advancing the code. Immediate next step will be some software design of the server-client relation and of the user interface as an initial step of rebuilding the client.

FreeRails: Next step, rebuilding the client

The refactoring of the code is coming to an end. I made some pages of notes on how the code works. The next step seems to be clear: the rebuilding of the client using JavaFX and in the course of this simplifying the server and client interaction if possible while retaining all the features.

This should result in a simpler, easier to modify code base and also more modern look at the same time. However, it will also take some time and meanwhile it will look from the outside as if not much progress is happening. This will surely limit the interest until this task is finished.

On the other side, someone else posted about the project on Reddit and I posted about it on the FreeGameDev and Java Gaming forums. This brought considerable interest and visitors on the project page. It's a good start.