TeamVanilla logo

We take old PC games apart and write down how they work.

TeamVanilla is a game development and research & development company, founded in 2018. On the research side, we pick a game, work out how its executable and data files are put together, and publish what we find in two forms: an encyclopedia that explains the engine, and a C++ SDK that lets you mod it. Underneath all of it sit three libraries of our own, for hooking, UI and graphics. On the development side, we rebuild old games on engines of our own, make games of our own, and make the tools and mods that follow from the research.

We started as Vanilla Remastered, a group of friends making a San Andreas modpack that passed 1.2 million downloads. How we got from there to here, and who we are, is on our About page.

The code and the full documentation live on teamvanilla.dev. This page is about the company and the rules we work by.

What we make

Libraries

VanHooks
Function hooking for Windows, Linux and macOS on x86, x64 and ARM64: 17 hook kinds, from trampolines, import tables and vtables to hardware breakpoints, with RAII lifetime, groups, chaining, introspection and a batch queue.
VanGUI
Immediate-mode UI for C++23, with 40 optional modules for animation, theming, dialogs and tooling widgets.
VanGFX
One interception and shader API across Direct3D 9, 11 and 12, with buffer and G-buffer readback.

Tools

NiTools
Static analysis of any file, in your browser, without uploading it. It breaks Windows, Linux, Android and macOS binaries down to the byte, disassembles x86 and x64, recovers C++ classes and scores how much points at packed or hostile code. Open NiTools.
VanSuite
A desktop reverse-engineering app built on VanHooks and VanGUI: disassembly, control-flow graphs, a decompiler, and live hooking of a running process.
VanTools
A Windows maintenance suite with no ads and no telemetry: cleaning, startup control, drivers from Windows Update, an uninstaller and a download manager, with every change backed up first.
And smaller ones
Py2EXE for building Windows executables from Python, DiscordChatExporter for keeping a channel's history, and GameFunctionsTools for checking class layouts against an executable.

Games

For each game we work on, the research comes first and the tools, mods and rebuilds follow from it. Each game has its own page on teamvanilla.dev.

Need for Speed: Most Wanted
A 78-chapter reference book, MWSDK, the MWOn12 and MWDX renderers, the MWTools editor suite, NFSMapEditor for Rockport, the NFSMW-ML mod loader, the FX12 post-processing suite, and mods including DriftMode and RemovePoliceHUD.
Grand Theft Auto: San Andreas
A 55-chapter reference book with 297 verified struct schemas, SA-SDK, and our modpack, Vanilla Remastered.
The Simpsons: Hit & Run
A 51-chapter reference book, DonutsSDK, and mods.
Soldier Front
OpenSF, the game reconstructed with its own server, at any frame rate and with controllers; a map editor; and a launcher, frame-rate and controller mods for the Legacy client.
Drift City
A reference book, an SDK, a mod loader, a graphics mod and a menu mod, and a rebuild of the game in development.
CrossFire
OpenCF, a site and app with players' profiles and every weapon's real numbers.
Gearhead Garage
The 1999 car-repair game, rebuilt screen by screen for Windows and Android.
GunZ: The Duel
A graphics overlay for GunZ Legacy.
Games of our own
A tactical shooter, a survival game set after a zombie outbreak in Appalachia, and a game set in Trenton Psychiatric Hospital in 1982, all on our own engines and all in development.

For the web

Prism
A self-hosted community watchdog platform: a searchable public record, a social layer, a help desk and an admin panel.
VanillaTickets and VanTracker
A standalone help desk, and a bug tracker with Discord sign-in and a JSON API.

The games named here are trademarks of their owners, and each game's page names them. We aren't affiliated with any of them.

What “verified” means here

Nearly everything we publish is a claim about a program somebody else wrote, so every claim carries one of three labels. Verified means we reproduced it from the file's bytes, or confirmed it in the executable's own code. Reasoned means it fits all the evidence but isn't a byte-for-byte proof. Open means we know the thing exists and haven't decoded it yet. We would rather print Open than guess.

Here are three facts from MWSDK, each one used by the SDK's own code:

NameValue
AttribCollection::GetField0x00454810, thiscall(key, index)
hash::attrib("default")0xEEC2271A
AIVehicle::mTopSpeed+0x84

The first is the function the game uses to read a car's tuning values; the SDK calls it to read and write attributes on a live car. The second is the engine's own string hash, reimplemented in the SDK and checked by static_assert every time it compiles. The third is a member offset that the SDK's typed vehicle view reads through.

None of those numbers were typed into the SDK by hand. A script generates its address database from the encyclopedia's data files, and only entries marked as verified reach the main namespace. Addresses from a third-party research import are kept apart in mw05::research, so weaker evidence is visible at the call site.

How a project usually goes

We start by reading. Before changing anything, we measure what the game actually does, and that measurement decides where to intervene.

Then we look for two separate sources of evidence: the data files the game ships with, and the executable itself. They go wrong in different ways, so when they agree we trust the result.

Next comes the encyclopedia. Writing a chapter shows us what we don't know yet, which sends us back to the files. The SDK is generated from the same data, so a number is identical in the book and in the code.

What we won't do

Contact

Discord is the quickest way to reach us. If you want to use one of the libraries or the SDKs, or you have a binary you want to understand, bring it there.