How To Design Minigames

Sometimes when you're working on a cool little video game, you'll come to a point where you're thinking about adding a little minigame to spice up an otherwise boring mechanic.

In my experience and as far as I can tell, usually this happens to bridge a gap in the wider design of your game. For instance, let me give an example using my own game.

In WARP-TEK, the gameplay is basically one really long journey interspersed with boss encounters. This is cool and everything but there is a problem with replayability- if the player is made to replay the first 10% of the game like a thousand times, they're gonna get really bored and run into the same issue that a lot of games, specifically roguelikes, run into- repeating content is not fun, and eventually repeating the same content enough actually becomes a deterrent to be weighed against the promise of something cool happening later on.

So in light of that, I thought a bit about how I would fix this, and I decided that the player would have to be able to skip over areas of the game that they've already played through a gazillion times. Of course I can't give this one to them for free- that'd remove like all of the challenge. So I decided that the perfect thing to fill in this gap would be to add a nice little minigame.

So it took me like two days to actually design and implement this simple minigame- all I ended up doing was making it so that the player can skip to a maximum of 80% of where they left off. There's one of those bars where the fill moves up and down, and the player has to press any key when it's as high as possible. This is still pretty easy but it's simple, quick and feels pretty nice as a little downtime between playthroughs.

If anything, the biggest flaw with this minigame is that it is too easy- with a bit of practice, I'm sure you can reliably hit 80% of where you left off every single time.

For what it's worth at this point - and this is probably a little bit more programmery than you might care about - the fill doesn't move up and down in a perfect sin graph as you might think to implement it. It's actually sin cubed, with a little bias to make it move away from the top values a little bit more quickly than it does the bottom values.

Anyway, back to design. What other considerations were there when making this minigame? Well, it couldn't be too tedious. The whole point of minigames in this context is to break up gameplay and make things a little bit less tedious. I considered doing a continuous "endless runner" type thing initially, where you have to dodge progressively more numerous obstacles until you eventually lose and you're placed into the game at the point that you lost.

This wasn't a bad idea but it could easily become tedious in itself if the player plays it enough. There's really no promise of variety and it would by necessity judge the player based on how long they can survive playing the same thing for maybe 20 or 30 seconds or so. That doesn't sound like much time, but in aggregate it could mean making the player play shitty Flappy Bird for upwards of 5, 10, 20 minutes over the course of beating the game.

There used to be a minigame in WARP-TEK that was such that right before you kill a boss, the camera zoomed in on your ship and you had to run around and activate all 4 power cores to fire a huge laser beam which finishes the big enemy off. If you took too long to do this, the boss would regenerate a little bit of health and you'd have to go again.

It's not a bad idea and I'm still not sure I hate it - I've actually got a switch that just disables it, the code and assets are still in the game just waiting for me to change a boolean value - but it does take a bit of time and it's really just the same damn thing every time. It's not super interesting or varied and while I love minigames conceptually, you have to keep in mind that they have to be either fun in themselves, or so tiny that the player doesn't have a chance to get tired of them.

That's all I've got for this video I guess, I hope you gleaned something interesting from this video. Thanks for watching and stay tuned for more videos about things I'm still despite my best efforts not qualified to talk about. I saw someone do a reddit comment one time saying that all my videos are "weak points" and I beg for subscribers at the end, so I guess fuck that guy and please subscribe to me. Goodbye!

Ludum Dare 43 Post-Mortem

I'm kinda jumping the gun on calling this a post-mortem since at the time of uploading this video, Ludum Dare 43 hasn't even finished yet. But hey, I already finished my submission and based on my schedule of uploading a video every 3 days, this is the best time slot to make this.

So for those of you who don't know, the theme was "Sacrifices must be made". I used a word processor to jot down a few ideas, and soon enough I came up with the idea that the player has to protect a small population of people from a bunch of oncoming enemies, but they can also sacrifice a member of the population to get stronger.

And that's the premise of my submission, you kinda have to balance having citizens to protect - if they all get killed or sacrificed, then the game's over - with your own power. Also, the enemies get progressively stronger as the game goes on.

So how did development go? Well, I originally intended for the art to be a bit more interested and varied than it ended up being, I thought hey I can do medium quality art in a relatively short time, so why not? However, by the time I put pixel to... uh... computer screen, I ended up with some real minimalistic sprites.

This proved to not really be an issue since it looks perfectly respectable, and on top of that took me like an hour to create.

As for code, there was a bunch of algorithmic type programming which is my absolute favourite type of programming. For instance, moving the selection cursor between citizens to determine which one to sacrifice was real fun to program, though I did spend about an hour working through one annoying bug which in retrospect, was way more time than I should have.

Another nice one was determining how the citizens should wander around- I went through a few really complicated solutions until the really simple "generate a random point to walk towards, then once they reach that point just generate a new one" system popped into my head.

Overall I'm really pleased with this Ludum Dare submission I gotta say, it's probably my best one yet in so far as its design goes. It's probably got the most replay value, and miraculously the music turned out sounding pretty decent! For the first time since that one music track from Mushroom: The Ruckus... I can't remember what it's called, but it was pretty good.

I also feel like in this Ludum Dare, I paced it way better- previously, I'd have like almost the whole game finished on Saturday, then on Sunday I'd only have audio and a few tweaks left to do. This time, it was much closer to a 50/50 split- probably on account of how much work I had to put into this one as compared to my previous Ludum Dare games. All in all, I put just under 16 hours of work into this Ludum Dare game.

Thanks for watching and stay tuned for more videos about games that I make, some of which are Ludum Dare games and others which are like real proper big games.