The design of Gunslinger Duel - A Unity game for mobile

In the above screenshot we can see the basic layout of the game. The fire button, left and right dodge buttons, and yellow arc which is for kick sand.

In the above screenshot we can see the basic layout of the game. The fire button, left and right dodge buttons, and yellow arc which is for kick sand.

Last update: 9th April 2017

I've been working on a Unity game for mobile.  It's a small, simple game about pistol-duelling cowboys. This blog post will be part of an organic design document that will update and change as the game develops.

At its heart, it's a game about fast reaction times - whoever fires and hits the opponent first after 'Draw!' is announced, wins the round. If five rounds are won, the player wins the match and can move on to the next, more difficult opponent. But I wanted to go further than this and add some extra mechanics to make the game deeper and more interesting tactically. These ideas mostly revolve around a dodge mechanic and kicking sand in the opponent's face.

It takes its inspiration from a similar game, Ready, Steady, Bang! and games like Nidhogg, which are all about fast-paced duelling.

It's being written in C# and is currently in a prototype stage.

Design Issues and Considerations

Player Actions and Timing

The three main actions I want performed by a player and AI opponent require (despite the simple concept) a fair degree of thought and balance. There are a few design considerations and permutations I can go through by prototyping in Unity, and through focused user testing.

Each ability, or action, needs to be useful, in order to not remain redundant, and they need to offer a tactical advantage in order to make them relevant, interesting, and to add more depth to the game mechanics.

I'll break them down here, partly for illustrative purposes and partly to help myself in the ongoing design process:

  1.  Fire

  2. Dodge (left or right)

  3. Kick Sand

 

In fact we could condense these in to the classic and simple rock, paper, scissors format to make them relevant, easier to understand and to help in the design process.

For example:

  • Firing beats dodging, but loses against kicking sand
  • Dodging beats kicking sand, but loses against firing
  • Kicking sand beats firing, but loses against dodging

Note: My current thoughts about firing involves not requiring aiming, i.e. a player does need to move to dodge to the same horizontal position of their opponent and then fire to be able to hit them, this may change though.

This is kind of bland in design terms though and we need to know exactly how each action wins or loses against the other. 

As this is a game about reaction times maybe we could base each action on speed, e.g:

  • Firing is quicker than dodging but slower than kicking sand
  • Dodging is quicker than kicking sand, but slower than firing
  • Kicking sand is quicker than firing but slower than dodging

In terms of game mechanics, we could implement these actions as a delay from when the player presses the button to when the action is completed. But this doesn't really work, if we write this down we can see, for example:

  • Firing has a 0.3 sec delay
  • Dodging has a 0.4 sec delay
  • Kicking sand has a 0.5 sec delay

Firing is quicker than dodging yes, and dodging is quicker than kicking sand and slower than firing yes, and kicking sand is slower than dodging yes. But the others don't work: firing is quicker than kicking sand and, conversely, kicking sand is slower than firing.

Additionally, the rock, paper, scissors format doesn't quite work well here as only one of these actions (firing) will win the round. There will always be a follow-up action until one of the players successfully fires on their opponent. Rock, paper, scissors is also mostly based on luck, and I'd rather have this game be based on some kind of strategy, in which the player will be able to feel like they outwitted their opponent by calculating their next move.

Another solution

How about scrapping delay times and telegraphing to the player when each opponent's action is about to be performed? For example, an icon will appear showing the next action the opponent will perform, and the player will then have to quickly respond with the appropriate counter? The amount of time the icon will appear for will act like a reaction time; longer for easier opponents, shorter for more difficult ones.

We could still use the RPS format:

  • Firing beats dodging, but loses against kicking sand
  • Dodging beats kicking sand, but loses against firing
  • Kicking sand beats firing, but loses against dodging

And we're still basing the system on reaction times which is good, thematically, for a game about cowboy duelling.

We do have one issue with this system. What is the downside to being too late to respond to your opponent? If the opponent is firing, and we fail to counter it, then obviously we lose the round. But what if we fail to counter a dodge or kick sand?

Well I suppose failing to counter a dodge (the counter to dodge is firing remember), simply means the opponent has another try to outwit you. But failing to counter sand kicking? Perhaps I can factor in the idea of a delay before we're able to counter the next move, simulating the idea of sand temporarily disorienting us and obscuring our vision.  This can be thought of as similar to the 'silence' abilities in many RPGs that stop magic casters from casting for a certain amount of time; or stun grenades in first person shooters that temporarily disorient the enemy.

The best thing to do at this stage though, is to knock up a prototype to see how it could potentially work. I'll come back to this blog once a prototype is up and running.

Writing the win and lose functions for each match in C#

Writing the win and lose functions for each match in C#

Controls

Controls, I feel, are extremely important when designing on a mobile platform and especially for games that require fast reactions. Given the nature of touch screens and the possibility of buttons either not being hit, or not even registering a hit, it's important to make them as simple as possible. 

Having complex controls or many options and buttons is something a turn-based game can get away with, but this game is about fast reactions which makes it all the more trickier.  One-touch controls are ideal in fast paced games, but given my desire to have four separate actions available to the player this will prove difficult.