OpenNFS unpacks Need for Speed data files into a modern engine

A renderer for data files, not a distribution of the games

OpenNFS is an attempt to recreate the classic Need for Speed games, one through five, by unpacking their original data files and running them in a modern engine built from scratch. The word unpack is the key one. The project reads assets that EA produced and renders them with new code, and it ships none of that content.

The releases section states this without ambiguity. OpenNFS does not bundle any EA intellectual property, and a copy of the original games must be provided for it to function, with instructions on the release page. The legal section credits the models, textures, tracks and cars to EA Seattle for 1998, 1999 and 2002 and to EA Canada for 2000, and says plainly that OpenNFS is not affiliated with EA.

That arrangement puts the project in a specific category. It is not a game you download and play. It is a reconstruction of the asset pipeline, the renderer and the vehicle dynamics of games whose data formats were reverse engineered over years, and the value of it lies in what you can build on top of that work.

The code is MIT licensed, which covers the engine side of the arrangement. Any specific question about what the licence means for a particular use belongs with your own counsel rather than with this page.

What the engine is built from

The feature list describes an engine designed with enough configurability to replicate the graphics and gameplay of each title respectively. Four pieces of that are named.

Asset loaders come first, covering tracks, cars, images and music for the PC and PSX versions of Need for Speed 1 through 5. The loaders are the part of the project with the most visible progress and also the part with the most uneven coverage.

Physics is handled by Bullet Physics integration for vehicle dynamics, which is a deliberate choice. The original titles used their own handling, and reproducing how a car felt in 1998 is not the same problem as writing a physically plausible car in a modern engine.

Rendering uses new shaders that allow for dynamic lighting and shadows, so the visual target is not a pixel accurate reproduction of the original output but something built with modern graphics techniques against the original content.

The repository layout matches that. There is a src directory, include, shaders, resources, a test directory, doc, and a cmake directory, plus CMakeLists.txt at the root and a BUILDING.md. The resource tree holds the menu images and the interface assets, and the build is organised as a standard CMake project with submodules for the external libraries.

The asset table is the honest measure of where the project stands

The README includes a table of current loadable assets per game, and it is the most useful thing in the document because it is specific about the gaps. Need for Speed 3 PC stands at 100 percent for cars and tracks and 50 percent for music. Need for Speed 4 PC is at 90 percent for cars and tracks. Need for Speed 2 SE and the PC and PS1 versions are at 90 percent for cars and 90 percent for tracks. Need for Speed 4 PS1 is at 50 percent for cars with tracks not yet listed, and Need for Speed 3 PS1 is at 40 percent for cars and 90 percent for tracks.

Two footnotes explain the asterisks in the table. Some titles fail to load in current builds because of a large parser refactor, which is why the NFS2 and NFS4 PC entries carry an asterisk on cars. NFS5 formats are known, but a stable parser has not yet been integrated, which is why the NFS5 row sits at 40 percent for cars and 5 percent for tracks.

Need for Speed 1 PC is listed at 0 percent for cars and 0 percent for tracks, and no music column is filled in for any title except the two PS1 and PC entries for NFS3.

So the project has working loaders for the middle of the series, partial support at the edges, and a documented parser refactor that temporarily breaks some of what used to work. That last point is the one to keep in mind when planning to spend time with it.

Fetching the dependencies and building on Windows, Mac and Linux

The build depends on a set of external libraries, and the CMake files are configured to detect them from inside the lib folder at the same level as src. The documentation says to get them with a submodule update:

git submodule update --recursive --remote

The dependencies listed are GLEW, GLFW, GLM, Bullet3, Freetype2, Google Test Framework and g3log. The .gitmodules file at the repository root is what makes that command work, and the lib directory in the tree is where they land.

The full build instructions live in BUILDING.md rather than in the README, so the README is deliberately thin on the steps. What it does say is about the CI builds: all versions for Windows, Mac and Linux are built on GitHub Actions, and to use them you click on the last build for the main branch and download the version for your operating system. The game files still have to be supplied, but otherwise the builds are ready to use.

That arrangement is worth weighing against building locally. A CI artefact gets you a running binary without setting up a toolchain or resolving the dependency tree, which is a reasonable way to look at the project before committing to it.

Planned features include actual gameplay and multiplayer

The planned features list sets out what the project is not yet. An actual implementation of gameplay that replicates the original titles is first. Customisable, modular menus built from configuration files are next, followed by automated import of game assets from CD, ISO or provided URLs, then free roam of an open world amalgamation of all the classic tracks, and finally multiplayer.

Read in order, that list describes the distance between an asset viewer and a game. Asset loading is the layer that is partly done. Everything above it, the menu system, the driving model that matches the originals, the world, the network layer, is on the list of things to do.

The free roam entry points at the most substantial of these, because it implies merging tracks from different titles into a single continuous world, which is a content problem on top of a technical one. Multiplayer at the end of the list is the clearest signal of how much is still outstanding.

For the people this project is for, that is a feature rather than a flaw. A renderer with an asset pipeline but no game loop is exactly what you want if the intention is to write the game loop yourself.

Where the work happens, and the licence behind it

Project tracking is public. The README points to the GitHub project boards for an upcoming point release and to a dedicated channel on the Classic Need for Speed Discord server.

The release history is the part that needs a caveat. The tags v0.1, v0.2 and v0.3 all carry July 2020 dates, and the latest stable feature releases are linked from a releases page under the project owner's other namespace, so the published artefacts and the tags in this repository are not quite the same list. The repository itself is not archived and the last push was on 2026-06-21, which means work continues on the main branch even though no version has been tagged since 2020.

That combination, active branch with old tags, is typical of a hobby reconstruction project where the interesting work is in the parsers and the renderer rather than in shipping versions. It also means you should read the commit history rather than the release notes to judge the current state, and expect to build from the branch rather than from a binary.

The MIT licence covers the code. The game assets stay with EA, and the arrangement only works because the project ships none of them.

Reverse engineering is the foundation, and it is credited

The thanks section names the people whose reverse engineering work made the project possible, with a specific list covering various NFS formats and gameplay. That acknowledgement is a fair description of the project's dependency: the format documentation came first, and the engine is built on top of it.

This also sets the boundary for what OpenNFS can and cannot do for you. Formats that nobody has documented cannot be loaded, and the asset table shows the result of that unevenness directly. NFS5 formats are known but have no stable parser integrated, and NFS1 PC data is at zero percent. The engine cannot be blamed for those, and no amount of shader work will change them.

What the project offers in return is a working, MIT licensed C++ codebase that already knows how to read a good share of the classic formats, with a CMake build, a test directory and the dependency set wired up. If your interest is in the games themselves, that is a substantial head start. If your interest is in playing them, the same table tells you the answer before you install anything.

Editorial conclusion

OpenNFS suits reverse engineers and engine developers who want to study how the classic Need for Speed formats were built and to work on a from scratch renderer, since the asset loaders and the CMake project are readable and the CI produces Windows, Mac and Linux builds. It is the wrong tool if you want to play the games, because it bundles no EA content, gameplay replication is still listed as a planned feature and no release has been tagged since v0.3 in 2020. Before building it, clone with submodules, point CMake at the dependencies in the lib folder as BUILDING.md describes, and check the asset load table to see whether the title you care about actually parses today.

Frequently asked questions

Official sources

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