From Nothing to Something to Something Else

[vc_row bg_color=””][vc_column width=”1/6″][/vc_column][vc_column width=”2/3″][vc_column_text]

What is ‘That’s My Jellybean!’

TMJ (That’s My Jellybean!) is a tower defence game with an affinity for the wacky and the wonderful. While at its core TMJ is a tower defence, the game was designed by a team that all dislike the genre, this initially lead us down a very different route for the game. This post will delve into process in which we came to the “final” design (certain aspects are ever evolving) for TMJ.

A Lucky Failure

The project started off as a 2nd year university group assignment, it was pretty broad but basically came down to: make a tower defence game with an AI system in place (this needed to be more complex than just simple enemy agents). Being young, bright-eyed and naïve we immediately started designing our game with little thought to any of our limitations (it’s worth noting the team was comprised of 4 inexperienced programmers), what could go wrong.

We started off talking about how we can revolutionise the genre, adding the depth and complexity that the genre has evidently been missing. This led us to layering mechanics from other recent popular games, mainly looking at the zombie genre, because the world clearly needed another zombie game. We felt that the experience needed to have meaning so we wanted to offer the player moral choices (a couple of us had just played Telltale’s The Walking Dead).

Telltale's The Walking Dead

Telltale’s The Walking Dead

We intelligently pointed out that this was not a large mechanical feature and that we needed to expand on the gameplay. We decided that in a zombie world it’s all about survival so we need to have the player go off and scavenge supplies to feed their people and gather resources to fortify their base.

We continue along this line starting to talk about story, UI etc. (we haven’t really spoken about the actual tower defence mechanics yet) It’s getting late into the day and we have a decent sized set of “refined” ideas and concepts, to the point where we should move on to the next step. At this point there is an awkward feeling in the air and after a few seconds of silence the question “Does anyone actually like this” is raised. After another few seconds of silence eventually a timid no is thrown into the fray from one of the developers, this is then echoed by all the other team members.

From The Ashes

With our previous design now in the bin (where it belongs), we got a new piece of paper and shared a laugh at the last several hours. Having hated our previous attempt we started what I like to call ‘Design by Hate’. We started by looking at what we dislike with tower defence games, agreeing on 4 core elements:

  • Slow game play – After setting up your turrets you end spend a lot of the game simply watching the game unfold.
  • Overpowered turrets – While cost to create may differ, there is an obvious ranking in terms of strength for most turrets.
  • Boring Turrets and Enemies – Quite often you have multiple versions of the same turret (i.e triple shot turret).
  • Predictable – Usually you can see a lot of how a level will play out at the beginning (i.e predefined paths).

To combat slow game play we decided that the rounds needed to be short, this would allow us to still have certain pre-defined circumstances and endless modes, but we could split them into small sections to control the pacing better. This alone did not feel like enough to make the game feel dynamic though, this led to the addition of ammo to turrets. This would mean that when a turret runs out of ammo it disappears, no longer allowing the player to passively just watch the game unfold, but forcing them to constantly interact.

The introduction of ammo felt like it would help with the idea of overpowered turrets, but it felt like we may deter players from picking higher cost turrets. To counter this we decided that kills would earn the player money to buy turrets, so a powerful turret would have the potential to provide a better return. This then also added a nice player choice in which the strongest turret may not be the best turret as the preferred move would be picking a turret that provides you the best kill (money earned) – cost. An example of this is a turret that say does 10 damage and costs 20 gold, is a bad choice to fight an enemy with 1 health that returns 10 gold.

Boring turrets and enemies was probably the easiest problem to come up with a solution, essentially we decided to ban turrets that do a basic modifier on an existing turret, so no fires two shots instead of one, this one has extra health or does fire damage. This meant that we would have a smaller roster, but all enemies and turrets would have defining mechanics to differentiate them from each other.

Mutators from Unreal Tournament

Mutators from Unreal Tournament

Last, but not least we had the problem of predictability for this we decided to borrow an idea from another game: Mutators from ‘Unreal Tournament’. We wanted to have ways to modify the core gameplay on the fly, maybe half way through a round the player now has to manually fire the turrets or maybe all the enemies just become sausage dogs. We wanted to have some fun with it, we were rolling with the mantra: the wackier the better, then we can filter this down later. After shouting a couple really stupid ideas for what we were now calling improvs and laughing how crazy some would work together, we decided that we would have 3 different improvs run in conjunction to hopefully create some awesome emergent gameplay scenarios.

So Let’s Make a Game

As this post is starting to become pretty big I’ll go into more detail in a later post, but to wrap up, after a really fun and productive session we realised that we needed something to actually defend. Someone shouted out jellybeans as a joke and with that ‘That’s My Jellybean’ was born.

[/vc_column_text][/vc_column][vc_column width=”1/6″][/vc_column][/vc_row]

Leave a Reply

Your email address will not be published. Required fields are marked *