A GMTK Gamejam Postmortem

This is a small little game and I think a big reason for that is that my big plans fell apart. Which is fine — a game jam is essentially a big prototyping session and if none of your prototypes fail, you're not prototyping enough. But I think it's worth chatting about all the same. So!

Game 1

The theme for the jam was playing with size. I had a bunch of ideas, but the one that seemed to have legs was a game where you can absorb size from cetain objects in the game world, or transfer your size to them. Size becomes a stat everything has. So, for example, maybe there's a pit of lava an you have to get across it by riding some flying creature — but there isn't one nearby. That's fine, there's one across the map you can shrink down and put in a jar, Zelda-fairy-stylee. But oh no, once you've shrunk the creature down you're too big to get out of the cave it's in, so now you need to go get another tiny creature, take it into the cave in your jar so you can shrink one creature, then pour your excess size into the other so you can get out. It's cute. I wasn't sure if there were a lot of puzzles to be had out of it but I figured it could be mostly platformy with puzzles guarding secrets or something.

So how to make that game? There are basically two reasonable options — either a bare-bones 2D engine like Löve or Picotron (mad props to Zep for dropping the Picotron web exporter literally on the last day of the jam, absolute peak banter feature delivery), or something like Godot (since I'm not learning Unity now).

I figured I'd try Godot. I've put a couple of things together in it before so I'm not starting from zero, and I figured if we're going to have a lot of objects moving around and changing size then that probably suited Godot well. I can create a CharacterNode for each creature, and then just whack a scaling transform on them. Certainly pixel-art was out of the question in a game where things keep changing sizes, so Picotron wasn't going to work, and I've never really used Löve. Godot seemed like the smart choice.

And it probably was a smart choice, but I think the main thing I learned from making this prototype was that I do not jive with this Unity-like model. Not that it's bad per se, but that it doesn't suit me. And this is fine, right, it's not like I was going to create an amazing game on my own in one weekend and it's not like I can't do something with this idea in the future if I want to. If this is how I learn that Godot is not really for me then that's great, although I do kind of feel like there isn't a good 3D equivalent of Löve — something that will let you render a model and drop in a light but won't insist that all my code be divided up into "nodes" that exist somewhere in the game world and then attempt to run physics on them. I don't know, that model seems to work for a lot of people but I much prefer having a main update loop so I can control what happens and in what order.

When we break a webapp into microservices each service is simpler but the overall system is not, so all we've really done is move the complexity into the gaps between services, where we can pretend it doesn't exist, not document it, and nobody really thinks it's their job. Similarly we understand neurons really well but the brain, which is made of them, is a mystery. And I think it's also true that breaking your game logic into nodes in this way does make each unit simple and self-contained, but if anything goes wrong at the interface, it's much harder to fix it because it's not really clear where the fix should be.

I think part of the issue is I want to do interesting things. I want to make games where you can resize things, or where the geometry is messed up, and I tend to find that using a tool like Godot always ties you in somewhat to doing the kinds of things the tool expects you to do, whereas even something much more limited like Pico-8 allows you to do aynthing you have the CPU cycles for — I have made a non-euclidean 3D environment in Pico-8 and I don't know how I could do that in Godot, at least, not without just building my own 3D engine within its 2D renderer (which would of course be ridiculous).

So yeah. I don't think I'll be creating a game in Godot any time soon — but I'll keep it around. It's a useful tool for certain things. I used it the other week to create a little 3D puzzle with basically two scripts and that worked really well. It's the complex real-time interactions I don't like it for. I need to see the main loop and I don't understand why anyone would not want that.

Game 2

I'd basically intended at that point to give up on the jam — I don't want to just sit and hack on something for the sake of entering a jam, I enter them because I like the "here's a theme and a timebox" hit. It's equal parts inspiration and excuse to create something. But if the inspiration doesn't land I'm not going to force it, and it was pretty clear I wasn't going to be able to do the idea I'd had in a way that worked in the time, so that goes on the back burner and I'll take the weekend off.

And then my brain started designing this game without my asking it. I've done a few Wordlevanias before — Cell Tower, Celtix, and 3Doku — so this is a natural fit for me. What I find with these things is the trick is to find a search-space that's large enough to be interesting, but small enough to be do-able. Wordle's search-space is if anything too small — it absolutely gets away with it, but generally you should be aiming bigger than that — and Scaled to Build's is categorically too large. Level one, Ooo (the levels are named by the blocks in them), limits the search space a lot by having very few blocks and they're all the same shape, but by the end each block can be in many places and four rotations and at seven different sizes and there are six-to-eight blocks, and no real indication of when you're on the right tracks. It's possible there are some better puzzles to be had in this engine, but my suspicion is this is just too many dimensions to be looking through. That's OK, I think I'm going to treat this as a prototype for a game that will probably never be built out, and I'm sure a few people who like a hard puzzle will get some fun out of it.

It's possible also there's a better game to be had with this premise. Perhaps if it worked more like a Tetris thing where you're trying to fill the space and you have to put each block somewhere — if it doesn't fit then you need to shrink it and that makes the shape you have left more awkward? I don't know, I didn't have time to explore that but it could be fun.

Oh well, I had fun building out these two little ideas this weekend, but I don't think either is likely to become a fully realised game.