Compatibility

Inter-module compatibility

Unvanquished has many software components: engine binaries, based on the Daemon repository (client and server); gamelogic binaries, based on the Unvanquished repository (cgame and sgame); and various other files shipped in DPKs, which may be used by any of the binaries. Currently, all components are on a single release cycle. A given user normally has only one version of the client installed, but different servers may distribute differing versions of the other components via the auto-download mechanism. This means many different combinations of versions of the components are possible. It can be difficult to reason about which combinations will work correctly, and even which combinations ought to be allowed.

In the rest of this article, "Unvanquished" refers to the eponymous Git repository, not the game.

Desired use cases

Use cases we want to support

• Develop on next-release branch (e.g. 0.52.0/sync) of all repos (Daemon, Unvanquished)
• Develop on master branch of all repos
• Build client from latest master and connect to latest-release servers
  We should be able to play with everyone on a client with the latest bug fixes.
• Build server from latest master and host with latest-release DPKs
  Likewise with a server.
• Host a server with gamelogic and assets build from latest master.
• Develop Unvanquished on master, using latest-release DPKs
  Development for simple cases should be accessible, not requiring -pakpath flags etc. Compatibility with the latest-release unvanquished DPK doesn't need to be perfect; it's OK if there are a few warnings or slightly messed up things in the UI. But it should be usable for basic experimentation.

Use cases we don't really care about

• Using engine of version N or above with gamelogic of version N-1 or older (this implies that a new release will break all currently existing games or mods when it happens)
• Keeping libengine (the part of engine which is needed by both engine and gamelogic) API stable (i.e. prototypes and structures may be moved from a header to another without notice)
• Documenting engine or libengine API or ABI breakages
• Using cgame and sgame built from different commits.
• Asset development with latest-release gamelogic.

Per-repository guidance

Dæmon engine code

Adding, modifying, or removing an IPC call must be done on the next-release branch. Likewise for any changes to serialization procedures or structs passed through IPC.

When developing Daemon master, you need to keep in mind compatibility with both the latest release and the current master of the gamelogic.

Unvanquished game code

Try to keep the submodule pointer to Daemon at a commits which is compatible with the Unvanquished commit containing them. We want to get a harmonious set of components when we do a recursive checkout of some Unvanquished commit.

Changing the playerState_t netcode is acceptable because the netcode table is stored in the gamelogic and we recommend always building cgame and sgame together.

It's OK to put gameplay changes on master.

Unvanquished game data

Changes to the master branch should be compatible with the master gamelogic, but need not be compatible with the last-release gamelogic. The master branch of assets should be compatible with either the master engine or the latest-release engine. If an asset requires an engine newer than the last release to work, it should go in a next-release branch.

If possible, we want to avoid any situation where developers are required to use any unreleased stuff from these to get a working setup.