Dice Druid

You play as a Druid, platforming his way past several hostile knights and treacherous rivers to find the Golden D6! Use collectable D6s to open gates, and use your staff to defend yourself against the knights trying to stop you.

• Unreal Engine 4 Editor

• Narrative Design

 • Blueprint System

• QA Testing

• Level and Environment Design

• Leadership and Production Skills

My team was off to a rocky start for the Game Maker's Toolkit 2022 Game Jam, since two members of our four person team dropped out a few days before the jam was due to begin... 

This would be the first in a series of hard-learnt lessons for me over the course of this game jam, namely: 1/ Ensure everyone is prepared and set-up *before* the project begins. As well as,  2/ When problems occur, you must quickly re-organise, adapt to overcome, and roll with the punches in whatever form they may take.

This was, unfortunately, not the end of our problems, rather the beginning. Even though this project could be regarded as a failure overall, I have included it to highlight the important lessons I learnt because of it and how we can gain just as much from our mistakes as from our successes. 

As soon as the theme for the game jam had been released ('A roll of the dice'), my remaining teammate and I began by writing a list of buzzwords that we wanted to reflect the feel of our game: 'Risk', 'loss-aversion', 'strategy' and 'randomness' were what we settled on. 

We planned out a narrative-driven, choice-based, murder mystery game set in a mansion on a stormy island. We wanted to have a whole roster of fleshed-out characters, spooky cinematics, a custom-written musical score, and many branching paths / multiple endings depending on player choice. 

In other words, we fell into the most commonplace and basic trap that designers face - we over-scoped. A project of the size we'd planned would've been a serious stretch for our original 4 person team in the 48 hours we had to finish it, let alone the 2 man team we now had. 

This is where lesson number 3 was learnt: Scope small, even smaller than you think!  

Having decided to make the project in Unreal Engine 4, we wanted to set up some version control and a way that we could both work on the game from separate computers at the same time. This is where lesson number 2 and lesson number 4 came into play. After 6 long hours of trying to get the software Perforce to work, we realised we should have set it up before the game jam started (qua lesson 2) and that we had just wasted roughly 15% of our total development time for absolutely nothing. This is where lesson 4 was learnt: If something is not working, do not bury precious resources into it - scrap it and find another solution!

Realising that we would only be able to realistically work on one computer at once, we were forced to rescope our original project into something much, much smaller. We settled on a puzzle-platformer concept with simple combat mechanics but a less simple dice mechanic that would still satisfy the randomness aspect of the theme. 

Once we had rescoped to a much more achievable vision, we managed to pick up some steam and set about creating our puzzle-platformer. Between us, we managed to get the character jumping and running (with animations), the camera to follow the player, enemies that would attack and do damage, a spell-casting attack, a dice block above the player that would increase with pickups, and gates that would only open if the player had the right dice face. 

I laid out a level design based around the main mechanics we had settled on: Jumping, exploration, combat and puzzle-solving. I made sure that there were some challenging platforming sections and a few hidden pickups to ensure that the player would have to hunt around before proceeding to the next section. 

Time was swiftly running out and, even though we had a more concrete game idea, we still had yet to turn it into a reality. In our rush to finish the game in the remaining time we had left, my team fell into yet another trap... we didn't budget our time properly. 

We ended up sinking a huge amount of time into making deep and robust systems (such as the player dice display and the enemy AI etc.) when we would have been better off using simpler design but making more of it. As a result, we didn't end up being able to even use the systems we had built much, the level was far shorter than it should have been, plus we ended up missing out the main mechanic that we had been striving for: 'Randomness'. 

As we wrapped up and submitted the game, we reflected on the last hard lesson we had learnt: 5/ Don't lose sight of the central game concept, no matter how many compromises and complexities arise!