Level Scripting in Max Payne

What follows is an outline of a level from start to finish. Most of the work (including the write-up) took a day, but I’m still fine tuning it.  While I’m using MaxED, the Max Payne level editor, the basic ideas and approach are quite general and will work in any action-adventure game focused around melee combat.

Level name: Defence Training

Overview: Simple encounter against an increasing number of enemies in a martial arts dojo, with a catch – 1 hit kills the player.

Design Purpose: This optional challenge map is designed to encourage players to practise fighting defensively against multiple melee attackers.  The individual enemies are easy to defeat, but unlike the main game, one hit kills the player.  Inspired by the principal of Darwinian Difficulty and Hotline Miami, as well as the challenge maps in the Batman Arkham games, my reasoning is that allowing players to practise in an extreme (but fair) scenario should help them refine their fighting ability to the point where regular encounters in the story mode are trivial.

In particular, this level is designed to raise the player’s awareness of actions/moves which have invincibility frames – both defensive sidesteps, twists, and rolls, and special attacks. Controlling the positioning and movement during a fight is also encouraged (i.e. don’t get backed into a corner).

While called ‘defence’ training, there is a strong emphasis on interception — those who wait for their attacker to hit them; dodge or guard the hit; and then counter; risk getting hit (especially when attacked from all sides by multiple attackers). Player should quickly realise that survival relies on a balance between defence and offence; as well as range, timing, movement, prioritisation; and positioning. In other words – hit attackers before they have the chance to attack you; move defensively to avoid being swarmed; position yourself so that you can attack without being hit; time your attacks, so that you are not left vulnerable; prioritise which adversaries to take down first.

Lastly, efficient use of Bullet Time is encouraged to slow down time to concentrate on defensive movement and attack.

An additional purpose is to expose any flaws or bugs in the combat system. Testing under the hardest difficulty possible should highlight problems with difficulty, fairness, balance and flow (unexpected, random deaths; hitbox tuning; damage per move).

Design approach: I’m reusing the Dojo level for speed and simplicity – it’s a small-medium sized arena, suitable for combat with a small number of enemies (guessing 13 – 21 before it gets crowded/laggy).

The fight is broken down into several encounters, focusing around an enemy type; and each encounter will be broken down into 5 waves. Each wave will throw an increasing number of enemies at the player, in accordance with the Fibonacci sequence (1,2,3,5,8,13…). First encounter will start off with very slow and easy enemies; then we will introduce faster and tougher enemies; enemies with weapons (possibly including firearms); and finally mixed sets of enemy types. Between encounters might be a bonus/challenge wave.

Example:

Encounter 1

  1. 1 White dragon enemy, hostile when approached, very slow and weak
  2. 2 enemies
  3. 3 enemies
  4. 5 enemies
  5. 8 enemies

Encounter 2 – Same as 1, but with Yellow Dragon, an enemy which sprints at the player.

Encounter 3 – Mixed white and yellow; introduce red dragon (tank) 1. 1 red 2. 1 yellow, 2 white 3. 2 yellow, 3 white 4. 3 yellow, 5 white 5. 1 red, 3 white, 2 yellow?

For the sake of keeping things simple, I’m just going to focus on the first encounter.

Implementation

Encounter1

Fig. 1

Encounter 1 looks like this. Blue spheres are the actual NPCs, green spheres are the custom FSM scripts I use to control them. Note the first guy is missing because he starts in the level itself.  To preserve name-spacing, I should have placed him here and teleported him into the playing area when the level starts, but I don’t think this level is big enough to warrant that level of discipline.

An annoying facet of Max Payne level design is that NPCs cannot be spawned into a level, like they can in Unreal, for example. This means you have to frontload all of the enemies you want to use, and usually hide them in a room off the level somewhere. In many ways, this is actually a good thing because it forces design and coding discipline — you can’t afford to spawn hundreds of guys in a room (which is problematic design anyway), because it results in a huge scripting overhead. In levels where I want a lot of guys on screen, it’s a good idea to constrain yourself to the Fibonacci sequence, and organise encounters into waves to keep things sane, and to control pacing.

Another approach is to simply re-use NPC assets. You can see above that the maximum number of white dragon enemies the player will ever encounter in this level is 8. Hypothetically, it makes sense to simply load 8 of these guys, and simply respawn them on each wave (respawn meaning to resurrect to full health and then teleport to the desired location). I would do this, but honestly NPC necromancy can be problematic in Max Payne — especially with more complicated scripts. Usually it works, but sometimes it results in the enemies doing strange and unpredictable things when they respawn like standing in a dazed trance, playing an incorrect animation, or dying immediately on spawn. It also makes counting kills in waves much more complicated than it needs to be, because you have to work out a way for the level to know exactly which wave this enemy belongs to at any given time. Finally, re-using enemies results in bodies disappearing during combat. The absolute worst thing is for an NPC’s body to suddenly vanish moments after you just KO’d him.

I mentioned custom FSMs earlier – those are the green spheres. I had hoped that this level would be simple enough not to require individual FSMs per enemy, but the nature of the wave system requires me to count each time an enemy dies, so that the next wave is started when all enemies are dead. A quirk of our mod is that it’s possible to ‘kill’ NPCs multiple times, during what we call a ‘juggle’ combo. One frame before the player’s punch or kick lands, we spawn a ‘juggle’ area projectile which heals the NPC briefly (dealing -0.01 damage), which resurrects knocked out ‘dead’ enemies just in time for the kick to KO them again. This allows the player to ‘juggle’ defeated enemies, and perform stylish combos to finish them, which is both intrinsically satisfying and serves a gameplay purpose — you gain health back for juggling enemies.

An individual FSM is therefore required to count the first (and only the first) time the player ‘kills’ an enemy, otherwise juggle hits are counted, and the whole script breaks down. It’s for this specific reason that variants on the Kung Fu mod (including Katana) break the level scripts in vanilla Max Payne — especially the Jack Lupino fight in Ragnarock. The original Max Payne levels are not scripted to take into account juggle combos, and therefore scripted events can be triggered prematurely. This is why you have to be careful resurrecting NPCs.

Fortunately, this is fairly simple to implement in MaxED. NPCs have two primary states – Alive (default) and Dead. When the enemy is killed for the first time, they switch to the dead state, and a message is sent to the Wave script to increase the kill count by +1. If they’re killed again (by juggling), it doesn’t count because no further messages are sent to the wave script while the enemy is in the ‘dead’ state.

states

messages

In the story levels, regular melee enemies have between 3- 8 states (called ‘lives’ to distinguish them from HP), which allows them to get back up after being knocked down. This system originated from Max Payne: Katana, where I wanted to simulate combat by having enemies block a certain number of attacks before being defeated. Each enemy had a pre-set number of ‘lives’ and tougher enemies, such as bosses could withstand as many as 20+ hits before dying.

You make this system more interesting by having enemies regenerate lives over time, forcing the player to focus their attacks on a single enemy; or by layering this system with others (bosses in TRW have a regenerating ‘guard’ or shield which has to be ‘broken’ first before you can do permanent damage).  The exact implementation in TRW is much more complicated, because we wanted the enemies to do more interesting things, like get off the ground if they get knocked over, and allow the player to kick them into walls, or punt them across the floor like in the film; but I’ll save that for another post.

Even on modern systems, Max Payne can grind the framerate down if you’re sloppy, so it’s generally a good idea to remove NPC bodies at regular intervals — especially if you’re scripting an arena type level. For this map, enemies are removed every other wave to reduce the likelihood of the player noticing them disappearing.  In my experience, most people are too focused on fighting off adversaries to notice downed enemies being removed.  For best results, create a timer for every enemy and randomise the time between dying and removing the body, but that requires considerable overhead.

Zoning

Although the Dojo level is fairly small, it’s good design practise to divide your levels up into modules, or zones, and track where the player is. This allows you to control stress and tension by spawning enemies intelligently, relative to the player’s location.

As the Dojo is a square shaped arena, this is straightforward – I simply divide the level into thirds horizontally and vertically, giving me 9 zones. I could have divided into four quadrants, which is simpler, but offers limited tracking – especially if the player stays in the centre of the ring. With 9 zones, no matter where the player is, I can easily surround and envelop them by spawning enemies in the adjacent zones. 9 zones is also convenient because, if you remember, the maximum number of enemies I want to spawn (for now) is 8. So if I wanted to, I could spawn one enemy in each zone, leaving one space for the player. As you can see, working with the golden ratio naturally leads to more elegant designs.

Zones

For this to be manageable, the naming scheme for the zones has to be straightforward and meaningful; so I’ve gone with Centre, North, South, East, West, NE, NW, SE, SW.

This is fairly straightforward to implement in MaxED – you have a tracking FSM called Zoning with your 9 states (North, East, South,…). You then create 9 player collision triggers evenly spaced across the map to cover each zone, and on the activation of each trigger, you simply switch the state of zoning to whichever trigger was activated. So if the player activates the trigger ‘North’ the state of zoning switches to North. Although this is fairly simple, I recommend printing a direct message to the HUD to display which zone you’re in for initial testing — you don’t want to go to the effort of creating a complicated zoning system, if the actual tracking isn’t working correctly.

Another consideration is the fact that in MaxED triggers are spherical, which means that there will be some gaps between triggers. You can fix this by nudging the corner triggers (NE, NW, SE, SW) towards the centre a bit, or by simply increasing their radius slightly, along with the central trigger.

Zoning implementation

Fig. 5 An FSM tracks where the player is in the level, so we can spawn enemies in smart locations.

As for the actual waypoints used for spawning the enemies, originally I thought about using 3 per zone. However, this leads to a total of 27 waypoints, which is far too many. In the end, I settled for a total of 16.  That leaves me with 3 in the centre, 2 in each corner, and 1 for every point of the compass. This means I can spawn as many as 18 enemies at once, if I wanted to (which I don’t, as my budget is 8 npcs)

The final step is to write the code to actually spawn enemies. For every wave, there are nine possible zones where the player could be, so it’s a case of working out where the best location to spawn enemies is (i.e. the adjacent zones).  So that means there are 45 possibilities in total.

This might sound like a lot of unnecessary work for simply spawning enemies in, but in practise it doesn’t take that long to implement, and (aside from the challenge of building it) I think the results are definitely worth it. It’s also fairly scalable – assuming we don’t increase the number of enemies on-screen from 8, most of the work can be duplicated for additional encounters with minor modifications to the scripts.

Now we have a good foundation for this level.  It might not be apparent in the video, but the zoning system allows for a fairly natural ‘feel’ to the encounter – enemies spawn close to the action, not randomly; and the waypoints and timing can be tweaked to adjust stress, tension and flow.  Although basic enemies work well for this specific level (remember 1-hit kills, so anything complicated will overwhelm the player), were this an encounter in a ‘proper’ level, the next logical step would be to increase variety, by adding enemies of different class and role, as explained in this excellent and authoritative article on the topic. At any rate, this level is now the perfect template for testing all manner of encounters.

Advertisements

The ‘Small and Agile’ approach – A retrospective

I’ve finally gotten around to posting my honours work /dissertation for my final year at the University of Abertay Dundee, for my degree in Game Production Management.  It comprises of a dissertation proposal, the dissertation itself, and supporting project work which serves as a worked example of some of the concepts proposed in the dissertation body.  It was published in May 2008.

  1. Part 1: Proposal (The problem for Independent Game Developers)
  2. Part 2: Dissertation (Survival of the fittest – Investigating the survival strategies of “Small and Agile” game studios)
  3. Part 3: Honours project (Game Development Plan and Reflective Log)

Some five years have passed since I wrote this work, and back then the prospects for indie game developers looked quite bleak.  Since then, the games industry has changed dramatically — Angry Birds demonstrated the huge potential for small developers in the mobile apps market; the rise and fall of Zynga highlighted the potential and risks of Facebook as a games platform; Humble bundle, Good Old Games, and even Xbox Live emerged as reliable digital distribution channels for independent developers; crowdfunded projects on Kickstarter took off in a big way, resulting in the world’s first crowdfunded indie games console the Ouya.  Oh, and Minecraft happened. :)

At present, I feel confident that independent games development is thriving in a very positive, if unexpected way.  Yet, many of the problems and challenges surrounding Next Gen / AAA development reported in my original proposal are still present.  With the latest round of next gen consoles – the PS4, Xbox One, and Wii U – the costs of games development for the home consumer is unlikely to go down any time soon.  The business model, as far as I’m aware, is still broken, with regards the developer royalties. In particular, the use of Metacritic scores as another way to control and limit how much a studio earns is particularly troubling.

There are still development horror stories — L.A Noire was a critical and commercial success, but plagued by a protracted development schedule (7 years) and controversy surrounding poor working conditions.  In spite of the game’s success, the developer, Team Bondi, was shut down after failing to secure another game project.  What’s more revealing is the recent downfall of middle tier publishers such as THQ, and the closure of several notable development studios (e.g. Psygnosis), throwing doubt into the previous convictions that being acquired by a major publisher would offer financial security and was a viable end-game for any independent developer.  The Radar Group, which I had high hopes for, seemingly disappeared after 3D Realms ran into financial difficulties, and at the time of writing, no one else seems to have taken the concept of a production studio on board.  To be fair, why would they?  Having another middleman to share royalties with is unappealing to both publishers and developers, even if it does reduce overall project risk.

If asked on my views of the games industry today, I’d refer to Dickens and say it was the best of times, it was the worst of times.  Better games are being made, and there’s good reason to be hopeful.  Yet, there’s still much to criticise and past mistakes aren’t being learnt from (for instance, sexism in games / production is still a prevalent issue).

In closing, Scott Miller, who I used to admire quite greatly and referenced heavily in the above work, once posted the question “Who’s left who can design their own game?”  Back then, the answer was very few.  Today, it seems like there are plenty of opportunities for anyone with a clear vision, and the skill and talent to see it through.  Time will tell if the kickstarter bubble bursts, but for now at least, it seems like an exciting time to be developing games, and I’m looking forward to seeing how these projects develop.

Story telling in games

This is something that’s been on my mind for a while now.  Story telling, recounting experiences – both real and made up – is something quite fundamental to human culture.  We tell stories to entertain people, to teach them, to inspire and challenge people.  Much day-to-day conversation falls into the pattern of listening to what people have to say, and retelling stories from your own life.  Even when we are asleep, a good portion of our brain is devoted to making up stories in the form of dreams – wild and fantastical.  Most organised religions are founded on stories from the past.

Like any art form, I see games as a medium for creating and telling stories.  For example, when you look at traditional pen-and-paper RPGs, they largely boil down to a group of friends making up stories. The game just gives them a framework for telling the story.

Gameplay, as a craft and discipline often gets overshadowed by the story and presentation; and yet I think gameplay design is at its most effective when it can facilitate story creation. Sure the vocabulary of the theatre and film transfers directly to games in terms of cast, set, props, and so on; but the best games create worlds, for which multiple stories and adventures can take place in (I’m thinking along the lines of Elder Scrolls, Minecraft, Journey, and probably MMOs like Warcraft as well).

Look at the new X-Com game that came out last year — there’s a game that has a very basic premise (aliens are abducting people, you must stop them!); but basically gives you a blank canvas to craft your own stories. As a game it plays like a modern version of chess (or more directly, warhammer 40k), with both you and the computer taking turns to move pieces, and the winner is the one that captures all the other pieces, or meets their objective. The genius of X-Com, as a video game, is that it lets you name your pieces, and customise their appearance and voice — it lets you turn them into characters. In doing so, players can reframe the events of the game, as a story. Every mission is just one episode in a bigger, personalised narrative, starring a cast entirely of your own creation. It’s compelling because you don’t have full control over the plot and you don’t know what’s going to happen next — characters can die, and the plot can twist in unexpected ways.  In RPG terms, there’s a games master (or story teller) in place to ensure dramatic conflict and uncertainty, whilst still allowing the player to own the story.

For me, that’s where I think story telling and games should go. Anyone can write a story, and then craft a game around it (yo). That’s fine, but I don’t think it’s using the video games medium to its fullest. Granted, you can personalise the story by adding branching plotlines, as with Mass Effect, but you’re still constrained by things like character arcs, audience expectations (Mass Effect 3 ending anyone?), consistency, and practical logistics.  Writing a good story is hard enough — writing a branching story makes things exponentially complex.

There’s always going to be a place for big, cinematic story games (nothing beats a well written, well told story); but I believe that games that allow players to make up their own stories are the way forward as an artistic medium.  I think that’s why games like Journey left such an impression — without a predefined story and no way to verbally communicate with other players, it forces the player to come up with their own personal interpretation of the journey they experience.  They can then recount that experience to others.   I think that’s also why Minecraft has become so popular — it’s simple to play, but has almost infinite potential for making up stories and games.

However, my growing concern is that we’re going to see a regression — instead of games, I think we’re going to see more “interactive experiences”.  Big budget, summer blockbuster entertainment titles, that you don’t play or explore, so much as participate in.  Modern incarnations of Dragon’s Lair (which is beautifully animated, but not really fun).   Again, on the scale of art and entertainment, there’s place for these titles to sit, but I think it would be a great shame if those are the games that get the most funding in the future.

Human’s are natural story tellers.  Our entire civilization is founded on our natural ability to recount events and characters from the past, and imagine and foresee events and consequences that might happen in the future.  As a game designer, I think we can make more meaningful, more impactful games by tapping into this natural instinct of interpreting and reinterpreting events as stories.  Instead of spoon-feeding people hollywood-esque drivel that would make even Dan Brown cringe; we can give people the tools and settings they need to create their own worlds and realise their own stories.  That’s something only games can do.

HEALTH – Max Payne 3 soundtrack

To round off the year, I thought I’d quickly take a look at my top albums for 2012.

Most of it isn’t too surprising, except for the Max Payne soundtrack.  What can I say here?  Obviously due to my modding background and past ties with Remedy, I had high hopes but low expectations for Max Payne 3.  It’s been almost nine years since the last game, and the idea of a bearded Max Payne with a skin head, shooting gangs in Brazil seemed wrong on paper.

Yet Rockstar exceeded them on almost every front — both in singleplayer and multiplayer.  Say what you want about the story, McCaffrey is in fine form and delivers some wonderfully cynical put downs (my favourite: “Rich parasites with delusions of humanity.“).  Maybe I just identify with bitter and broken anti-heroes a little too much these days.

But what took me, and clearly many others, by complete surprise was the soundtrack.  Of course, it shouldn’t have — Rockstar have proven many times that someone in their office knows their music, both old and new.  What’s evident though, is that they clearly understood both what made the Max Payne soundtrack work in the past games, and what was missing from them.

The first two Max Payne games were scored by Kärtsy Hatakka & Kimmo Kajasto, who set the tone of the series with dark, ambient pieces, mixing electronic, rock, and classical arrangements.  The second game also closed with a single from Poets of the Fall, a Finnish band who have continued to work with Remedy on their next game series, Alan Wake.

While I love these soundtracks, when it came to making new levels for them (particularly in Mona The Assassin) it became apparent that there are actually very few action tracks in the score.  Max Payne 2 literally has only one track , and as a level scripter you simply can’t use that one over and over again.  Considering that this is a game series that revolves around violent gunfights — mostly in slow-motion — it’s a strange omission.

What HEALTH have successfully managed to do with Max Payne 3 is carry over the dark, melancholic ambience from the first games, and inject a pulse into it.  From the moment you load the game up, the music immediately sets a steady pulse going and it never lets up as the action intensifies.  During gameplay, as Max takes cover you become aware of a drum rhythm, which then builds to a frenzy — mirroring the on-screen violence.  It reminds me of stories (I’m not sure of the origin) of warriors or soldiers driven mad, because of an unrelenting drumming sound in their head.  The drums of war, so to speak.  Certainly, when I hear it now, my pace quickens and my focus sharpens.

Modern game designers often talk about a concept called ‘flow’ — the careful control of tension and release in conflict based gameplay, which (if done skilfully) can heighten the experience.  Although it’s an obvious thing to do, Max Payne 3 is one of the few games I’m aware of that very consciously uses its soundtrack to manipulate the feelings of the player.  The audio is layered into the game in such a way that the transitions between chaotic gunfights and ambient introspection are subtle and go mostly unnoticed.

But it’s not just the use of percussion that makes the Max Payne 3 soundtrack great.  The game has many melancholic and reflective tracks, that evoke (for me anyway) that dark electronic sound you hear in 80s films like Manhunter.  For me, the more introspective tracks like Pain, Torture, Dead, Panama, and Future are the most interesting to listen; and as a whole, they give the album a sense of balance.  That’s important, because it feels like a complete music piece – a concept album – rather than just a movie or game soundtrack.

It’s not an easy album to listen to, and ambience and noise is always an acquired taste, but I think it more than stands up alongside other releases this year.  That said, it’s a dark album, and in the context of the game there are undertones of loss, regret, failure, violence, and self-hate.  This is the soundtrack to a man who indulges in self abuse, labels people as “chumps” and “parasites”, and unconsciously sets himself up for repeat failure — which he then wallows in.  It’s a soundtrack to a man who finds escape and release through being shot at.  In some respects, Max Payne is exploring just how far down the downward spiral he can go before reaching catharsis; and HEALTH’s soundtrack perfectly reflects the pain, anger, and conflict of a man trying to piece back together the fragments of his broken psyche, cutting himself on the shards in the process.

On a personal level, it’s a  dark soundtrack to what has been a surprisingly difficult year —  full of failure, change, uncertainty, doubt, and loss.  Bleak as this record might sound, it’s important to remember that when facing difficulties, the message is not to wallow in self-pity, alcoholism  and violence.  Max Payne isn’t an ideal hero, nor is he a protector — a role he continually miscasts himself as.  When stripped to his core, Max Payne is a fighter.  If there is a message to take from the story, it’s to keep fighting.  Keep fighting for what you believe in;  fight for change; fight for hope; fight to make a difference.

Whatever it is you think is important, don’t give up on it, no matter how bad things might seem.  A simple message, but one that gets clouded in the day-to-day haze of modern life.  This is something I learnt many years ago, and having faced absolute failure in the face on more than one occasion, I believe you have to match difficulty with the tenacity to keep on going forward, to never give up, to keep fighting.  This record somehow captures that sense of hope,  surprisingly enough in the track entitled Pain.

You can listen to the whole album on Spotify here: Health – Max Payne 3 Official Soundtrack

Finishing touches…

I’ve been somewhat restless this year…  looking at my wordpress dashboard, I have no less than 19 posts sitting in the ‘draft’ queue.  There’s so much more I want to write about, and yet it seems like these days I can only get two thirds of an article written before I run out of energy or inclination.  I guess a 45 hour week will do that to you.

I’ve been studying game systems and the art boss design with intense interest this year.

One of the limitations of making turning Max Payne into a fighting/adventure game has been that fights always come across a little underwhelming.  All of the characters are regular bipeds, and they share the same movements due to the enormous amount of time and effort animation takes up.  It takes a lot of work to prevent these fights from getting repetitive.  Even in the regular Max Payne games (1 and 2), the weakest aspects are the boss fights because they either boil down to basic shootouts, or elaborate stage puzzles.

This week I realised that the reason the boss fight I was designing fell flat is because there’s no payoff for actually beating the bad guy.  In Katana, when you defeat The Big Bad – your reward is crude but satisfying: –  the music intensifies; blood and light particles flood the screen; and your character echos  “Wuuoooaarhh!!!” as he tears his adversary’s head off in slow motion with his sword.  All of this happens in about 3 seconds.  A fitting, and brutally honest end to a  game is entirely focused around violent, bloody confrontations.

It is called Katana, after all.

Whereas in this fight I’m working on… it’s a bit of strange one because the conflict is optional.  The whole premise is that the player character is starting to believe in their inner strength and chooses to fight the big bad boss, even though they don’t have to.  In game terms, that means that the player should also want to choose to fight, because it’s fun; but if they want to, they can actually run away and load the next level.

This boss is intentionally tougher than anything they’ve faced before, so assuming they choose to fight on, I’ve added another shortcut — ring outs.  The setting is a small subway, and the player can lure the boss onto the tracks, wait for a train, and then jump to safety at the last moment.  The boss is scripted to try and climb back onto the platform, but most of the time he still gets hit.  Of course, the player can also get splattered by the train, so there is some risk involved.

So, I think all that stuff is okay, but what happens for the players who do take the time to beat this boss properly?  

He just yells “Yarrrgh…!”, keels over, and vanishes.

Until this week, I’d not given it that much thought, but I had an underline sense that it just felt wrong.  For stylistic reasons, I can’t have the player decapitate him or have him explode (the game is not gory at all); but I wanted to visually reward players for winning the fight.  Then it occurred to me — why not make it like a Mortal Kombat stage fatality?  I mean, sure it’s cheesy, but the train is already there.

So, after you ‘win’ the fight, the boss staggers to his feet, precariously near the edge of the platform.  I must stress that the player can still choose to run away at this point.

“overcome adversity… in an honest and visually unique way” 

It’s a very simple set up that guarantees that the train will suddenly appear and hit the character if the player chooses to kick or punch them off the platform.  This means the player can run up to the guy and perform their own custom juggle combo on the boss – really lay into them, and then cap it off with a cool stage finisher.  It’s not quite finished, but already the level feels more complete after this addition.

It occurs to me that not enough games outside of the fighting genre actually let the player beat up the boss after they’ve won.  And why the hell not?  Bosses are, by definition, challenging and borderline frustrating, so it makes sense to reward the player once they’ve overcome them.  Yet, off the top of my head, I can’t think of a single recent game that lets you ‘finish’ a boss.  Bayonetta perhaps?  Even if the fight itself is solid, too many games these days retreat into a cutscene or quicktime event the moment that the boss hits zero HP.  It’s a real shame, because the idea of allowing the player to ‘Finish’ his opponent in style is a stroke of genius.

Say what you will about Mortal Kombat’s exaggerated violence and gore, Ed Boon and his team really understand the idea of overcoming adversity “in an honest and visually unique way”.  It’s about understanding your characters, something which MK has always excelled in — whether it’s Sub Zero with his deep freezing powers, Scorpion with his harpoon spear, Raiden with his electricity, or Kung Lao with his razor sharp hat.  All of these characters are instantly identifiable, and their finishing moves are appealing because they fully utilise the uniqueness of the character and their powers.

You can see this in their new fighting game, Injustice:

I can’t say I’m a huge fan of the DC universe, but who wouldn’t want to play as Superman when you can uppercut your opponent OUT OF THE EARTH’S ATMOSPHERE.

Getting back to finishing moves, besides being visually striking, the most important thing is that they are interactive.

What do I mean by this?

  • They can only be performed if you win the match.
  • You can choose between 2-4 unique moves per character, and some levels offer special stage finishers.
  • You have about 5-10 seconds to enter the correct input.
  • You have to be standing in the correct place for it to trigger correctly.
  • They can be failed, and there’s no ‘try again’

The key point to take from that list is choice.

We’re not talking about a glorified quicktime event, where the player presses buttons in sequence as cool stuff happens.  And we’re not talking about violence for the sake of violence.  The point is that the player can choose exactly how they want to finish their adversary – even if that choice means running away or letting them go.

Something Ninja Gaiden 3 utterly failed to do:

http://kotaku.com/5894896/heres-everything-i-cant-stand-about-ninja-gaiden-iii  (skip to 1:30)

In this scene, the player character backs a defeated, unarmed soldier to the wall, and is then prompted to kill him.  All the while, the man is begging for his life.  It could have been quite thought provoking, adding a level of ambiguity to the character, and making a brave point about thoughtless killing in promoted in videogames.  Instead, it’s unsettling — and for the wrong reasons.  As the reviewer points out – “the player has no choice but to run him through, in slow motion.”  In his dying breath, the soldier reprimands the player for being inhuman.

This is a design mistake.  If you’re going to have your character commit a morally ambiguous action, you either don’t make it interactive, or you let the player choose and accept the consequences.  Forcing the player to participate in an action they morally disagree with only serves to alienate them from the character and the game as a whole.

Contrast that with the ending of Max Payne 3:

It’s subtle, but you have about ten seconds to decide whether or not to pull the trigger.  The game doesn’t judge your decision.

Meaningful choice is important because humans are problem solving machines.  When confronted with a problem, we make a choice and take action based on it.  We then analyse the consequences of that action (rewards and punishments); we consider the alternative choices that could have been made; we weigh these factors up and we determine whether or not we made a mistake.  Through this process of trial and error, we learn from our mistakes, and when confronted with similar problems, we apply this learning to make more informed decisions.  As we become more knowledgeable and experienced, we start to make less mistakes and gain a sense of accomplishment.  We then seek more challenging problems, so we can further our learning, and inch closer towards mastery.

Problem -> Choices  -> Consequences -> Learning -> Meaningful Choices -> Accomplishment

However, if you take choice away entirely, then you short-circuit the whole learning cycle.  Without choice, you can’t make a mistake, and without mistakes you can’t really learn.  Your actions become meaningless events with no significant consequence.  In the simplest terms: if learning equates to fun, then removing choice kills the fun in your game (although remember that overchoice can overwhelm players — everything in moderation, as always).  On the other hand, introducing subtle tactical and strategic choices can make a basic game system more refined and interesting.

For instance, even when God of War uses quicktime prompts, many of them are optional and have different strengths and weaknesses.  Usually performing a quicktime finisher lets you defeat the enemy early (when they have 20% – 33%  health left), makes you invincible during the animation, and it rewards you with a health or magic bonus.  In other words, these finishing moves give you an immediate, tactical advantage, as well as a visually strong way to defeat your opponents.  However, if you beat the enemy with regular attacks (slightly more challenging), you’re rewarded with more orbs — the game’s currency, which lets you purchase upgrades.  This gives skilful players a long term, strategic advantage.   

This means that during almost every single encounter, the player can choose between a tactical vs. strategic approach, depending on their current situation, and their goals and motivation.  But it’s not required of them — there is an optimal path, but they’re not forced to play it.  This adds subtle layer of depth to the game, without ever over complicating it.

In closing, when designing games and levels, I think it can be helpful to think of “the player as the director”.  Always remember that when the game starts, when someone calls “Action!” (or “Finish him!”), it’s the player who fulfils the role of both the lead actor and the director on set.  While it’s tempting to push them down the best possible path, ultimately it’s their story, and when it comes to the big set pieces, they should be the ones who control how the action unfolds.  Do they viciously finish their adversaries, or do they just walk away? That should be their decision.  Your job is to give them the opportunity to decide.

The Why, How, What of game design.

MMOs designers need to focus more on the ‘why’, not the ‘what’ 

This is an interesting article, in so far as it highlights a good thinking discipline — if you can’t accurately explain ‘why‘ a user likes an existing product or feature, you shouldn’t be thinking about how or what to build next.
It’s very easy to slip into a reverse thinking pattern where you do this backwards – what shall I build? How shall I build it?  Why would they want it? (i.e. how do I justify it?).  Instead it should be: Why do they like this, how can I improve it, what do I build to facilitate it?

In gaming terms, I don’t think MMO’s are any different from regular games, but they’re problematic because often skill based gameplay is substituted for repetitive grind tasks.  However, all games have one common goal and motivation (the why), and that’s to achieve a sense of accomplishment.  How do players get this? By making meaningful choices, through applied learning and mastery of the game’s world and systems.  Minecraft is a good example of this.

The  -What- varies from game to game, but generally speaking it’s signposted by overcoming challenges — beating other players in the game, finishing the game’s levels, reaching the highest level, or conquering all the game’s environments.  If the list of challenges dries up, or becomes stale (e.g. generic, never ending missions in GTA and Skyrim) the player loses interest – so you facilitate this by introducing more challenges to overcome.

For example, Tekken hasn’t really changed its core gameplay since Tekken 3, which came out 15 years ago.  They’ve extended the game with subtle refinements to game system, and more importantly by drastically expanding the character roster (to over 50) and the number of moves per character (which is in the hundreds).  In other words, they keep pushing that bar of ‘mastery’ out of the grasp of all but the very best players (who compete in tournaments).  As a result, there are always more characters to master, and always new opponents to overcome.

With an MMO, it’s pretty simple – you need to keep pushing that level cap, build new areas to explore, and even bigger monsters to beat (particularly those that encourage team play, or even an entire community of players, like that mobile game that has a billion HP boss).  Why do players do this?  Again – to get a sense of accomplishment, by overcoming all challenges.

Rapid Playtesting

The scenario: You’re a lone gameplay designer working on a project that’s been on the back burner for too long (years), and you want to make the damn thing production ready ASAP.  The problem is, the levels are a mess, and worse still you’ve got a dozen more to work through afterwards!  Deadlines are looming and you have nothing to show for it.

What follows is the approach I’ve developed over the years, modified with a few techniques and ideas I picked up at work and elsewhere.  This refining process is best suited for levels and projects that are on that last ‘20% is 80% of the work stage’ – i.e. built, scripted, but very buggy and needs improvement.  It’s not intended for initial design work, which requires proper planning; likewise we are not adding new features or content, unless the benefits and workload are clearly understood.  You’ll need a notepad (essential for any design work) and ideally an alarm clock (I use my mobile’s timer function).

The overall idea is to work in passes and refine the work with each iteration.  For your first pass, play through the level for around 25 minutes or so, and note down everything that stands out as wrong, not right, a little off, and needs work.  I recommend that you focus on the critical path to begin with – that is, play the level as it was intended to be played.  At this stage, there’s not a lot of point rooting out those obscure bugs if the core level design has issues, and remember that our key objective here is to make the level production ready as soon as possible.  Nevertheless, it’s still best to jot down everything that stands out so you don’t forget it later.  I tend to use a single notepad page per level / pass, and write down each issue on a new line.  I use pen and paper because I’m working alone and the process is supposed to be simple and fluid.  You can easily flick back a few pages to see where you were, but the idea is to establish a prompt working rhythm and not interrupt that with over-complication.

Once you’ve done this, you need to break down the issues in terms of importance and estimated difficulty/time.  I class issues as: trivial, minor, and major, like we do at work, for familiarity; but given that this is an informal (and rapid) version of the ticketing process, I recommend that you use a system that makes sense to you.  For me, a trivial issue is one that can either be resolved in a matter minutes or can be written off; a major or critical issue is something that needs a bit more thought or absolutely has to be resolved before your level is production ready.  Adding content should always be considered a major issue, because it will likely require significant time and effort to code and test, and risks introducing new bugs into the project.

With the tasks estimated, the final step is simply to address and resolve them.  I’m not going to be prescriptive here – you may wish to resolve all the minor issues first – that’s fine.  However, there’s one final trick you can employ here to speed things along – set a time limit.  Specifically, give yourself 25 minutes and use an alarm clock or an egg timer to keep time.  Then blitz through the list and try resolve as many of the issues as you can before the alarm goes off.  Then stop, finish what you’re doing and take a five minute break.  You don’t need to be a certified Pomodoro Master to appreciate the benefits of this approach;  while achieving a state of “flow” is great; in my experience, it’s hard to control, and there’s a definite risk of flowing down the wrong creek.  Using a timer and a prioritised list keeps you focused, and taking frequent breaks reduces fatigue and keeps you fresh.

After the break you can either return to the list for another 25 minutes, or if enough of it is finished, begin a new pass, starting with another playtesting session.  When working through the list, I tick off each item that has been addressed, and during the next testing phase, I strike-through all the issues which appear to be resolved (thereby closing them).  Once all issues have been resolved to your satisfaction, you can either continue to seek out more obscure errors, or call it a wrap and move on to the next task.

Essentially the method described above is a sped-up version of Agile development, with each micro-sprint being limited to no longer than 25 minutes, and the core phases of QA testing and task estimation condensed down to a quick notepad exercise.  The simplicity and speed of the process makes it ideal for tasks like playtesting and polishing, while keeping you focused on testing and resolving genuine issues that will prevent your level from being shipped.  Lastly, the iterative nature of this approach means that the level should be becoming more refined with each pass as you continue to invest time eliminating problems.

The above graph is absolutely non-scientific or set in stone.  The point is to illustrate the logarithmic nature of time working vs. quality.  That’s not to say you should skimp on polish – hell no, it’s by far the most important phase, but there will come a point where your changes start to have marginal improvement, or may even be detrimental to the final product.  The trick is recognising when you’re at this stage.  I’m quite fond of Mike Birkhead’s mantra:

“Add things until it starts sucking, take things away until it stops getting better”

Potential quality is the game you’d like to make, or  imagine it to be like finished if only we could just…  I’m not going to say that it’s impossible for games to meet or exceed their potential, but certainly in my experience there’s always been a gap between the game you wanted to make, and the game you actually end up releasing. Good as it may be, they’re not the same thing; so you need to learn when to let go and call it a job well done.

Anyway, once you’ve got your level to a point that you’re happy with, and can no longer see any scope for improvements, the final phase before release is to get real feedback from other playtesters.  I cannot  stress enough how important this phase is – second opinions will give you a much clearer idea on what works and what doesn’t, highlight issues you’d never considered, and will help you prioritise the issues that really matter.

For the Real World, I used Dropbox and invited about a dozen people to try three levels and give me feedback.  This process is much slower, as people can take up to a week to get back to you; however, the core benefit of using dropbox is that you can address issues almost immediately: “Too difficult you say? Okay, try now – is it better or worse?”  This interactive approach is quite effective, because playtesters can suggest ideas and immediately see the results of their suggestions implemented in the game.

To give you an example, in Trinity’s level,  we had a crate blocking part of the corridor you’re supposed run down to escape the Agent.  On paper, this seems like a legitimate obstacle to frustrate the player’s escape a little, and create a bit of dramatic tension. This was an oversight on my part – having played through the level countless times, I’d simply learnt to avoid it.  The first round of playtesting immediately identified this as a flaw in the design, and as a result it was moved out of the player’s way.

In practise I did about three or four rounds of playtesting (1 month approx)– the biggest issue was the difficulty, and it was important that these complaints were addressed before releasing the level to the public.  This was done in stages – a limited release candidate was made available to download via a QR code, to a small audience – this was to make sure there were no showstopper issues with the mod (e.g. compatibility issues), and a week later the ‘final’ release was uploaded and mirrored.

Overall, I would say that the final release was better for this adopting this approach, and enabled me to develop, polish, playtest, and release a 4 level mod within a 2-3 month timeframe.  I’m pretty happy with the final result (which you can try here), and the majority of feedback has been positive.  Of course there’s always scope for improvement, but again, we return to that balance between meeting potential and actually releasing content for people to play.  At any rate, this is just the first release – I’ve left the door open for future refinement.