Postmortem

This was my first jam game and I feel like I learned a lot from the format (and it was fun). I'll do more jams in the future. My big take away is that scope and polish are the two important things to focus on in the future. This project is by no means large or complex but getting the core mechanic working required enough tricky code that it is probably pushing the bounds of reasonable scope for me. And polish is important. The places where I spent time making things smooth and pretty are the places I'm happiest with and the places I neglected that are the places I'm most frustrated by. So I think my goal for next time is to shrink scope and try to get a crisp, polished implementation of a technically simpler idea.

Things That Went Well
Concept
In the first couple of hours I came up with a pretty clear vision of a moment I wanted to have in the game and I spent the rest of the time building towards that. I wanted a little meeple to run into an enclosed space, drink a potion and suddenly grow ten times larger, smashing everything around them in the process. That vision and the underlying idea of scale change as a game mechanic kept me pretty on track through development.

Focus on Details
Some places where I successfully focused on the details and got results I am pleased with:

The feel of the initial sequence where the player emerges from the forest and sees the small scale fence mixed with the scaled up tree sprites and the "hill" made from an even more scaled up skull sprite, which at that point is so large relative to everything else that it isn't even recognizable. I wish I'd gotten to the same level of detail in the rest of the level.

The over all look of the world when seen fully zoomed out during the final sequence. I wish I'd had more time to spend on this but I still like it. Until very near the end there was a moon in the sky where the final card is in the release version which contained a (never finished) second half of the level.

I spent a lot of time working on performance so that the game could stream in the relatively large amount of collision data it uses without a loading screen and without disrupting the frame rate noticeably. It's still not perfect, especially in Firefox where performance is poor over all, but I like the seamlessness of not having the loading screen and over all the frame rate is pretty stable even during terrain destruction which requires rebuilding a lot of cached stuff. If I were to continue development I'd have to spend even more time on this to get smoother particle effects and to make the final sequence with it's rapid terrain destruction and explosive scale change work well.

Choice of tools
I continue to be pleased with how well Rust handles cross platform code. I produced executables for Linux (my development environment), Windows and WASM without writing a single line of platform specific code. That's due not just to Rust but to Quicksilver (and it's dependencies) being aggressively cross platform. Obviously if I'd been using a mature engine like Unity or Godot it would have been at least as easy but I appreciate being able to write fairly low level code and having it just work everywhere. Almost everywhere. I wasn't trying to do mobile and Quicksilver has little or no support for those platforms. I also didn't try to produce a Mac build because I didn't have the cross compilation chain already installed, but I think if I had it would have worked as smoothly as the Windows build.

Binary Size
This is a particular bugbear of mine which isn't really that important in most cases but it always bothers me. The binary size for this project, which I have made no effort to minimize, is around 4M for the desktop version and just over 1M for the WASM version (uncompressed). Most of the games I'm seeing in the jam which are exported from Unity or Godot weigh in at 20x that even though they are using roughly the same assets. I haven't tried to do compact web builds using either of those tools and it looks like there are ways to produce more compact executables but clearly the default is huge.

Things That Went Not As Well
Visual Impact
When I started working on this I had an image in my mind of large scale structures built out of mosaics of smaller sprites, little things nested in big things, a lot of visual detail created by layering low resolution images at many different scales. The final version doesn't really achieve any of that. The biggest reason is time. Doing what I imagined would take a lot of effort to design and lay things out even if you were just trying to make a static visual, a hundred times more to make it into something that is both visually appealing and a playable level. Still, I wish I'd invested more time in getting a few examples of what I was imagining into the final project. The closest it really comes are the skull hills. The other issue is that I only gave myself three layers to work with, a background, a foreground and collidable terrain inbetween. Each layer was a single solid color. To do what I wanted I would have needed, at the very least, several additional foreground and background layers with distinct colors. But I baked some assumptions about the layering into the code and by the time I realized what I needed there wasn't really time either to fix the code or to design enough visual detail to justify the change. I should have thought a bit harder about visual polish early on.

 Choice of Tools
This gets a bad stuff section as well as a good stuff section. I wrote a lot of really low level code for this. There's a custom quad tree. There's a lot of mucking around with linear pixel arrays. Considering that I was working against a 48 hour deadline I probably should have reached for higher level stuff. There's an element of stubborness there. I like working that way. Also, the biggest chunk of low level code I wrote is the quadtree and I don't know if I was going to find an off the shelf thing that would support the kinds of operations I needed. A quick survey of existing Rust libraries didn't turn up anything that looked promissing.

The most problematic tool for me was Tiled. It's great for laying out tile maps but I was trying to use it to do pixel accurate placements of sprites which were sometimes scaled by more than 100x and it's simply not designed for that. It worked just well enough that I continued to use it but I probably should have had a look around for something else because it cost me a lot of time. If I were to keep working on this project I would certainly switch to a different tool. I would also likely build a preprocessing pipeline to help with terrain loading by preflattening the many overlapping sprites in the input and probably even prebuilding the initial quadtree so that doesn't have to happen at runtime.

 Presentation
The game doesn't have any introduction, or instructions and there's minimal feedback on player actions. It ends abruptly with a basically meaningless and completely unexplained "score" in the form of a cloud of card sprites. None of that stuff is vital to exploring the core mechanic but not having it makes everything feel crude and amateurish. Next time I do something like this I will dedicate a meaningful chunk of the time budget to getting better framing early on.

When I posted the game to the jam it asked for a logo image and I just stuck in a random screenshot. Later as I was browsing other people's submissions I realized that if I saw this game's "logo" in a big list like that there's no way I would ever click on it. This is a zero-stakes game jam so there's no particular reason to do any marketing but even so it would be nice to make the game look at least somewhat interesting. So I replaced the logo with a more composed image which is at least slightly attractive. Next time I'll think more about how the game presents itself in it's metacontext.

 Level Design
Aside from sound and music, level design is probably the aspect of game development I'm worst at.  I feel like I actually did better on this project than past things because there were a few moments where I had some flow and sense that the player was actually playing the level rather than just walking through. But still, it's hard and I left most of it for the last few hours of development which means there isn't much in the final project. Plus I hardly used the core idea of changing scale and destroying terrain in the level design. It happens as you play the game, but only in a couple of places is it based on choices the player makes and that's no fun.

 Wandering Off Concept
I managed to stay pretty focused during this project, but not focused enough. The game is about changing scale but I got distracted by a few other things. I added the collectable cards near the end because I panicked about how little direction and motivation I was giving the player. That was a mistake. I should have taken the time I spent working on the collectables system and focused on just developing the exploration oriented gameplay. I also realized part way through that I could change the player's scale independently on the x and y axis. In a longer project I'd love to explore that more. In this tiny project it was just a distraction. It's not an interesting enough extension to the core mechanic to justify the time I spent on it.

 Conclusion
I'm pleased with what I made for all it's shortcoming and I have a clear idea of what I want to focus on next time. I call this a success and I'm already looking forward to the next one.