Robots vs Bigger Robots – quick game design

After moving to Vancouver, I had perfectly natural concerns about removing myself from all my friends and colleagues in the UK and having to make new ties and bonds with people in a strange new city. I needn’t have worried – everyone on the game dev scene has been excellent and friendly and great company.

Looking for work has its perks. Sometimes, a friend will call you up in the middle of the day just to see if you want to go to the pub and make a game. A few cool things happened last Friday (hopefully more info on that later) and this was one of them.

A game of clicks and chance

A developer buddy, Cash, wanted to learn a new JavaScript framework (MobX) by building a little clicker game with it. He had a ‘coin toss’ system, where you had to click a button to toss a coin. You either win or lose the toss and are awarded a point if you beat your imaginary opponent over 10 tosses.

When I joined him, he was working on a system that would let you buy an item to automatically flip a coin once every n seconds – the start of a classic idle game system.

Everyone has their favourite idle game (it’s probably A Dark Room), but I quickly launched up a couple of them to remind myself of the feel and progression of these titles. They range in pace from furious clickers to games that suggest a little more strategy. Of course, patience is always a factor in these games

Starting work on the game design, I decided to first work out what Cash wanted to get out of his learning activity with MobX. He was pretty open, so I listed out the mechanics we had and the factors that influence those. Coin tosses with a win or lose outcome will yield currency over time. The amount of currency per second is determined by how quickly coins can be tossed; how many coins can be tossed concurrently; and chance.

I drew out a flow chart of the main interaction, tossing a coin:

This helped visualise the existing features and exposed parts of the cycle that could be modified. We can increase the number of coins owned; the points won after the toss; the chance of winning; and decrease the points needed to win a round. We can add auto flippers that flip coins for the player or start matches automatically, making the game easier to manage.

Something that doesn’t suck

We discussed ideas for a narrative to frame the game with a story or setting that “doesn’t suck”. Flipping coins… game of chance… why?… how?… Wizards?.. No…  Aliens?… Ummm… how about robots?

Discussing a more tangible setting sparked a few more ideas. You’re controlling a robot army by charging and firing their weapons to defeat… a bigger robot? Successfully landing hits yields cogs, that can be used to upgrade your own robots. I know, we’re narrative geniuses.

The game design now has two steps: charge and fire. The ‘coin flipping’ controls the rate at which your weapon charges and the firing occurs depending on whether you won your round (best of ten). I went through the process again, drawing out a flow of the mechanic and looking for things to mess with or upgrade. Some points were the same, but we can now add things like weapon accuracy or damage multipliers.

Design concerns

One concern I had about porting the coin flip system over to a weapon charge so literally is if the player presses a button to charge a weapon and loses the coin flip, nothing will happen. This is most unsatisfactory! The chance element seemed to have lost its relevance, which is a shame since this is a nice addition to the clicker mechanic. Your opponent is now at the end of the round (firing your weapon) rather than throughout the game (flipping a coin).

Rather than lose the chance element, I looked at my flow chart and decided on a new outcome for losing a toss – the player takes damage! Perhaps the weapon backfires or shorts out. This means there is now a risk attached to clicking the charge button – but this makes the reward of clicking feel greater.

Adding a damage system also provides more opportunities to control the upgrade speed too – perhaps robots on low health operate slower or stop operating altogether. It makes a simple clicker game feel more tactical.

I then updated the flow charts one more time so they look like this:

User Interface

To explain these ideas quickly to Cash, I drew out a quick sketch on paper, then worked a little on a first pass wireframe for the game’s presentation. I find this the quickest way to explain and document my designs, usually with a few notes around the edge of the diagram. Of course, I checked Cash was happy with this design, since he’d be the one implementing it!

Since this is a first pass, there’s a few things I’d like to change – firstly the presentation of items in the shop! This should be simplified to read “upgrade weapons, upgrade defence, heal” rather than breaking down accuracy, charge speed, etc. So many options with a large army of robots could quickly become annoying.

Future implementations

Of course there’s so much we could add to this – different robot types (tank, infantry, healers) or changing the a risk/reward system of the weapons so that firing a shot before the weapon is fully charged deals less damage to the enemy, but reduces the risk of a missed shot. No matter what, it’ll be fun testing and iterating on this over the coming months.

So there you have it – this is where the design is at. Still working on getting something playable online, but I’ll provide a link when it’s up. It was a fun Friday afternoon quickly throwing this stuff down, hopefully we’ll get to work on it some more and flesh it out!

Leave a Reply

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