DrillBit was my first ever completed and released game, an achievement that I'm extremely proud of.

The game (in its current state) is not without its issues though, and I'd like to share with you a teardown of the game, its development process, the issues it currently has, and the changes I would like to make moving forward.

The (Quick) Backstory

As a child I always wanted to make games. I bought a book "Teach Yourself Game Programming in 24 Hours", after 5 pages of the book I was already disheartened. Around 6 weeks ago (late June 2019) I decided to make that childhood ambition come true and begin work on a Harvest Moon / Stardew Valley clone called "Lunar Pioneer", which is coming along really well.

I have followed GMTK on YouTube for a good while now, so when I saw the announcement of a Game Jam, I know I had to take part. Add to that the 48 hour time constraint and well, that means in a weekend I would finally realise that childhood dreaming of making and releasing a game people can play and, hopefully, enjoy. 6 weeks of course isn't a long time to get familiar with a game engine, and I still have an incredible amount to learn, but I'm a programmer by trade and picked up GameMaker quite quickly.

The Development of DrillBit

I actually started the GMTKjam with a completely different idea in mind -- a metroidvania where your character had a magic arrow, but only the one. The arrow could be shot into walls to create platform puzzling elements. I was about 3 hours into development of that untitled idea when I realised I was out of my depth, and should try an idea that is more achievable by a one-man team.

The result of that, was DrillBit. An infinite-runner controlled with just one button.

My development process is quite standard I imagine, but I'll list it out regardless so that you know how I chose to tackle this project. I would love to hear from anyone that has any resources regarding project management for games.

1. Create placeholder sprites (literally coloured squares) and begin setting up the character that will be controlled.
2. Work on character controls, and focus on that feeling good and correct before anything else (more on this later).
3. Begin adding threats to the game, in DrillBit, these are the blocks and obstacles that will kill you.
4. Adding collectable, incentives and power-ups for a better player experience.
5. Polishing and balancing (more on this later) the gameplay.
6. Adding art, transitions and animations.
7. Adding background music, sound effects and really trying to juice up the feedback the player receives.
8. Adding more juice and feedback in screen-shakes, player shake etc.
9. Code run-over, optimisation checks, spell check and final testing.
10. Release!

A challenge I faced early on in development was, how to handle the kill blocks which are moving up the screen? I tested out an array system to design the blocks in (boolean values in each column) which the game would iterate over and produce the blocks. In this way the blocks would be made up of individual objects. I ended up using this system for the pickup items but not (currently) for the killing blocks.

For the killing blocks I simply designed the layouts in Aseprite, imported into GameMaker and set the collisions to be precise. To avoid a horror show of wasted memory, all objects are destroyed on the frame that they leave the top of the screen, and without too many objects on the screen at once, the optimisation seems to be reasonable.

I decided early on that the control scheme would be tap to move fast, and hold to move slow. This made DrillBit EXTREMELY difficult, but at the time I felt that the game would be fun with a steep learning curve (more on this later).

Current Issues in DrillBit

There are issues in DrillBit I was aware of when uploading the game, but given the time constraints of the game jam, I didn't have time to fix. This was the difficulty balance of the game, its simply too punishing and ruins the fun for a lot of players.

There's also other issues that have been brought up since by the community which I definitely agree with; the control system is intuitively inverted - it would make more sense to move slowly on a tap, and fast after a hold. This control system has now been tested and it both works nicely, and also makes the learning curve of the game significantly easier (more to follow). What's funny about this is I spent quite a long time working on the control system and getting the speeds correct, but, blinded by my own want to keep pushing forward, I hadn't really considered that the current control system was unintuitive and making the game a lot harder than it really needed to be.

Another mentioned issue is that our main character, DrillBit, can't actually do any drilling! I definitely need to resolve this so I feel that a third power-up may be required to let DrillBit finally drill.

Lastly, another valid point is that the game needs some more set pieces, some more block configurations and just something to mix it up a little, otherwise there isn't much longevity.

Feedback is the most useful and important thing to me right now, so if you have any further feedback to provide for DrillBit, please do so, I welcome it and will do my best to respond to everyone.

DrillBit Moving Forward

Thanks to the community I feel like I already have a huge list of improvements to the game to move this forward. I think each of these will add real value to the overall enjoyment and accessibility of the game, without impacting those who prefer a challenge.

1. Create an inverted control system. The default is tap for fast, hold for slow. Inverted would be tap for slow and hold for fast. I have tested this scheme and it works nicely, and also makes the game more simple.
2. With #1 in place, I'll add an option for easy or hard mode for the game, each mode based around one of the control schemes.
3. I want DrillBit to drill, so I'm thinking that a power-up that will supercharge the drill will allow the player to drill through the barricades and earn points. With this in mind I could also design some new barricades around this mechanic.
4. Add increasing difficulty whilst playing. I would like to setup score thresholds which will increase the movement speed of the game to increase the pressure as the player is getting a higher and higher score.

That's it for now, I'll edit this post-mortem if I have anything else to add or say on the subject.