Inspiration
Could the plants from Plants vs. Zombies survive a different kind of zombie apocalypse? We brought them into Call of Duty’s Nacht der Untoten to find out.
Plants vs. Zombies and Call of Duty: World at War both turn surviving waves of zombies into a strategy problem, but they approach it very differently. We wanted to combine PvZ’s plant placement and resource management with the intensity and immersion of first-person Zombies gameplay, while keeping World at War’s original engine and both games’ original artwork and sounds.
That idea became Nacht Garden. Along the way, it also became an experiment in using modern AMD cloud computing to prepare better animation assets for a much older game.
What it does
Nacht Garden brings placeable plants, sun currency, seed packets and plants Vs. Zombies abilities into Nacht der Untoten.
Players can build defenses with plants such as Peashooter, Sunflower, Wall-nut and Chomper while continuing to move and fight normally. Planting uses a modified version of World at War’s original Bouncing Betty animation, with the selected plant in the player’s hands. We also added pea attacks to the M1A1 Carbine wall weapon just for the fun of it.
Our recorded comparison places the earlier Peashooter animation beside the improved version, showing how we utilized AMD's cloud computing hardware with smoother movement, a continuous body loop and correctly attached eyelids.
How we built it
The project has two connected parts: AI-assisted game integration and AMD-accelerated animation processing.
For the integration, we used AI coding assistance to help investigate asset formats, understand animation behavior, write conversion tools and implement gameplay scripts. We extracted assets and inspected scripts from our installed games, consulted an existing PvZ decompilation reference, and used World at War’s GSC scripting system to connect the plant mechanics to its zombies, weapons and HUD.
We retained the original WaW engine. This was asset extraction, reverse engineering and integration—not a complete decompilation or merger of two game engines.
For the animation pipeline, we used an Anrui cloud workspace with an AMD Radeon Pro W7900D and approximately 48 GiB of GPU memory. Python and NumPy handled data preparation, while PyTorch through AMD ROCm accelerated image sampling and compositing.
Our renderer uses the original animation tracks and artwork to produce additional intermediate frames. For the enhanced Peashooter idle, we turned 25 original poses into 125 frames for playback at 60 animation samples per second. We also repaired the loop and attachment logic so blinking no longer interrupted the body’s movement.
The expanded roster pipeline exported 1,358 frames across 24 clips. Local tools packed the frames into sprite sheets and World at War’s native texture and effect formats. WaW Mod Tools and OpenAssetTools assembled the mod, which we tested on Linux through Steam Proton.
The cloud processing happens before gameplay. Once packaged, the assets play locally without a connection to the cloud GPU. This is offline animation processing, not FSR or live game-frame generation.
Challenges we ran into
The hardest problems were often at the boundary between systems.
Heads and eyelids detached when animation layers used the wrong attachment transforms. Blinks caused pauses when they interrupted the body cycle. Large sprite sheets ran into the older engine’s memory constraints.
We also encountered problems that successful compilation did not catch. Two planting-weapon definitions exceeded the game’s text-loading limit and appeared as default weapons. Chomper’s sprite extended below the floor because rectangular effects were missing an independent width-and-height setting.
These problems taught us to validate the whole path: original data, rendered frames, packaged assets and actual gameplay.
Accomplishments we’re proud of
We built a playable crossover inside the original World at War engine while preserving the original games’ visual identity.
We also measured a concrete AMD compute result. In our initial controlled benchmark, rendering the same 16-frame batch took approximately 1.388 seconds on the cloud CPU and 0.0392 seconds on the Radeon GPU—a 35.4× rendering speedup.
All 1,358 expanded-roster frames passed pixel-preservation checks during packing. We added checks for sprite borders, texture sizes and weapon-definition limits, then confirmed the repaired Nacht version through playtesting.
What we learned
GPU acceleration and animation correctness solve different problems. AMD hardware made the rendering calculations faster, while our code had to fix the timing, attachments and proportions.
We learned that modern compute can improve content for older software without requiring that software to run a modern compute framework itself. A small team can use remote AMD hardware to prepare assets, then deliver those assets to an existing local runtime.
What’s next
Nacht is our accepted proof of concept. Next steps include broader combat and balance testing, additional map support and more complete end-to-end performance measurements.
Longer term, we would like to turn the animation pipeline into a reusable tool: provide original animation data and an engine’s output constraints, process it on AMD cloud hardware, and receive validated, engine-ready assets.
Log in or sign up for Devpost to join the conversation.