It's awesome. Also, this is a test.



Deathmatching John Romero

‘They say never meet your heroes, but shooting them in the face with a double-barrelled shotgun is probably a good way to break the ice.’

I’m paraphrasing slightly, but that comment by a friend on a recent Facebook post of mine basically summed up the events of last Saturday, and it was glorious. 

Last week I was lucky enough to win a competition to challenge John Romero to a Doom II deathmatch at a tech event in London.  Doom is an immensely important part of my life, and John Romero is of course an immensely important part of Doom. Doom planted the seed of interest in to what was to be my future career in game development, not only because it was an incredible game, but also due to its strong support and capability for modding. I've also written about Doom before on this site back in 2015, but more specifically about my concerns for the 2016 version (which fortunately were misplaced as the game turned out to be great).

I was around 12 or 13 years old when the original Doom was released and I remember being blown away by it.  It was - and still is - fast and visceral, and it paved the way for a whole new genre.  I played both Doom I and II to death and spent hours poking around its innards, discovering new ways to mod and play it.  I once thought I was a genius for extracting the sound file from the Icon of Sin map, the final level in Doom II, reversing it to discover the immortal words "To Win the Game you must Kill Me, John Romero".  

So with Vanya, Steve, and Alex in tow I donned my UAC attire and dove in to what was, inevitably, a massacre at the hand of the master of Doom himself.

To Win the Game you must Kill Me, John Romero

It's safe to say he absolutely annihilated me, as he did the rest of the competition; he took everyone apart with calm, surgical precision, and he plays with a seemingly frame-perfect accuracy. The very fact I got two frags on him, despite his twenty against me, means I can now die a happy man. It's also curious - as his wife Brenda was telling me later - that John is probably one of the few people who is a pro-gamer at his own game.

Both Romero and Brenda are very welcoming, lovely people, and it was pretty damn humbling to be in their presence. It was amazing just to meet him, let alone face off in the very game that made us both who we are.

Achievement unlocked: Deathmatch John Romero (and die horribly of course)

I'll leave this with the moment I first fragged him. I should get this mounted or something.


Here's the gallery of pics below; I really do pull some weird faces when gaming.

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, 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.

Quadratic Bezier Curve Demo

I’m enjoying some of the maths that goes in to scripting and thought I’d branch out a bit by trying my hand at mathematically formed curves.  I made this in GameMaker and you can see a demo of it above.

Read More