"Roadmap"

This is the sort-of "roadmap" describing our next steps. They are not necessarily ordered by priority.

Binary distribution

• Build and ship AppImages for Linux (xenial and newer)
  • first set up a CI workflow for Travis running on xenial to retain compatibility with almost all newer distros
    • rework the CMake installation stuff to automatically create an FHS-like layout (which is definitely cleaner than the current system)
    • add the necessary bits to the code to support the new directory layout
  • extend that to build AppImages
  • integrate that then into https://github.com/redeclipse-legacy/release
• Build and ship Windows installers quickly
  • first set up a CI workflow based on MinGW on Travis CI (we do not have native Windows machines available, and likely don't need any; Red Eclipse can be cross-compiled just fine)
  • then, extend this to build tarballs
  • integrate that then into https://github.com/redeclipse-legacy/release
  • build some more convenient distribution, e.g., NSIS based installers, ideally with a built-in updater (not an urgent task)
• Build and ship macOS binaries (e.g., as .dmg, or maybe as a tarball for the beginning time)
  • first set up a CI workflow using the native macOS integration in Travis CI
  • then, extend this to build a tarball
  • integrate that then into https://github.com/redeclipse-legacy/release
  • consider building a .dmg or plain .app, ideally with a built-in updater (not an urgent task)

Distribution of data

We have to re-engineer how to distribute the game data. In the AppImage, for example, we can easily ship the data bundled with the executables, as we have binary delta updating available as a feature of AppImages, keeping the overhead of updates as low as possible. For macOS and Windows, there is an existing shell script based updater which suffers from very tight integration into GitHub and some CI service (requiring a very specific and fragile setup, unable to test locally).

It might make sense to avoid using git and anything GitHub/CI bound, as these are difficult to maintain. An alternative could be to simply put the data on an rsync server, and have clients use rsync and maybe even a small GUI to perform updates.

For the beginning, shipping the data as part of the installation should be fine, as we just remain compatible with 1.6.

Menu changes

The current menu is a bit overwhelming for beginners, and lacks docs where needed. We should re-engineer the menu to be more newcomer friendly. There should be documentation for everything (ideally in-game with tooltips, and maybe some guide on the Wiki or in a separate docs repository).

Documentation

We should set up a Sphinx-based online documentation of Red Eclipse, featuring the most important elements of gameplay, how to set up a server (including example configs for special ones, e.g., racing servers, edit, etc.), parkour (including the names of the moves; lingo is important, it makes it easier for people to discuss the topic), etc.

A wiki appears to be easier at first, however most wikis aren't sustainable, the content is usually not published publicly (to have "backups" for example), and the textual and markup quality of serious documentation systems is a lot higher. Learning the language (reST) isn't considered to be a big deal for people eager to help. Worst case, people can convert their texts from Markdown with Pandoc.

Parkour tutorial

Parkour (the very unique movement in Red Eclipse Legacy) is the greatest feature of the entire game. However, many newcomers don't immediately see that there is such a huge amount of possibilities to move through the maps with such a high pace.

We should incorporate the parkour tutorial map "Tuto", made by @bonifarz and provided as free content on GitHub, into the game, providing an option in the main menu. Also, I could imagine offering a special server browser (maybe just with a suitable search filter) allowing users to visit any of the online tutorial servers.

It is important to make the online training a first-class citizen next to offline training. "Tuto" is great, but being advised and guided by an experienced player on a server is most likely more helpful than plain offline practice. Therefore, offering both online and offline training is a good idea.