Everything so far has been drawn from the original game’s data files. That is fine for proving the formats decode, but it means the engine cannot run at all without a copy of a commercial game sitting next to it. So there is now a sample package that ships with the repo — clone it, build it, and it runs, without a single byte from anywhere else.
It looks ridiculous. A figure assembled out of shaded spheres walking on an empty dirt field, and that is the whole world. I am fine with that for now, and I think building it this early was the right call anyway.
Why bother now
The point is not the art. It is that the sample answers a question with a program instead of a promise: does the engine run without an external asset set?
Asking that question early forces the answer into the architecture instead of bolting it on later. A native package needs its own sprite format, its own map format, its own catalog — and every one of those has to be readable and writable by something other than the legacy importer. Get that shape wrong and the whole engine quietly grows around the assumption that the original game’s data is the only thing that exists.
So the sample is really a shape, and the art is the cheapest thing I could put inside it to prove the shape holds.
What is in it
A sprite is a pair of files with the same name: a PNG and an .ini. The PNG is a
plain grid — one row per direction, one column per frame, every cell exactly the
declared size with no tight packing — and the .ini carries the cell size, the
frame count, the interval, and an anchor point.
The anchor is the part that matters. It is a pixel inside the cell that lines up with the object’s world position, and every sprite making up a character shares it. That is what lets a torso, a head and two arms be drawn as separate sprites and still land on the same body. Get it wrong and the head leaves the neck — and it reads as a rendering bug rather than a data one, which is exactly the sort of thing worth designing carefully before there are hundreds of files.
Maps are .ojr region files: a string table plus three flat arrays of tiles,
objects and scenery, already in the coordinate space the renderer uses. Loading a
region is reading and reattaching, not parsing.
Everything above it is hand-written UTF-8 ini — a map catalog and an actor catalog — because a native package has no import step to generate them.
Where the art came from
None of it is traced or lifted:
- The default character is generated by a script, drawn entirely by algorithm.
- The second character is spheres with drop shadows, also pure algorithm.
- The ground tiles come from a CC0 texture pack.
There are no trees, bushes or rocks, and that absence is deliberate. My local build had scenery from an asset pack whose licence allows use but not redistribution, so all of it came out — 162 pieces plus their 140 shadows — leaving bare ground. A distributable package needs its trees generated too, and that is work for later.
Later
This is a test rig, not a playable build. Once the basics are done I will come back and make a sample worth looking at. Right now its job is to keep the engine honest, and it does that just as well while looking silly.