The koi are back

January 2025

A great way to find out how much work you've done, is to do it all over. The Javascript prototype felt like a quick experiment, but I've really come to appreciate the amount of work I had already done while porting it. Luckily, the end is in sight, as I've now ported over everything except for the pattern generator, which requires a bit of a redesign since I want to improve upon it.

The koi have all their body parts back and swimming around happily. The game now has three different builds:

1. The debug build, which is the one I use most often. This build contains all the development interfaces which let me edit all things while the game runs. It gives me detailed information whenever a bug occurs, but it's also unoptimized for that reason.
2. The development build, which is optimized and should perform very similarly to the release build. It does however still contain all the development interfaces for testing.
3. The release build, which is the build that will eventually be distributed to players. This does not contain development interfaces, and it's the most heavily optimized build.

The new debug interface is not HTML based like the prototype. I did initially really love the HTML based debugging interface, they seemed very easy to set up and modify. Rewriting them in c++ using ImGui was a breeze though, and it's noticeably faster to write and iterate upon. It's using the "immediate mode" design pattern (hence the name), which doesn't need as much state and therefore potential bugs. Another advantage is that this interface doesn't just run on PCs, but on consoles and phones as well, while web based interfaces aren't universal. This will help to debug console versions in the future.

Another small improvement I've made to the engine is hot reloading shaders and pipelines. A lot of work is done on the GPU, and with this improvement I can write and test GPU code without restarting the game all the time.

While porting, I also seized the opportunity to improve systems I know I'll have to rely on later. For example, clicking koi was implemented in a very accurate but rather complex method: I would create a screen size texture and render all koi in the scene to it. Instead of writing colors, I wrote the koi indices to it, read back the texture from the GPU and checked which koi (if any) was at a given pixel position. This method was "pixel perfect", but reading back data from the GPU takes a lot of time, and by the time you have that data, the game has advanced by a few frames already. The method seemed very precise, but in reality, you were clicking on koi in the past and getting the results too late. Implementing this in the new engine was tricky, and although it worked, the latency was too big. I replaced that method by just approximating the koi by a number of spheres, and picking up koi now checks for intersections of the mouse ray with these spheres. Interactions feel snappy again, and I've implemented the single koi moving mode to test this.

Moving a single koi at a time is useful, but the koi limit of the entire scene is about 4000, so more useful moving methods will be implemented later. Moving a bunch of koi in a net for example is very useful when breeding koi, and there will be methods to quickly filter through large numbers of small fry. These methods need to do many more checks, for which the new koi picking method is much more suitable.