Myrmex Hollow - A self critical review

As of writing this review, I’ve recently completed development on my first original video game, which I have called Myrmex Hollow; “myrmex” being Greek for “ant” (or so I’m told). I think I’ve always had an interest in making my own video games, ever since I was about 8 years old drawing levels for my own Oddworld games entirely on paper. But my interest in creating video games was re-invigorated as an adult by Yahtzee’s Dev Diary series on The Escapist. I had a few interesting ideas floating around in my head regarding something I could potentially make and one came from my playing classic 90s shooters.

A couple of years ago I started playing a lot of the classic 90s shooters, such as Quake, Duke Nukem 3D, and Blood. I was already a big Half-Life fan and had been for many years and I had played a lot of the original Doom in the past too. But I found myself thinking; in Doom you fight demons, in Half-Life you fight aliens, in Turok you fight dinosaurs, in Quake you fight interdimensional beings, in Wolfenstein 3D you fight Nazis, but what about a shooter where you fight giant insects? Insects are terrifying up close; seeing them under a microscope can be the stuff of nightmares. Well, that’s what the thinking was anyway.

After getting myself a 1-month free trial for GameMaker Studio 2 from YoYo Games, I took myself through some of their YouTube tutorials and ending up making myself an Asteroids clone. I then bought a year’s development licence for GMS2 and proceeded to make a Breakout clone, a much more detailed Asteroids clone, and the ground work for a 2D platformer. Using this ground work, I decided to take my 90’s shooter idea and create a Metroidvania-style platformer out of it. This plan was far too ambitious for someone who had only just gotten himself into game design, so the project was swiftly cut down to the short 20-minute game that I’m about to release; I was losing interest in the Metroidvania genre anyway.

So the result of this whole process is Myrmex Hollow, a game about giant ants destroying the surface of the Earth... somehow. Yeah, the story of this game is kind of daft, but I was really taking an attitude to video game story similar to that of John Carmack who once was quoted as saying “story in a game is like story in a porn movie. It’s expected to be there, but it’s not that important”; so in the end I wrote a load of story to fit in between the six levels, thought “that’ll do”, and left it at that.

As for the gameplay, I was actually designing the gameplay with the game Poacher in mind, Poacher being an indie game from the previously mentioned Yahtzee Croshaw also made in GameMaker. So Myrmex Hollow is a 2D platformer putting the player in the role of a little man (who I briefly refer to as Gerald in the credits) armed with a massive sci-fi gun. You can move left and right, as is expected; you can jump, as is also expected; and you can shoot, as is definitely expected. I also included a grenade feature, but I’m not entirely satisfied with its inclusion, they’re only really useful in the first boss fight, and given their over abundance in level 1 where all the enemies die in one hit, they could have been handled a lot better. Another gameplay complaint I could make is that I probably relied far too much on the “gun-jump” mechanic; in fact you probably shoot more at the ground throughout the game than you do at any of the enemies. But I digress.

As I said, there are six levels to this game, but the level design isn’t anything to be marvelled at. Levels 1, 2, and 4 are the more standard kinds of levels with a starting point, an exit, and a bunch of things to shoot in between the two, or in level 4’s case: things to run away from. Levels 3 and 5 are the boss fights and with these I’m pretty happy at how they turned out. I’d hardly argue that they’re any good, but given that I’ve never designed a boss fight before and with the assumption that they’re a tricky thing to pull off effectively, I’m satisfied at the results. The level 3 boss fight does drag on a bit with the player having to get in shots whenever they can while mostly avoiding the regular enemies that drop in from above, and the level 5 boss fight I think was a bit too short once you know what you’re doing. But equally I think level 5 is a bit unchanging and repetitive once you know what you’re doing too, so I was stuck between deciding to lengthen it out to make it last longer, but possibly leading it to becoming a bit boring; and just leaving it as it is despite it being fairly short. In the end I figured it might take players a while to figure out exactly when to do what with good timing that I thought it might drag it out a bit.

If anyone does want a cheat sheet for level 5:

·         Stand on the lower platform on the left (or right, but I’ll start with the left for this guide) and shoot upwards; you’re aiming for the scar on the mandible or the eye if the mandible is already destroyed

·         Jump to the outer platform just before the acid attack starts, it might take a bit of practice to know when the acid attack is fully charged

·         Jump back to the lower platform just as the acid attack stops to avoid being stomped on; ignore the ant that drops in for now

·         Jump across to the lower right (or left) platform and repeat what you’ve done so far

·         After the second acid attack there will now be two ants on the outer platforms, having just been on the right (or left) side of the screen, you want to be on the lower left (or right) platform, but before you jump down, stay on the center platform and shoot the ant on the side that you’re heading for.

·         If you have a grenade you can destroy the ant from the lower platform when looking up, just make sure you’re facing the right direction.

·         Once both mandibles and eyes have been destroyed, your next target should be fairly obvious, the procedure is more of less the same but stay on the central platform to shoot upwards.

Follow this guide and level 5 will seem really easy after a bit of practice.

Anyway the final level 6 is a simple timed escape, the player has one minute to climb up a vertical shaft (which I refer to as a highly convenient escape tunnel in a somewhat roundabout reference to Fable II). Do this in time and the player will emerge blinking into the sunlight of the countryside.

So that’s a basic overview of the game, but how did I find the process of game design? There was a lot of fun, but also a bit of frustration. Taking things in order, I found that the drawing of sprites could be kind of fun if slightly challenging for someone who always avoided drawing things in school, but I don’t think anything looks particularly bad, or at least everything is consistently bad and therefore nothing stands out for it’s bad-ness. Animation of those sprites on the other hand was a bit more tedious, you can notice that neither of the bosses have much animation, the second boss has the animation of its head tearing open which I think looks okay, and they both have death animations, but little else. I also didn’t do a good job of syncing the walking animations with the object movement speeds. But at the end of the day, I don’t think how it looks is particularly important, it plays as I was hoping it would which brings me to the programming.

Programming was probably the hardest part of the development process, because it’s a skill that I’ve had to learn from scratch over the course of the past year; although I’ve never done any sound design either but that was a lot of fun. There were a lot of frustrating moments when I was just looking at my code yelling “Why isn’t this working!!!” And there’s almost always something you’ve over-looked, so once you get your code to work, you start to test it and realise that you’ve missed something out so you have to fit in a single line of code somewhere into the tangle you’ve already gotten yourself into; usually the line is just an if() statement and the word “exit”. There was the one specific moment that was starting to piss me off was the enemy AI (AI being a term I use loosely), but the epiphany came when I remembered that code is read by the engine line by line rather than all in one go. In the end, all the code I need to work worked (hence the fact that I’m releasing the game at all, obviously).

I had an enormous amount of fun with the sound design, despite having to learn from scratch. I used both stock sound effects from freesound.org and some that I created on my own. For example, the stomp sound effect that plays during the second boss fight was created by me slamming wrist down on my desk then slowing it down to 25% of its original speed. Realising that this worked felt great. But I think the most interesting use of sound design was for an ambient sound effect for the final level. During the escape you can hear the sound of the cavern starting to collapse and the distance clunky stress of the cavern walls. That was the sound of a rocking chair slowed down to 10% its original speed.

Now, this game is short. I’ve timed myself playing it and I can beat it in 12 minutes flat. But this game is essentially an audition piece. The audition being “can I actually make a functioning game?” Except the only person I’m auditioning to is myself. And I think to my own satisfaction I can say “yes, I can make my own functioning game”. It’s not a particularly long game, or even a particularly good one, but I think I could now safely call amateur game development a hobby of mine.

EDIT: shortly before I was going to release the game on itch.io I discovered a minor bug regarding grenades and checkpoints. Basically, when the player is touching a checkpoint the game is saving every frame until the player stops touching the checkpoint; this would be fine if it wasn't for the grenade count. If a player fires a grenade after reaching a checkpoint, but before moving away from it, or if they fire a grenade and then pass back through a checkpoint they've reached before, that grenade will be lost to the player. I figured that adding in a piece of code that allows the checkpoint to save only during the first frame of the checkpoint's animation, then the problem would be solved. Unfortunately I soon discovered that this would, for some reason, cause the player to spawn at the checkpoints corresponding coordinates in the next room after they reach the end of a level. I have no idea why this was happening but the original bug was only a minor inconvenience, while the fix caused the game to break, so I decided to leave the bug in.