Miner Taur postmortem

posted

This was the first time that we had used Godot for any project that we intended to complete and deliver. Both of us are mainly experienced in Unity, so it was always going to be a challenge to both learn an engine and get the game done. But hey, what are jams for except pushing yourself a bit? Onto the game!

We had a vague idea of what we wanted to achieve, and it consisted of two loops: inner and outer. The inner loop was the Breakout gameplay, which was to be simple enough that the player could idle it if they wished. That simple inner loop would feed resources into the outer loop of the player character sitting at home on their mobile phone, ordering dumb stuff and gambling online. Unfortunately we ran out of time to implement the outer loop so we ended up focusing entirely on polishing up the inner loop and making it feel good to the player. You can still see a tiny bit of teaser for the outer loop in the last .gif in this post, though!

The very first thing I did when programming the gameplay once I had collisions sorted was to add hitflash, hitstun, and camera shake on impact. Why do this first? In my previous game jams, I always ran out of time to implement those effects that make a game feel crunchy and nice, so I wanted to get at least a few of them out of the way early. Not only that, but it also makes the game instantly feel good while you’re developing it, which can be really motivating! Hitflash/stun is a bit hard to capture in .gifs with the framerate, but you can see it popping up every now and then.

While we started out with our character moving linearly and bouncing off walls and objects, I wanted to give the player some kind of limited input into movement. In the below .gif you can just make out an arrow that points in a direction determined by the player mouse position. When the character hits an object that isn’t an outer wall, they will move in the direction the arrow points. This was intended to give the player a small amount of agency but still be chaotic enough (when multiple impacts happen in a short period of time) to introduce some fun ‘panic’ moments.

It’s a bit difficult to see in the .gif, but initially we restricted the new movement direction to a 90° arc in the direction they were travelling at the time of impact. The idea was that players would need to be a bit strategic about how they went about hitting each object to be able to direct themselves. But in practise we kept widening the arc up more and more until we decided to get rid of it and allow the player to move in any direction on impact. The restriction didn’t add anything to the gameplay other than a bit of frustration on the player side, so it was an easy one to let go.

The next effect that we added was a slowdown when the player approahced objects they could collide with. This was an effect that had a significant effect on gameplay; we thought that players needed a bit of time to decide to react and decide which way they wanted to bounce off, and this gave them that time. At first I used an area-based solution with a circular Area2D that slowed down the player while they were inside it (you can see the areas exaggerated in the above .gif). But that resulted in a strange feeling of the impact being muted by the pre-impact slowdown. You can kind of see that in the .gif below where it slows down for just a touch too long pre-impact.

And that was just about it! There’s a few more random things we included/subtleties that I’ll quickly list here:

  • Each ore type will randomly generate opal types on hit, on a weighted scale where more valuable opals (fire and black) are rarer. Each ore type is also generated randomly on a weighted scale, with the ones that are more likely to contain rare ores being rarer themselves. All of which is to say that the score is kind of random, but there’s some skill to knowing when to move on once you’ve popped all the more-likely-to-contain-rare-opals ore.
  • Black opals and fire opals give you a small time bonus when picked up, as well as being the more valuable opals. We had initially tested giving a time bonus for all opals, but we couldn’t tweak it quickly/accurately enough to be assured that players couldn’t play forever easily. So we reduced it to just the highest value ones, and very small time bonuses.
  • The arrow will only appear when you are on a collision course to hitting some ore. This was a design choice to make sure players were being reminded that they need to choose a direction. Not sure how to put this feeling into words exactly, but when the arrow was always there, I found myself getting complacent. But if it comes and goes, but is only there when a choice is immenent, it made it feel more compelling? Not sure what to call that, but it seemed to work! The way we did this was just with a shapecast the same size as the player’s collision box stretching ahead of them by some amount of pixels.

One thing that was somewhat intangible but that I really appreciated was the in-built code editor. I’m someone who struggles with distraction when sitting at my computer, and for that reason not needing to switch windows and introduce that split-second of ‘oh I’ll just go check this other tab before I switch to VSCode’ was a huge benefit. The code autocomplete was annoyingly slow until I was informed that this is literally a setting you can change in Godot (Editor -> Editor Settings -> Text Editor -> Completion. There are “Idle Parse Delay” and “Code Complete Delay” settings). Overall we really enjoyed working with Godot, so much so that phloup are going to be using it for our next few projects! Even if they end up just being janky game jam games.