From Unvanquished
Jump to: navigation, search

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, unvanquished_src.dpkdir)
  • Develop on master branch of all repos
  • Build client from laster 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.
  • Build sgame from master and use it with latest-release cgame
    Server owners could ship sgame bug fixes without requiring a download.
  • Develop Unvanquished on master, using latest-release DPKs
    Development for simple cases should be accessible, not requiring -pakpath flags etc.
    As of right now (last release was 0.51), this case is broken: cgame at master is incompatible with unvanquished_0.51.1.pdk so you have to use the pak from Git.

Use cases we don't really care about

  • Using unvanquished_src.dpkdir from master with latest-release gamelogic
  • Using a cgame built from an older commit than the sgame

Per-repository guidance


Adding or removing an IPC call must be done on the next-release branch.

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


Try to keep the submodule pointers to Daemon and unvanquished_src.dpkdir at commits which are 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.

In addition to compatibility with other repos, it is necessary to consider compatibility between cgame and sgame. For example, if you want to add a field to the playerState_t netcode [1], you should do that on the next-release branch. (But if you are a mod developer, you may add fields at any time, provided you ship a cgame.)


When developing on master, you just need to keep it working with the master of Unvanquished. The expectation is that server owners who are shipping a cutting-edge version of this repo should also rebuild the gamelogic.

Other *.dkpdir repos

There isn't a lot of precedent here. Probably it's best to do anything except bug fixes on 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.

Open questions

Should gameplay changes be encouraged on the Unvanquished master branch, as long as they follow compatibility guidelines? Or should those stick to the next-release branch?

On one hand, it might be nice to build the gamelogic from master as a way to test the latest gameplay changes. On the other hand, many gameplay changes will require cgame or pak changes to work; perhaps it is better to keep all gameplay changes together on the next-release branch. We could consider dropping the use-case "Build sgame from master and use it with latest-release cgame" to allow a greater share of gameplay changes on master (ones which modify both sgame and cgame, not just sgame), but we should still forbid changes to master that require modification of unvanquished_src.dpkdir or other paks, since it inconveniences developers.

  1. It is only possible to change this without rebuilding the engine starting from version 0.52.