# Tomatenquark roadmap

This pad discusses changes targeted after the initial Steam release.

## Milestones (T1)

- Introductionary content
- Build System
- Refactoring I
- ~~Package Manager~~
- `libtomatenquark`

-----------

### Introductionary content

We should create some introduction material for new players. This includes both the website and in-game documentation. Currently onboarding for new players into the game is horrible. Improve on that!

### Build system

The project should establish a build system that is:

- easy to set up
- fast and reproducible
- removes binary dependencies from the git repository
- allows for adding additional dependencies

Why? Currently there are three different build systems (XCode, VSProject, Make). If possible these should be simplified.

Hard requirements:

- needs to run seamlessly on all platforms
- should provide working binaries without effort
- should support our current dependencies out of the box / with little effort
- needs to provide support for XCode, as the XCode project is required to ship on OSX (signing)

List of dependencies:

- sdl2
- zlib
- `enet`

Possible candidates are:

- [Conan](https://conan.io/)
- [Bazel](https://www.bazel.build/)
- ~~[vcpkg](https://github.com/microsoft/vcpkg)~~

| Build system | Supported platforms | Supported dependencies | XCode support |
| ------------ | ------------------- | -- | - |
| conan | Windows, OSX, Linux | sdl2 (community), zlib (community), enet (community) | yes via generators |
| bazel | Windows, OSX, Linux | sdl2, zlib | yes via plugin |
| vcpkg | Windows, OSX, Linux | sdl2, zlib, enet | no |

### Refactoring I

Obviously some refactoring can't harm sauer. Here is a list of things that definitely should be done:

- replace all hard-coded paths with variable ones
- the logo should be scalable as SVG in the game (any display size)
- replace custom crafted cryptographic algorithm (authkeys) with [ECDSA](https://www.openssl.org/docs/man1.0.2/man3/ecdsa.html) (OpenSSL)
- compile a list of custom implemented data structures and algorithms that could be replaced using C++ standard library

#### Dependencies:

- Build system
- Support for OpenSSL (or any other fitting SSL implementation)

### Package Manager

We want a modular content system. In essence this should provide for:

- a `require` command. Using this in your `map.cfg` will load the texture pack / sound pack / model pack defined in your require
- a `depends` command. Using this in your `package.cfg` will define dependencies

This could be done using the `addzip` command to load bundles into the game.
Once implemented we could start repackaging our content to fit the new package management. This significantly reduces bundle shipping size. It also has neat applications in the future, e.g:

- ship prefabs
- ship gamemodes
- (...)

For some inspiration we can have a look at [Lumberyard's Asset Bundler](https://docs.aws.amazon.com/lumberyard/latest/userguide/asset-bundler-intro.html) as well as [Steam Workshop](https://partner.steamgames.com/doc/features/workshop).

#### Dependencies

- Build system

See [Asset package manager](https://hackmd.io/kAXTMtswRsug9mXhL4cHvQ?sync=&type=) notes.

### `libtomatenquark`

Create a `libtomatenquark` library containing core logic of the game (mostly data types) and refactor code to use this.

Why is this so immensly useful?
Once done, we can ship `libtomatenquark` as a standalone. This means anyone can write a custom server in a language they favour, e.g `go`, `rust` or `node.js`.

A end result should be some competition about implementations of a nice server (and master), resulting in a standalone server.

#### Dependencies

- Build system

-----------

## What's to come after this roadmap? (T2)

The list in `T1` is a sizeable amount of work for the next 4 releases of `Tomatenquark`. Until then the following is expected:

- the community has compiled a list of issues / bugs / feature wishes they would like to see
- we have compiled a list of refactorings for `Refactoring II`

The flexibility that we win by implementing the milestones in `T1` will allow to plan differently in the future. We should have a discussion / prioritize the tickets that come next. Some fundamental issues that come to my mind are:

- Deprecate the old master server (see `libtomatenquark`)
- Deprecate the old server (see `libtomatenquark`)
- Replace CubeScript with a language that has good ecosystem
- Replace custom UI framework with [UltraLight](https://ultralig.ht/)

None of these items will be done trivially. It makes sense to execute them step by step, in sizeable amounts of work. The core contributors should decide on a list of tasks they want / are able to complete for the next release.