Skip to content

Long term projects

Jump to bottom Edit New page
James Robertson edited this page Jan 16, 2022 · 7 revisions

This page describes a few projects that the devs would like to do. There's no warranty regarding actual implementation, but contributions towards these goals are more than welcome.

🎮 Client redesign

The user interface of the client needs a complete overhaul to look better and be more intuitive. The most urgent part is probably the game page, where one spends most of the time. Next, the start, network, pregame, save and scenario pages should be considered.

Sample issues:

🪖 New ruleset features

There is an endless stream of new requests to make the game more flexible and relying less on hard-coded defaults.

Sample issues:

🗺️ Flexible tilesets

The format in which tilesets are written was apparently designed along with the tilesets themselves, resulting in very cumbersome behaviors and terrible implementation. Based on the experience gained in the Vectron Project and the related feature requests, a generic format should be developed that would use unified semantics between all layers and allow for complicated combinations. The first step will be to extract a set of concepts that can be used to select tiles, generalizing the existing matching logic for terrains and extras. They would then be "tested" by using them to rephrase the existing code. The complete generalization will likely follow naturally.

Sample issues:

⚡ More flexible network protocol

Communication between the client and the server uses a tightly packed binary protocol designed to limit data usage as much as possible. This was a requirement when Freeciv was initially written but, today, the widespread availability of fast Internet connections renders it obsolete. The nature of the protocol also makes it difficult to expand: other than for minimal changes, a new version of both the client and server is often required. In addition, using the protocol with reverse proxies requires an external program.

The envisioned network protocol would be based on Web standards: WebSocket would be used to exchange messages consisting of JSON documents. Depending on the libraries used (likely Qt WebSocket), transparent WS compression or per-message compression would be used to keep bandwidth usage under control. JSON should provide much greater flexibility than the current binary packets, making additions trivial as long as they can be ignored on the receiving end and waiving many current hard-coded limits.

Sample issues:

Research

  • RapidJSON, a C++ JSON library
  • FlatBuffers, a multilanguage forward-compatible binary serialization library

Reproducing the delta protocol appears to be a difficult part.

Add a custom footer
Add a custom sidebar
Clone this wiki locally