Why not an engine

Cinder is the renderer for the tycoon sim I'm building. Written in C99 against Vulkan 1.3, with a Slang shader pipeline and an asset cook that produces a flat pack. No engine-side C++, no middleware, and a small API: describe pipelines programmatically, then render.

Why not Unreal

For most solo projects I'd use Unreal, Unity or Godot, and that would be the right call. It isn't here. The buildings are deformed into their grid cells, not rigidly transformed into place.

That single fact means the per-instance data is four corner positions, not a matrix, and a scene graph built around per-instance transforms fights that at every level. Add a deterministic simulation, which wants control over compiler flags that middleware doesn't expose, and owning the stack stops being a preference and starts being a requirement.

What's stuck so far

A few choices I don't expect to reverse.

C99, no engine-side C++. Keeps the ABI simple and the build fast, and forces an explicit design where C++ would hide allocation and lifetime behind abstractions. The cost is accepted: it rules out most middleware, nearly all of which assumes a C++ ABI.

Vulkan 1.3 as the floor. Descriptor indexing has been core since 1.2, so requiring 1.3 means it's present on every device the game will ever run on. That one guarantee deletes a whole class of fallback paths.

No texture atlases for 3D. With 1.3 guaranteed, bindless descriptor arrays solve batching without constraining content. Atlases would also break the full mip chain (neighbouring tiles bleed at every level past the first) and make REPEAT wrapping impossible.

Per-instance data is cell corners, not a matrix. Buildings are a kit of pieces deformed into the cells of an irregular grid. The vertex shader interpolates mesh-local coordinates into those corners. Anything assuming a per-instance transform is the wrong shape.

Where it is

Graphics and compute paths both work. Fixed binding model: at most four descriptor sets, four bindings per set, two frames in flight. The engine notes are a decision log I write while deciding, not afterwards.

I'll write more as things settle.