VoxelStrike — Destructible Combat Engine in Python

A land, air and sea combat engine over terrain you can blow holes in, written in Python and kept at frame rate by Numba-compiled kernels and a GPU renderer that works per pixel.

A real-time 3D combat game in a language not built for speed

Read how it is built Browse the whole roster

291,772lines of code
254files
2,820commits
1data models
Screenshot of VoxelStrike — Destructible Combat Engine in Python

The hard part

A game has about sixteen milliseconds to draw each frame. Python uses a good share of that before any game code runs, which is why 3D engines are rarely written in it. That constraint shaped every design decision here: each choice exists to win those milliseconds back, and the frame rate shows at once whether it worked.

The hot loops are compiled to machine code with Numba, the terrain is raymarched per pixel on the GPU, and lighting is baked into the colour map ahead of time. Everything that is not ground is drawn with instancing, which renders many copies of an object in a single call. Bombs then carve real craters into the live terrain. Every performance change is measured against the previous commit, so a slowdown shows up as a number long before anyone feels it.

2,476 commits on 91 working days since 2026-05-31; every gate verified against a deliberate revert; the showcase's counts generated from the game's own tables.

What the measurements mean

Only what is unusual for this project. Every sentence names the field it came from; nothing here is asserted that cannot be checked against the data.

How it works

The terrain is a height map plus a colour map, and it is drawn two ways. The first is the classic Voxel Space column raycaster, the technique behind Comanche, compiled with Numba (which turns Python into fast machine code) and run on every core. The second is a GPU raymarch that casts through the same height field for every pixel. That gives a true camera tilted to any angle, so a city seen from above shows real three-dimensional buildings. Voxel models, particles and billboards are drawn in batches on the same path. Craters are carved into the live height map by a single Numba kernel that slumps the rim to its angle of repose, the slope loose ground settles at. That detail matters for play: a machine that drives into a crater can always drive back out. What sets the project apart is how it is developed: nearly every claim is measured, and the measurement is committed. Every check in its headless test battery has been shown to fail when the thing it guards is deliberately reverted. Performance is benchmarked A/B, interleaved against the last commit so that machine load affects both sides equally. Each weapon, machine and mech has its own lab, long runs go to my fleet of machines, and the public showcase is generated from the game's own tables. Its architecture became the starter kit for VoxelBlox.

What it is built from

Each bar is one of this project's own modules, sized by how many times the rest of the project imports it. The counts are measured, not estimated, and the module at the top is the one the rest of the project leans on most.

Module mapInternal modules by how often they are imported: labkit 212 times, battle_lab 25 times, fx_lab 9 times, trailer 8 timeslabkit212battle_lab25fx_lab9trailer8imports of each internal module, counted across the project

What kind of engineering this is

Six signals counted from the source: files that run models locally, that act without being asked each time, that check their own output, that survive failure, that touch parsers and protocols, and that were measured then improved. Every axis carries its file count.

Depth profileDepth signals: Local inference 0 files, Autonomy 8 files, Verification 11 files, Resilience 34 files, Low level 22 files, Iteration 0 filesLocal inference0 filesAutonomy8 filesVerification11 filesResilience34 filesLow level22 filesIteration0 files

What it is written in

Share of code bytes. Vendored bundles and generated output are set aside before this is computed, which is why it differs from a simple file count.

Language mixPython 98.2%, HTML 1.6%, Batchfile 0.1%, C 0.1%, CSS 0.1%, Shell 0%Python 98.2%

What stands out

Capabilities

Grade

Every check names the field it measured. Checks that cannot apply are excluded, never counted as failures.

A
97.1% over 18 of 18 checks100% coverage

Architecture

Directories carrying real modules, largest first.

Data model

Typed structures and tables found in the source.

Vocabulary

Parsed 244 of 247 Python file(s); the rest were over the size budget. Counts are exact; the names below are a sample.

3,829functions
2,249methods
220classes
231documented modules

Classes

Functions

Command line

Depth

Signals counted from the code, not asserted.

2477 commits across 102 separate working days over 5.4 months, 90 of them revising existing behaviour

Built from scratch

Closes its own loop

Proves itself

Survives failure

Systems

Working within limits

Distributed systems

Networking

Environment engineering

Operating-system internals

Languages

Built with

Recurring themes in the commit history

Evidence

Taken from the code itself: a module docstring or the opening of the README.

VoxelStrike entry point. python main.py Or just double-click run.bat on Windows (sets up the venv automatically).

At a glance

Status
active
Primary language
Python
First commit
2026-05-31
Last activity
2026-11-11
Domain
Games & graphics
Agent docs
CLAUDE.md, AGENTS.md, .claude