VVVVVV's source code: what the desktop_version tree actually contains

What the VVVVVV repository publishes, and for whom

This is the source code to VVVVVV, the 2010 indie game by Terry Cavanagh with music by Magnus Pålsson, released publicly in January 2020 according to the announcement linked from the README. The repository is not a framework and not a library. It is a shipped game, opened up.

The README splits the codebase in two. The desktop version lives in desktop_version, and the README says that is where the source for the desktop version is. A mobile_version directory sits at the top level alongside it, and the repository's primary language is listed as ActionScript, which points at that mobile tree rather than at the desktop port. Anyone arriving expecting a single coherent C++ project should notice that split first, because it changes which folder they open.

The audience is narrow and specific. The README states you are completely free to compile the game for your own personal use, and that if you are interested in distributing a compiled version you should see LICENSE.md. That sentence draws the line the project cares about: building for yourself versus shipping something to other people. If your interest is the second one, the README does not settle the question and points you at the licence file instead. The credits list a long chain of contributors, including Simon Roth for the 2.0 C++ port, Ethan Lee for the 2.2 SDL2, PhysicsFS and Steamworks port, and Misa Kai for additional coding, which tells you the desktop version is a port that has been worked on by several hands rather than a single original codebase.

How the desktop_version port is put together

The README's credits are the clearest architecture statement available. The 2.0 update is described as a C++ port, and the 2.2 update as an SDL2, PhysicsFS and Steamworks port. Read together, those two lines describe the desktop version's dependency shape: SDL2 for the window, input and rendering layer, PhysicsFS for file access, and Steamworks for the Steam build. That is a conventional arrangement for a 2D game ported out of an earlier runtime, and it explains why the repository carries a third_party directory at the top level: vendored dependencies sit outside the game code.

The data flow implied by that layout is ordinary for a game of this kind. The compiled binary reads its assets, and PhysicsFS is the layer that decides where those assets come from, which is what lets the same build read from a directory during development and from a packaged archive when shipped. The mobile_version tree is the earlier ActionScript line, which is why the repository's headline language is ActionScript even though the desktop folder is C++. The two are not the same program in two languages; they are two branches of the project's history kept in one repository.

What the README does not do is describe the engine loop, the room format, or how levels are loaded. There is no architecture document in the repository. If you want to understand how a room is defined or how the physics work, you will be reading desktop_version source, not documentation. That is the honest state of things here, and it is worth knowing before you clone.

Building VVVVVV from source: where to start

The README does not give build commands. It gives a folder and it gives a licence pointer, and that is the whole of its install guidance. So the first step is not a command, it is reading the right files in the right order.

The repository layout tells you what to open. The desktop build lives in the desktop_version folder, and the README names the two licence files that govern what you may do with a compiled result. Those are the files the README itself directs distributors toward, and the exceptions file exists precisely because the main licence does not cover every asset or contribution in the tree. Read both before you plan anything beyond a personal build.

The README also points at where development conversation happens, which matters when the source does not answer a question. It states that discussion about VVVVVV updates mainly happens on the unofficial VVVVVV discord, in the vvvvvv-code channel. That is the README's actual answer to "where do I ask about this". If you hit a build problem the README cannot solve, that channel is the documented route. What you should not expect is a step-by-step quickstart, because the README does not contain one.

The licence is the real constraint, not the code

The repository's licence is recorded as NOASSERTION, meaning the automated classifier could not map it onto a standard identifier. That matches what the README and the file layout describe: a custom licence with a companion exceptions file, not MIT, not GPL, not zlib.

The practical consequence is that the permissive-sounding sentence in the README, that you are completely free to compile the game for your own personal use, is scoped to personal use. Distribution is handled elsewhere, and the README explicitly redirects you to LICENSE.md for it. A file named License exceptions.md sitting at the top level is a strong signal that some components carry terms different from the main body, which is common when a project bundles third-party code, fonts, music or contributions from many people. The credits list names a composer, a metal soundtrack arranger, localisation teams and a long list of additional contributors, so the exceptions file is plausibly doing real work.

This is not legal advice and the article cannot tell you whether your intended use is permitted. What it can tell you is the shape of the problem: two licence files, a custom identifier, and a README that separates personal compilation from distribution. If your plan involves shipping a build, that is the question to resolve before writing any code, and the answer is in those two files rather than in the README.

Where VVVVVV source is the wrong starting point

If you want a 2D platformer engine to build a different game on, this repository is the wrong tool, and the reason is structural rather than legal. VVVVVV is a finished game with a very particular mechanic: the player cannot jump, and instead flips gravity. Every room, every hazard and the entire level design are built around that one constraint. The source encodes a game, not a general-purpose toolkit, and the README gives no indication that it is intended to be reused as one.

The dependency situation reinforces this. A desktop build pulls in SDL2, PhysicsFS and, for the Steam variant, Steamworks, and the repository vendors third-party code in a top-level directory. You would be adopting a game's build graph, including its Steam integration, for a project that probably does not want either.

The mobile_version tree is a second reason to check your assumptions. If you came for the ActionScript original, you are working in a different folder from the one the README points at for the desktop build, and the two are not interchangeable. And if what you actually want is to play VVVVVV rather than modify it, none of this applies: the README notes the game is still commercially available at thelettervsixtim.es, and compiling it yourself is a separate exercise from buying it.

How VVVVVV's source compares with open-sourced id Software engines

The closest reference point for a reader deciding whether to spend time here is the tradition of id Software's engine releases, Doom and Quake among them. Both are open source, both are game code rather than libraries, and both are studied far more than they are shipped as products.

The difference in approach is what the release is for. An id engine release is typically a general engine that many games were built on, so the source doubles as a platform for new projects and as a historical artifact. VVVVVV is the opposite: a single game with a single distinctive mechanic, released so that people can compile it, study it and localise it. The README's own framing supports that reading, since it talks about compiling for personal use and about localisation teams rather than about building on top of it.

That changes what you get. With an id engine you inherit a toolchain other people have already extended. With VVVVVV you inherit a complete, idiosyncratic game and its port history, including the C++ rewrite in 2.0 and the SDL2, PhysicsFS and Steamworks work in 2.2. If your goal is to understand how a small, tightly designed game is structured in C++, VVVVVV is the more instructive of the two, because the whole thing is small enough to read. If your goal is to build a new game, the id lineage is the better fit, and VVVVVV is a detour.

Releases, maintenance and what upgrading costs you

The repository is not archived, and the last push was on 2026-08-24. Releases are infrequent and irregular in spacing: 2.4.2 on 2024-08-21, 2.4.3 on 2025-06-19, and 2.4.4 on 2026-04-21. That is roughly one release a year, which is the pace you should plan around if you maintain a fork or a localisation patch.

The cost of upgrading is not documented. The README says nothing about migration, and there is no changelog beyond the release version numbers themselves. If you carry local changes, you will be diffing against the new tag yourself, and the size of that job depends entirely on how far the desktop_version tree moved between releases, which this article cannot tell you.

What the repository does support is where to ask. The README states that discussion about VVVVVV updates mainly happens on the unofficial discord, in the vvvvvv-code channel. For a project with this release cadence and no changelog in the README, that channel is the practical substitute for release notes. On the licence side, the same two files apply to every release: LICENSE.md and License exceptions.md. Nothing in the README suggests the licence changes between versions, but nothing states that it does not either, so a fork that matters to you should re-read both files at each tag rather than assume they are stable.

Editorial conclusion

Adopt it if you want to compile VVVVVV for personal use, study the C++ port, or localise the game: the desktop_version folder is where that work happens, and the README points to the vvvvvv-code channel on the unofficial Discord for update discussion. Do not treat it as a drop-in engine for a commercial platformer: the licence is a custom NOASSERTION document with a separate exceptions file, and the README directs anyone distributing a compiled build to read LICENSE.md first. Before you start, read LICENSE.md and License exceptions.md in full, confirm your toolchain against the current README rather than this article, and check the release notes for 2.4.4, published on 2026-04-21, to see what changed since the version you plan to build.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. TerryCavanagh/VVVVVV on GitHub