NZ:P, a Call of Duty Zombies demake built on Quake engine forks

What the hub repository is, and what it is not

This is the main or hub repository for NZ:P, a Call of Duty: Zombies demake powered by various enhanced forks of the Quake engine, in development since 2009. The README describes the hub as serving two purposes: a place to host nightly builds, and a means of bug reporting on a game-wide, non-component, scale.

That distinction matters for anyone evaluating the project, because the interesting code is not here. The top level of the repository holds the README, the .github/ directory, a .gitignore, a screenshots/ directory, two shell scripts, and a JSON file called gay.nzp.nzportable.json. There is no engine source and no game code in this tree.

The project has a second important property, stated in the README: the game is feature-equivalent with Call of Duty: World at War on a generic level. Gameplay components are implemented with minor parity differences. Most World at War maps and their unique features are not yet represented. Various small additions and changes from Call of Duty: Black Ops are present as a means of gameplay smoothing, but not on a wide scale. The final sentence is the one to hold on to: NZ:P is, first and foremost, a Call of Duty: World at War remake.

So the honest framing is that this is a fan remake with a defined scope, seventeen years into development, that has not yet reproduced the full content of the game it is remaking, and that adds a small number of things from the later entry. The README is upfront about all three of those facts, which is unusual and worth crediting.

The engine choice and why the Quake forks matter

The technical decision that makes NZ:P possible on the hardware it targets is the engine, and the README describes it as powered by various enhanced forks of the Quake engine. The organisation breakdown names them: vril-engine is the NZ:P engine, and quakec is the game-side code for things like weapons and Perk machines.

Quake engines have a long history of community forks that add modern conveniences without abandoning the original structure, and several of the credits in the README point at exactly that. Shpuld is credited with CleanQC4FTE and heavy dQuakePlus optimization. Crow_Bar and st1x51 are credited with (a)dQuake(plus). fgsfdsfgs with Quakespasm-NX. MasterFeizz with ctrQuake. Ralf Willenbacher with nQuake.

Those are not incidental acknowledgements. Each of those forks is a piece of the reason the project can target the platforms listed later, because porting a modern shooter engine to a Nintendo 3DS or a TI NSPIRE is not a job anyone does from scratch when a maintained fork of a 1996 engine already exists with the necessary abstractions in place.

The credit list also shows how the project is staffed. Under programming you have Blubswillrule, Jukki, DR_Mabuse1981, Naievil, Cypress and Scatterbox. Models and GFX credit Blubswillrule, Ju[s]tice and Derped_Crusader, with the name Ju[s]tice written with escaping in both the models and the GFX lists. Sounds and music credit Blubswillrule, Biodude, Cypress and Marty P.

That is a small, long-standing group, and the special thanks section names individuals with specific contributions: Rinnegatamante for the initial VITA port and the VITA auto-updater, Azenn for GFX assistance, BCDeshiG for extensive testing, and a group including Spike, Eukara and Contributors: FTEQW.

The project also has an institutional side, a nzp-team organisation and a separate nzp-team.github.io site, which is where the documentation at docs.nzp.gay lives.

The platform list, which is the headline achievement

The supported platforms list is the reason this project is interesting to read about, and it is worth taking one at a time.

Linux is supported on x86, x86_64, armhf and arm64, which covers both desktop distributions and the SBC boards and handhelds that run them. Windows is supported on x86 and x86_64.

Then the list stops being conventional. There is the Nintendo Switch, the Nintendo 3DS, the PlayStation Portable in both its original PHAT form and the SLIM revision, and the PlayStation Vita. There is TI NSPIRE, in the CX II revision. And there is WebGL, linked to a live build at nzp.gay.

Running a first-person shooter with procedural features on a TI NSPIRE is a genuinely remarkable piece of engineering, and the presence of a WebGL build is the other end of the same idea: the same source that runs on a handheld compiles to the browser.

The Vita port gets its own line in the credits, with Rinnegatamante credited for the initial port and the auto-updater, which suggests the Vita was not a straightforward target and needed its own bring-up work.

Two details in the README tell you the project treats these platforms as first-class rather than as an afterthought. The WebGL build is linked directly from the platform list rather than described in prose, and the documentation site is a separate nzp-team.github.io repository rather than a wiki page, which is what a project with this many platforms and this many contributors tends to need.

How the hub works: nightly builds, flatpak packaging and project-wide bugs

Three files in the repository root carry the mechanics of the hub, and each maps to one of the README's stated purposes.

generate-nightly.sh is the build automation behind the nightly artefacts. It is the script that produces the builds the hub exists to host, and the release list shows a single rolling tag named nightly, whose version string carries a build timestamp: the most recent release listed is 2.0.0-indev+20261019143309, tagged the same day as the last push to the repository. The indev marker and the date suffix together tell you this is a continuous integration release line rather than a curated one, so a consumer pinning a nightly gets whatever the build produced that day rather than a chosen version.

generate-flatpak.sh produces a Linux package. Flatpak is the packaging format that made Linux handheld ports tractable, and the decision to ship a flatpak generation script in the hub rather than in a component repository is the right one, because the packaging has to describe the whole assembled game.

gay.nzp.nzportable.json is a per-platform metadata file, named after the project, which describes the build for a specific target. A file named this way in a hub repository is the conventional place for the descriptor of a platform-specific package, so this is where the Windows, Switch, 3DS or Vita build definitions would live rather than in the shared engine repository.

The other stated purpose of the hub is bug reporting at game-wide scale. That exists because the project is split into components. A bug that spans the engine and the game code does not belong to either, and without a hub the only place to report it is a repository issue tracker that belongs to one of them. The README points to the breakdown of the GitHub organisation for the source code and other components, which lists assets for the game GFX, sound and other data, vril-engine for the engine, quakec for the game-side code, tools for miscellaneous development tools, and toolbox as an all-in-one development suite for map makers and contributors.

Limits: no licence, no tagged releases and a remake that is not finished

The limits here are real and they come from the documentation rather than from anything hidden.

The first is the licence. The repository records the licence as unknown, and there is no LICENSE file in the top-level listing. There is a CLA.txt in the engine repository's naming, and Quake engine forks have their own licensing terms which historically have included both permissive and source-available variants. For a project built on forks of other people's engines, the licence position is genuinely complicated, and the README does not address it at all. Anyone planning to redistribute or build on this needs to work that out separately.

The second is the release model. There is a single rolling nightly tag and nothing else. No versioned releases, no changelog in the repository, no stable branch. The version string 2.0.0-indev tells you the project is still working towards a 2.0, seventeen years in, which is either a statement about scope or about how the versioning is done, and the README does not say.

The third is the completeness of the remake, and this is the README's own admission. Most World at War maps and their unique features are not yet represented. The additions from Black Ops are present but explicitly not on a wide scale. So the product is a partial recreation with a defined difference from the original, and a buyer should judge it on that basis rather than on the screenshots.

The fourth is the size of the assembly. This repository is a hub over five other repositories, and the runtime result depends on the engine, the game code and the assets all being at compatible revisions. The bug tracker being at hub level exists precisely because those boundaries cause problems, and the same boundary means a user installing from the hub has to trust that the nightly bundle it downloads has the right combination.

The fifth is that the primary language is recorded as Shell, which tells you the hub itself is a thin set of scripts and that the substance lives elsewhere.

NZ:P against a standalone Quake port and against a modern commercial remake

Two comparisons make the choice clearer.

The first is against running a stock Quake engine with the Call of Duty content you already own. That is what a Quake port is for, and it gives you the engine without the game. The difference in approach is that NZ:P implements the gameplay itself: the round structure, the perk machines named in the credits, the weapon behaviour, the points economy. That work is what makes it a remake rather than a content swap, and it is why the repository has a separate quakec repository for the game-side code.

The practical benefit of that choice is hardware reach. Because the engine is a Quake fork with a long history of community optimisation, the same source reaches a Nintendo 3DS, a TI NSPIRE and a browser. A modern shooter engine would reach none of those.

The second comparison is against a commercial remake or a licensed re-release. Those have working licences, defined content parity, support and no ambiguity about what you are running. NZ:P has none of those. In exchange it gives you a build you can run on hardware that no commercial product will ever target, and a codebase you can read, modify and port.

The honest framing is that these are different activities rather than competing products. A commercial remake is a purchase; NZ:P is a hobby project, maintained by a small credited group over seventeen years, and the README's own scope statement is the specification you should hold it to.

Editorial conclusion

Adopt NZ:P if you want a self-hosted Night of the Dead-style mode that runs on hardware a modern shooter would never reach, including handhelds and a browser. Do not adopt it as a Call of Duty replacement, since the README is explicit that it is a World at War remake and that most World at War maps are not yet represented. Verify first which platform build you want and where nightly artefacts are published, that the game-side content is present in the assets repository rather than this one, and that the licence position is acceptable, since the repository records the licence as unknown and the work is built on Quake engine forks with their own terms.

Frequently asked questions

Official sources

1. Issues
2. nzp-team/nzportable on GitHub
3. README
4. Releases