# TiltedEvolution: the reverse-engineered multiplayer framework behind Skyrim Together

> TiltedEvolution is a framework that enables multiplayer in Bethesda games, currently supporting Skyrim Special Edition, and it works by hooking the game engine and reimplementing its internals in C++ alongside a CEF-based overlay, a dedicated server and a shared network encoding layer. It ships as a Nexus mod with a public GitHub development tree.

**tiltedphoques/TiltedEvolution** — Skyrim mod to play online!

- Repository: https://github.com/tiltedphoques/TiltedEvolution
- Website: https://skyrim-together.com
- Stars: 1,199 · Forks: 293
- Language: C++
- License: NOASSERTION
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/tiltedphoques-tiltedevolution

## A framework behind a mod, and the two names

TiltedEvolution is a framework created to enable multiplayer in Bethesda games, currently supporting Skyrim Special Edition. The project is distributed as Skyrim Together, its codename is TiltedEvolution, and the two names appear in different places: the Nexus page is where players get it, the repository is where developers work on it, and the homepage skyrim-together.com is the product site.

That three-way split is worth holding on to, because it explains the repository's structure. The README's first instruction for a player is to go to the Nexus page, and the general information is on the TiltedEvolution wiki. Only after that does it point developers at the build guide, the code guidelines and the requirement to run clang-format.

So there are two audiences and two workflows. A player installs a mod from a mod site and never sees the repository. A developer reads the wiki's technical documentation, follows the build guide, and works against the source tree. The repository is the second workflow only.

The subject is game modding, and the mechanism is reverse engineering. The topic tags name it directly: game-networking, modding, multiplayer, multiplayer-mod and reverse-engineering, along with fallout4 and skyrim, since the framework's reach is wider than the game it currently supports. The primary language is C++.

The maintenance picture is healthy by the visible numbers. The last push was on 2026-10-15, the repository is not archived, and the release history is recent and frequent, with v1.8.3 on 2026-10-03, v1.8.2 on 2026-09-20 and v1.8.1 on 2026-09-14. The default branch is dev, and the contributing section is explicit that pull requests go to the dev branch and not to master, which is the usual arrangement for a project that keeps a stable branch for players and a development branch for contributors.

## The source tree, and what each piece actually is

The README documents the main project source tree, and the list is a good map of how a multiplayer mod for a single-player game is put together.

The client/ directory is the Skyrim SE client: engine hooks, reverse-engineered game types and the sync logic. That is the part that runs inside the game process, intercepts the game's own behaviour and turns single-player mechanics into networked ones. The immersive_launcher/ directory holds `SkyrimTogether.exe`, which starts the game with the client loaded, which is how a mod gets injected without the player launching the game themselves.

The immersive_elf/ directory contains an `EarlyLoad.dll` helper DLL for the launcher, and it has a specific and slightly unusual job: it detects if Mod Organizer 2 was injected first. That is a real problem in the Bethesda modding world, where several layers of injectors can fight over load order, and a project that handles it explicitly is a project that has been through the field.

The server side is split in two. The server/ directory is the game server, `STServer.dll`, and the server_runner/ directory is the dedicated server executable that hosts the server DLL. Separating the runner from the DLL means the same server code can be loaded into a dedicated process or hosted by something else.

The overlay is tp_process/, a worker for the CEF, the Chromium Embedded Framework, overlay, and skyrim_ui/ holds the in-game UI written in Angular and TypeScript. Using a browser engine for the overlay is a deliberate choice: you get HTML, CSS and a web framework for an interface that has to be drawn on top of a DirectX game.

Then the parts that make it a codebase rather than a script. The encoding/ directory holds the network message and struct definitions shared by the client and server, which is the contract between the two halves and the thing that has to stay in step when the protocol changes. The common/ and base/ directories hold shared utilities, components/ holds shared modules such as the console and settings, the ESP loader, resources and ImGui, and tests/ holds the unit tests.

Outside the source there are three more directories. GameFiles/ holds the plugins, scripts and assets shipped with the mod, Libraries/ holds networking, hooking, reverse-engineering and UI libraries as git submodules, and Tools/ holds the reverse-engineering and address scripts.

## Building it, with xmake, Visual Studio scripts and Docker

The build tooling is where the project's engineering shows, and the repository listing has a lot of it.

The root has Build.bat, MakeLinux.cmd, MakeVSXMakeLatestProjects.cmd, MakeVSLatestProjects.cmd and xmake.lua. The xmake.lua is the substantive one, because the Dockerfile builds the server with xmake, and xmake is what lets the same source build on Windows and Linux.

The Dockerfile is explicit about what it does. For x64 it is `docker build -t imagename .`, for arm64 it is `docker build --platform linux/arm64 -t imagename .`, and for a multi-platform build and push the comments show creating a builder with `docker buildx create --name st-server-multiarch --use` and then building with `--platform linux/amd64,linux/arm64`. The Dockerfile itself has a builder stage on debian:12 that installs build-essential, curl, pkg-config, git, ca-certificates, unzip and libssl-dev, then installs xmake from xmake.io with the shget script, copies the source, and runs `xmake config -y -m release`, `xmake -y` and `xmake install -y -o package`, with the xmake package and repository caches mounted as build cache mounts.

The runtime stage is debian:12-slim, and it copies exactly two artefacts out of the build: the shared library libSTServer.so and the binary SkyrimTogetherServer, with the entrypoint running ./SkyrimTogetherServer and 10578/udp exposed. The comment on the runtime stage says the server runtime image is a todo with maybe reconsidering distroless in the future, which is a note that the base image was chosen for expedience rather than as a considered minimum.

The compose file matches. The service is the published image tiltedphoques/st-reborn-server:latest, it mounts a config directory, a logs directory and a Data directory, it passes /etc/localtime and /etc/timezone read-only so the container's clock matches the host, and it publishes 10578:10578/udp with restart unless-stopped and a tty and stdin kept open.

The port is worth noticing: the game server speaks UDP on 10578, and a dedicated server for a mod is a separate machine from the one playing the game. The docker-compose.yml and docker-multiarch-build.sh at the root are the supported path for running that server, and the presence of a Linux build script alongside the Visual Studio ones says the project expects contributors on both platforms.

## Contributing, and the release machinery

The contributing guidance is short and points in three directions at once.

Check the issues, described as a good place to start when you don't know what to do. Fork the repository and create pull requests to this repository. Create pull requests to the dev branch, not to master. And try to keep your code clean, following the code guidelines, which the README points at as CODE_GUIDELINES.md, with the reminder to make sure to run clang-format.

The asking for experience in C++ is a real signal. This is a codebase where the hard part is the reverse-engineered game types and the engine hooks, and a contributor who does not know C++ is not going to get traction in the sync logic. The same applies to the fact that the hooks and the address scripts are in Tools/, which is where a new contributor would spend their first weeks.

The release machinery is modern and worth describing, because it explains the version numbers. The root package.json is the semantic-release configuration, with semantic-release and its changelog, git and release-notes-generator plugins, and the test script is the npm placeholder that echoes an error and exits, so the JavaScript side of the repository has no unit tests. The .releaserc file holds the semantic-release configuration, and the .gitmessage/ and .githooks/ directories are for commit message conventions, which fits with a project that asks contributors to follow a code guidelines document.

There is a Doxyfile at the root, so the project generates API documentation from the source, and a CHANGELOG.md, an AGENTS.md, a GETTINGSTARTED.md, a CODE_GUIDELINES.md and a README-ANIMATION-MODS.md for the animation mods side of the project.

The project also has a flake.nix and a flake.lock, which is the Nix development environment, and a docker-multiarch-build.sh, a .dockerignore and a .editorconfig, plus branding/ and modules/ directories and a package-lock.json.

The last point about the build system is the one that catches people out. The primary language of the repository is C++, but there is a package.json with Node dependencies, and the JavaScript build is the release automation rather than the product. A contributor who reads the root package.json expecting a JavaScript project will misread the repository, and the semantic-release configuration is the tell.

## Where TiltedEvolution is the wrong choice

There are three limits, and the first one is about scope in a way the project is honest about.

The first is the game support. TiltedEvolution is a framework created to enable multiplayer in Bethesda games, currently supporting Skyrim Special Edition. The framework's design is general, and the topic tags include fallout4, but the current support is Skyrim Special Edition, and the client directory is described specifically as the Skyrim SE client with its reverse-engineered game types. Adopting the framework for a different Bethesda title means doing the reverse engineering work yourself, which is the expensive part and the part the project has already done once.

The second is the nature of reverse engineering. The client works by hooking the game engine and by reimplementing the game's internal types, and both of those depend on a specific build of a specific game. A game patch that changes internal structures can break the hooks, and the fix is a new reverse-engineering pass. That is an ongoing maintenance commitment that a project of this kind carries whether or not the README says so, and it is the reason the project has a tools/ directory of reverse-engineering and address scripts and an active issue tracker with detailed reproducible bug reports called of great importance.

The third is the release channel mismatch. Players get the mod from Nexus, developers work from the repository, and the two are versioned separately. The repository's release tags, 1.8.1, 1.8.2 and 1.8.3 in September and October 2026, are semantic-release versions of the source tree, and there is no statement in the README about how a Nexus build maps onto a repository commit. A player on the Nexus version and a developer on the dev branch are not necessarily running the same code, and that gap has to be closed by whoever integrates them.

And a licensing point, briefly. The README states the project is free software under the GNU General Public License, either version 3 of the License or, at your option, any later version, with a GPLv3 badge and a LICENSE file at the root. The package.json declares a different licence, ISC, and the repository metadata classifies it as a custom licence GitHub cannot classify. The README's statement is the one that describes the project, and a GPL project that links libraries from other licences is a question for whoever reviews the dependency set, which for a project with git submodules in Libraries/ is a real review rather than a formality.

## Conclusion

Adopt TiltedEvolution if you are a modder who wants to work on the Skyrim Together multiplayer stack, because the public tree contains the client, the server, the overlay and the shared encoding layer in one place. Do not adopt it as a library for a different game, since the current support is Skyrim Special Edition and the whole design is built around that engine. Verify first that the version of the mod on Nexus matches the commit in the repository you plan to build, and that the build path you use, xmake, Visual Studio or the Linux script, is the one your environment has.

## FAQ

### What is TiltedEvolution and what does it enable?

It is a framework created to enable multiplayer in Bethesda games, currently supporting Skyrim Special Edition, and it is distributed as the Skyrim Together mod. The public tree contains the hooked game client, the launcher, the dedicated server, the overlay and the shared network encoding layer.

### How do I build the Skyrim Together server?

The Dockerfile documents it: `docker build -t imagename .` for x64, or with `--platform linux/arm64` for arm64, using xmake as the build tool with `xmake config -y -m release` and `xmake install -y -o package`. The compose file runs the published tiltedphoques/st-reborn-server:latest image and publishes 10578/udp.

### Which branch should pull requests target in TiltedEvolution?

The README asks contributors to create pull requests to the dev branch and not to master, and the repository's default branch is dev. The code guidelines are in CODE_GUIDELINES.md, and contributors are asked to run clang-format.

### What licence does TiltedEvolution use?

The README states the project is free software under the GNU General Public License, either version 3 of the License or, at your option, any later version, and the repository carries a LICENSE file. The root package.json separately declares ISC, so the two declarations do not match.

## Sources

- [Issues](https://github.com/tiltedphoques/TiltedEvolution/issues)
- [Project website](https://skyrim-together.com)
- [README](https://github.com/tiltedphoques/TiltedEvolution/blob/dev/README.md)
- [Releases](https://github.com/tiltedphoques/TiltedEvolution/releases)
- [tiltedphoques/TiltedEvolution on GitHub](https://github.com/tiltedphoques/TiltedEvolution)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tiltedphoques-tiltedevolution