Starship Olympics is a local 1 to 4 player arcade game built in Godot, still in development

A couch party game built around one button

Starship Olympics is a fast-paced multiplayer game where you compete with other players to become the ultimate starship champion. The framing is a sports fiction: you play as one pilot from a roster of aliens, fighting to become the champion of the intergalactic Games, a sport competition described as a symbol of unity and peace for all the species of the universe.

The design constraint that defines it is the control scheme. The features list calls for intuitive and expressive single-button controls, with the promise that everyone can pick up a controller and play. That single decision is what makes it a party game rather than a competitive arena shooter: with one button, a four-player match on one keyboard is genuinely playable, and a newcomer can contribute in the first thirty seconds without learning a move list.

The modes are solo, versus and co-op, and the games are the content: 20 plus games in one, with the README honestly annotating that as eventually, with lots in development. The types of challenge named are racing through an asteroid field and dogfights, both in a 2D top-down arena.

The audience is therefore a group of people in one room with a keyboard or a few controllers, not an online service. It is also, secondarily, a Godot project that a developer might want to read, run or contribute to.

Godot 4.4.x and GDScript, with the game code under godot/

The project is built on Godot v4.4.x and written in GDScript, and the repository layout reflects how the build is organised.

There is a godot/ directory that holds the project itself, and the commitizen configuration in pyproject.toml names a specific file inside it as one of the version sources: godot/globals/global.gd:var version. That tells you two things. The game keeps its version string in a global script rather than in the project settings, and the release tooling writes to it directly, so the version number lives in the same place the running game reads it.

The rest of the tree is release machinery rather than game code. There is a release/ directory, a docs/ directory, img/ for the README screenshots, source_vectors/ for the editable source artwork, a CHANGELOG.md, a CONTRIBUTING.md, a VERSION file, and three separate licence files. There is also a Makefile and a requirements.txt containing a single line, commitizen.

The version bookkeeping is the part worth understanding if you want to contribute. The commitizen config declares version_type semver, a custom bump command name, a tag format of v$version, and three version_files entries pointing at pyproject.toml:version, the VERSION file, and the GDScript global. It also sets update_changelog_on_bump to true and annotated_tag to true, so a single bump command updates the changelog, stamps the tag and writes the version into all three places at once.

That is a well-organised release setup for a small project, and it explains why the tree carries an alpha version even though the last GitHub release is from 2023.

The Makefile is a thin wrapper around commitizen

The build surface is small, and it is a good example of a project that has automated its release process rather than doing it by hand.

The default goal is help, and the version comes from a file read at make time:

.DEFAULT_GOAL = help
FILE=VERSION
VERSION=`cat $(FILE)`

The install target is a two-step chain. install-pip-tools upgrades pip and pip-tools, and install depends on it and then installs the requirements:

install-pip-tools:
	pip install -U pip
	pip install --upgrade pip-tools

install: install-pip-tools
	pip install  -r requirements.txt

The version bump targets are where the interesting behaviour sits. A plain bump fetches the tags, installs dependencies and runs cz bump, which updates version, changelog and annotated tag together. Then there are bump-minor, bump-major and bump-patch, which pass the increment flag to the same command:

bump: fetch-tags install
	cz bump

bump-minor: fetch-tags install
	cz bump --increment MINOR

And there is an alpha path, which is the one that produced the version currently in pyproject.toml:

bump-alpha: fetch-tags install
	cz changelog
	cz bump --prerelease alpha

The changelog target is separate and uses the unreleased version as its argument:

changelog: install
	cz changelog --unreleased-version $(VERSION)

The alpha target runs cz changelog first, which is a meaningful difference from the others. The release history in the repository shows the shape of the work: v0.12.0 as a Worlds update on 2023-04-21, v0.14.0 for analytics and minor bug fixes on 2023-05-13, and v0.14.1 as a hotfix for better keyboard controls on 2023-05-17.

Three licences, and only one of them is open source

The licensing is unusual and the README is explicit about the distinction, so it is worth reading carefully before you use anything from this repository.

The README says all the code used in the project is open source and under the MIT License, so you can use any part of it in games you develop in GodotEngine, which is itself MIT licensed. But the same paragraph then says the software and official releases and binaries are distributed under the project's own End-User License Agreement, and the tree contains three separate licence files: LICENSE_source_code.txt, LICENSE_assets.txt and LICENSE_software.txt.

The summary in the README spells it out in two rules. Source code, meaning everything except the game assets under the assets folder, is under the MIT License. All the game assets, art, audio, textures and .svg files, are under CC BY NC SA unless explicitly stated otherwise, made by notapixelstudio, the community, or contributors, with some from third-party sources credited in the README or in the respective folder.

Two consequences follow that are easy to miss. First, CC BY NC SA is not a permissive licence: the NC clause bars commercial use and the SA clause requires derivatives of the assets to be shared under the same terms, so you cannot drop the art into a commercial game without checking. Second, the binaries are not open source at all, they are covered by a separate EULA, so downloading the build from itch.io and shipping it is governed by a different document from the code you can read.

The project also says the resources are free and royalty-free, made by the community or contributors, and that since the game is in development the credits list might change often. A moving asset attribution list is a practical reason to keep your own record of which assets you used.

Localisation runs through Poedit and a messages.pot file

The project has a documented translation workflow, and it is a gettext-style one rather than an in-editor string system.

The requirement is Poedit, which the README links to for download. The steps for a contributor are numbered: fork the repository and create a branch for the translation work, open the messages.pot file located in the locales directory using Poedit, create a new .po file for the target language through File and then New, translate the strings in the right-hand column, save and close, then commit, push to the fork and create a Merge Request, and the maintainers review and merge.

So the layout is a locales directory holding a template file and one .po file per language, edited in a dedicated tool. That is the standard gettext workflow, which has an advantage for a game with many short UI strings: translators work in a tool built for it, and the .pot can be regenerated from the source as strings change.

The translation guidelines are short and sensible. Use simple and clear language, keep the strings brief and to the point, avoid colloquialisms or cultural references that may not make sense in other languages or regions, and maintain consistency of terminology and phrasing throughout.

The project also asks for help translating in general, and the README points to a Discord, a Twitter account under @notapixelstudio and an Instagram account for updates and news. The game itself is downloaded from itch.io at notapixel.itch.io, and the repository carries PRs welcome and an in-development status badge.

Where Starship Olympics is the wrong choice

The first wrong case is a finished game. The status badge says in development, the features list annotates 20 plus games as eventually with lots in development, and the version in pyproject.toml is 0.14.4a5, an alpha. The last tagged release is v0.14.1 from 2023-05-17, and the last push to the repository was on 2026-10-20. So the source is being worked on, but the published build is old, and the two are not in step.

The second wrong case is anything requiring online play. The features list is explicit about 1 to 4 players and about local party framing, with solo, versus and co-op modes. There is no mention of networking, lobbies, matchmaking or a server, so a group that is not in one room is out of scope.

The third wrong case is a commercial game project that wants the assets. The CC BY NC SA terms on the assets and the separate EULA on the binaries make the code reusable under MIT but the art a different proposition, and the third-party credited sounds and music carry their own attribution trails.

The alternative approach for someone who wants a local party game with a large library of mini games is an established commercial or open party game collection for the same platform. The difference in approach is that a shipped commercial collection has finished minigames, a tutorial pass, balance work and platform polish, where this project gives you a working engine for a dozen or so challenges plus an open roadmap and a community you can contribute to. If the goal is a reliable party night, the commercial collection is the safer purchase. If the goal is a Godot codebase to learn from, or a project to help finish, the repository is the better fit, and the CHANGELOG plus the open issue tracker are the place to see what is next.

Editorial conclusion

Starship Olympics suits a group that wants a drop-in local party game on one keyboard or a shared screen, and a Godot developer who wants to read or contribute to a GDScript game project. It does not suit someone expecting a finished release, since the last tagged release is v0.14.1 from 2023-05-17 while the source tree carries a 0.14.4a5 alpha version, and the project ships binaries under its own EULA rather than a plain open source licence. Before adopting the code, read the three licence files separately, since the source is MIT while the game assets are CC BY NC SA and the official binaries are not open source at all.

Frequently asked questions

Official sources

1. Issues
2. notapixelstudio/starship-olympics on GitHub
3. Project website
4. README
5. Releases