TetraForce is a Zelda-shaped Godot game built around multiplayer and mods

A top-down adventure with a deliberately small feature set

TetraForce is described as an action adventure game inspired by various action platformer puzzle games, and the two references it names are the top-down Legend of Zelda games and CrossCode. The design goal stated in the README is replayability, for casual and experienced players alike, whether playing alone or with friends. What is unusual is that the project leads with three specific features rather than with a story or a world: multiplayer that is easy to use, an item randomizer, and moddability. The game is built with the open source Godot Engine and is written in GDScript, the engine's own scripting language, which means the source is readable if you know the engine. The repository also carries a `project.godot` file, the scene and resource layout, and an `export_presets.cfg`, so the whole thing is a standard Godot project that can be opened in the editor.

Multiplayer, a randomizer and mods are the three hooks

Each of the three features is a different answer to the same problem, which is that a single playthrough should not be the whole experience. The multiplayer is the answer for the social case, and the README stresses that the point is how easy it is to utilise, since a cooperative mode that is hard to join is not worth much. The item randomizer is the answer for the replay case, shuffling what you find so a second run is not the first run again. Moddability is the answer for the long tail, letting players add their own content. A screenshot in the README shows the multiplayer in action. The project is also reachable in more than one place, with a website, an itch.io page to play in a browser, and a Discord server, which is the usual arrangement for a small game team trying to grow a community. The repository's `.itch/` directory matches that itch.io presence, holding the configuration for the web build.

The repository is organised by game system, not by feature

The root listing shows how a Godot project of this size is usually arranged, and it is worth skimming before you contribute. There is `engine/` for the systems that drive the game, `entities/` for the things in it, `maps/` for the levels, `ui/` for the interface, `dialogue/` for conversations, `effects/` for what happens on screen, `sound/` and `tiled/` plus `tiles/` for the audio and the tile art. `addons/` holds the Godot addons the project depends on, and there are a few loose resources at the root, `default_env.tres` for the default environment, `default_bus_layout.tres` for the audio bus layout, and a `Control.tscn` scene. `contributors.txt` at the root is a small human touch. For a new contributor, the fastest way to understand the project is to open `project.godot` in Godot, see which scenes the game starts with, and trace from there into the directories above.

A container that runs the headless Godot server

The repository includes a Dockerfile, and it is the clearest piece of documentation for the multiplayer side of the game. The base image is CentOS 8, and the build installs the X and audio libraries a graphical build expects, including libXcursor, libXinerama, libXi, alsa-lib, pulseaudio-libs and mesa-libGL, plus wget, unzip and openssl. The Godot version is pinned as an environment variable:

ENV GODOT_VERSION "3.3.2"
RUN wget -q https://downloads.tuxfamily.org/godotengine/${GODOT_VERSION}/Godot_v${GODOT_VERSION}-stable_linux_headless.64.zip \
    && unzip Godot_v${GODOT_VERSION}-stable_linux_headless.64.zip \
    && mv Godot_v${GODOT_VERSION}-stable_linux_headless.64 /usr/local/bin/godot \
    && chmod +x /usr/local/bin/godot

The image then creates a runtime user, adds the exported game as a pack file, and starts it. The command line is the whole server contract:

CMD /usr/local/bin/godot --main-pack /tetra/TetraForce.pck --empty-server-timeout=900

The main pack flag points Godot at the exported game data, and the empty server timeout ends a session that has been running for fifteen minutes with no players, which is the difference between a server that idles and one that consumes a machine all night.

Godot 3.3.2 and CentOS 8 are the pins to check first

The Dockerfile pins two things that will decide how much work an adoption is. The engine is Godot 3.3.2, a headless Linux build, which means the server side of the game is built around the Godot 3 line rather than Godot 4, and the base image is CentOS 8. Both choices come with a shelf life, and the documentation does not discuss upgrading either of them, so an adopter should treat them as fixed rather than as a starting point for a modern rebuild. There is also a practical wrinkle in the download step: the Godot binary is fetched from the tuxfamily download host, which is an external dependency of your build in the same way a package mirror is. The exported `.pck` file is added from a `build/` directory, which means the image is assembled from an export that has to exist first, so building the image is a two step process rather than a single command.

Contribution runs through issues, not pull requests

The contributing guidance is specific enough to be worth reading closely. If you want to contribute, the README asks you to look through the issues first. If an issue already exists for what you want to work on, you leave a comment on it or reach out to the current assignee. If no issue exists, the guidance is to create one to start the conversation. You are asked to review the Style Guide before contributing, and only then to create pull requests. So the workflow is issue first, discussion second, code third, and the repository's own documentation treats the tracker as the front door. For an outside contributor this is a good sign for the maintainers' workload, and a slow one for someone who expected to open a patch directly.

MIT licensed, with releases that stopped years ago

The licence is MIT, so the code, the art and the design are all open to reuse, and that matters for a game project with a modding story, because a permissive licence is what lets a mod distribute its own patch without a separate agreement. The release history is where the project looks least like its marketing. The tags are v0.3.0 on 2021-09-15, v0.4.0 on 2021-10-09 and v0.4.1 on 2023-01-16, and the last push to the repository was on 2026-09-05 with the repository not archived. So the most recent tag is more than three years old while commits continue on the default branch. Nothing in the documentation explains the gap between the two, and the README does not describe a roadmap beyond the three features and the promise of more to come. For a player this is mostly irrelevant, since the itch.io build is the way in. For someone who wants to host the multiplayer server or build a mod on top of the code, it is the fact to plan around.

Editorial conclusion

Players looking for a cooperative action adventure that can be replayed with shuffled items and extended with their own content will find the three features the developers name, and the container recipe gives you a server you can start without a desktop environment. It is the wrong project to fork as a game engine reference, since the codebase is a game rather than a framework, and the wrong project to depend on for a maintained release, since the newest tag is v0.4.1 from 2023. Before you commit, read the Dockerfile to see which Godot version the server expects, and try the itch build to see whether the multiplayer and randomizer features are what you expected before touching the container.

Frequently asked questions

Official sources

1. License: MIT
2. loudsmilestudios/TetraForce on GitHub
3. Project website
4. README
5. Releases