Studio Ganzheit

Phew. The boss entrance scene is nearly wrapped. A couple more fixes and I move on to the ending. I went back and forth a lot on whether to destroy that palace, since I figured it would eat a lot of time, but somehow it came together in three days. Keeping the palace meant it had to break for the boss to appear, but giving it up meant losing that feeling entirely. I had to dig out tools I couldn’t even remember the last time I used, which was daunting, but they held up well and it went fine.

That palace (Injeongjeon) was bought during the last project, and its texture sizes were a mess — it was eating video memory at a terrifying rate. Because of that, things kept slowing down mid-scene and I went looking for the cause everywhere else first, which meant I ended up doing every other optimization before finally fixing the texture sizes. Now it runs okay. The video is from a standalone build; a shipping build should be smoother.

So now it’s really the ending. For the ending I’m planning to move the levels I’ll use as backdrops into new levels, set up static poses with a bit of camera movement, capture that, and handle it as video. The music will be carrying a lot of weight here. I bought a model for the ending but couldn’t find one at decent quality. It only appears in two ending shots in a fixed pose, so I can’t bring myself to install new tools and dig through it. The model quality is rough, but I’ll try to cover for it with camera work.

As I get closer to finishing, the things I want to improve and apply next time are stirring hard. Right now game progression is handled by an in-house script closer to assembly, with no arithmetic or logic in it at all — the one exception is a basic if-then. I decided that once a game script starts carrying logic, debugging becomes unmanageable later, so the script should do nothing beyond running things sequentially and making it easy to wait on something mid-sequence. That’s how it’s built.

Next time I want to stack a BASIC on top of that assembly (I’ve loosely named it a-asm, short for aom asm; the BASIC would be a-basic). Instead of wiring commands by hand across the code like I do now, I’d add an action, have the action describe itself, and let that propagate all the way up to the BASIC layer. I’m thinking of handling the a-basic to a-asm translation in VS Code. The a-basic layer would of course keep logic at the same if-then level. Two reasons for this: easier editing and readability, and because I want to make a game in the BASIC I used as a kid. The second one I consider an excellent reason.

Beyond that, I want to fix all the mistakes I made back when my understanding of the engine was weaker. I spent 2.5 years on this project, and if I improve the things I have in mind, I wonder whether the same scope could come down to a year and a half. I went down so many wrong paths on this one.

Circumstances aren’t easy, but things like this get my heart racing, and sometimes I wonder what that says about me. It’s also what makes me feel that building things the way I do now makes me happy.