If there’s one thing you don’t want to mess with, it’s The Laws of the Universe. Going against Mother Nature (or Father Math) can – and will – end you in serious trouble. For your convenience The Laws of The Universe (for Game Designers) investigates the universal and inescapable laws of The Cosmos, and what they mean for us lowly Game Developers. Endorsed by 8 out of 10 Hermits.

#2 – The 80-20 Rule (aka “The Pareto Principle”)

The Pareto Principle states that:

“[...] for many events, roughly 80% of the effects come from 20% of the causes”.

20% of the effort accounts for 80% of the results. Or so I would have you believe.

Let’s look at some commonly used examples of this principle:

• 80% of the wealth in a country is owned by the 20% richest people.
• 80% of the crashes are mady by 20% of the bugs in your software.
• 80% of the population lives in the 20% most densely populated areas.

The 80-20 division may not be completely accurate for most situations – in some cases not at all – but at least it can serve as a rough guide for typical distributions, and remind us that most things in life is not even!

Basically, the principle claims that a few, select things are VITAL (having a big effect) and a lot of things are TRIVIAL (having less influence).

What this means for game developers

At the fear of overextending this lovely principle, I’d say that it’s very relevant for game developers, at least as a way of prioritizing and thinking about what you’re working on. No matter how much content and polish you put into your game, chances are that players will spend around 80% of the time looking at 20% of it!

Can you guess which 20% of the image gets looked at 80% of the time?

But WHICH 20% will they be looking at? That’s the question you need to think long and hard about.

Obviously many players will cover up towards 100% of the areas in a game, i.e. traverse all the levels, and kill all the enemies. However, they will most likely spend 80% of their time in some specific parts of your game, select areas – scattered throughout the game – that make up only 20%. In multiplayer games, most of the action is usually centered around small parts of the maps. These are the kill-zones or chokepoints that developers need to be aware of.

Hopefully the few chunks where players spend most of their time will be nicely done “key locations”, that your team really took time to polish and make cool! Right?

Thinking 80-20

By mentally applying the 80-20 Rule to your work, you can force yourself to think about which parts of your content/features/assets comprise “your key 20%“. The stuff that will make up the larger amount of the player’s experience. This is not just to be found in level design. It might as well be within the core features (like combat, stealth or climbing) that the player uses all the time, or commonly used sound bits, animation, particle effects or GUI elements.

I personally have a hang-up with games where the basic “running animation” isn’t well done. C’mon, developers! I’m looking at that animation constantly, so please make it look good – or at least not so ugly that it catches my eye all the time.

Likewise, it might be the constantly used “explosion” and “gunfire” sounds you need to be aware of. Maybe you should put down that nice, moody soundbite, for a creaky elevator, that you’ve spend 3 days polishing to perfection. If it’s only found in one location of the entire game, it may not be worth the effort, and your time is better spent improving something that the player hears/sees constantly.

What I’m saying is: Make sure the content and core features that the players encounters most of the time are rock solid. That’s what we developers can learn from The Pareto Principle.

“Personal efficiency” and the 80-20 Rule

On a “personal efficiency” level, many people admit that they’re only fully efficient 20% or so of their workday. Those slackers!

Some feel very bad, about this. After a few bouts of double-distilled, crystal clear efficiency they can’t seem to get back on track, and might end up spending way too much time goofing off, surfing the web, writing blog-posts (like this one)…

Don't knock yourself if you're only really 100% efficient 20% of the day

My advice to you is: Don’t feel bad, it’s perfectly normal!

You probalby get 80% of your work done in those 20% of the day where you are most focused. Getting into the fabled “flow mode” can be hard, but once you’re there you often crank out top quality work. Of course, if you can find some way to stay focussed through a larger part of your workday, by all means do.

My personal experience is that I’m usually (mildly) efficient around 50-60% of the workday, but within those 60% there are “sprints” where I become much more efficient for about 45-60 minutes or so. Those peaks only happen once or twice each day, no matter how much I beat myself up about it.

Your results may vary!

Lastly, I’d like to quote this BetterExplained.com post on the same topic:

… don’t think the Pareto Principle means only do 80% of the work needed. It may be true that 80% of a bridge is built in the first 20% of the time, but you still need the rest of the bridge in order for it to work.

Thanks for reading, and don’t be afraid to spend 80% of your day dreaming up comments for this post.

More Laws of The Universe for Game Designers:

• Part #1 – Karma

Hiro face a bunch of evil samurai warriors in Mini Ninjas

I recently finished working on Mini Ninjas, IO Interactive’s new game for Xbox360, Ps3, Wii, PC & DS, due for release September 2009. If you haven’t heard about the game yet, there’s a ton of previews to be found around the web.

During work on Mini Ninjas I had some experiences in dealing with complex feature interactions, that led me to create a simple tool for designing gameplay features.

It’s a tool which can be used during pre-production, when you plan out the feature set you want to include in your game.

It can also be used as a “change management” tool, when you need to get an idea of the implications of adding, changing or removing a specific feature from a game that’s already in development.

I call this “The Feature Matrix” and I’d like to share some of the ideas behind it.

The problem with new features

As you might gather from reading the previews, Mini Ninjas is a game which contain quite a large number of different features:

Ninjas, their weapons, skills, moves, magic spells (and so on) all need to fit perfectly together with all the enemies, bosses, animals, collectibles and a horde of other game features, in order to create a coherent game experience without too many bugs, exploits and “weird” behavior.

The biggest problem with creating a game with many features is not the time it takes to make individual, new features. It’s how these interact with the rest of the game.

Complexity rises exponentially as more features are added to a game... *sigh*

A game’s complexity seems to increases in a non-linear fashion when you add new stuff, because features need to interact with other features in order to have any effect on the gameplay. If they can’t interact or DO anything they aren’t much good, are they?

Let me exemplify:

Let’s say we add a new weapon to the game, then obviously it needs to be able to hit enemies and have some kind of effect, otherwise it’s pretty useless.

So the different “enemies” features need to be modified to interact with the new weapon. But a lot of other features may also be relevant to update:

• Does the weapon make enemies react in a certain way (stunned/panic etc.)?
• Does it make enemies play special or behavior animations?
• Does it release any effects like fire/sparks/lightning?
• Does it use ammo, and need to interact with an “ammo feature”?
• Does it appear in inventory and need icons and properties to fit in there ?
• Can it be sold and need price/rarity for a “shop feature”?
• Can the weapon be stored/found/picked up and need to interact with “loot feature”?
• Can it be dropped and need physics or to be able to obstruct pathfinder?

… and so on!

Actually you would probably discover that adding a new feature means you have to look into at least half of your existing features and modify something (big or small) in order for it to work smoothly. So adding a new feature is adding a large number of special cases, some of these being such big issues they might even be considered an entirely new features themselves. Cutting out features will also have the same kinds of implications.

As more features are added or changed the complexity skyrockets, and it quickly becomes impossible for most human brains to cope with the implications of adding, changing or removing anything in the game.

No wonder game development schedules slip and games are delayed!

If there’s one thing you don’t want to mess with, it’s The Laws of the Universe. Going against Mother Nature (or Father Math) can and will end you in serious trouble. For your convenience The Laws of The Universe (for Game Designers) investigates the universal and inescapable laws of The Cosmos, and what they mean for us lowly Game Developers. Endorsed by 8 out of 10 Hermits.

#1 – The Karmic Law

Instant Karma's gonna git ya!

The Karmic Law is the principle that your deeds shape your future, in a cycle of cause and effect. Act evil, and evil will be done to you. Put in another way: “What you send out, you get in return” or “you reap what you sow”.

Put THAT in your pipe an smoke it!

Like it or not, you are tied to your Karma, and you can’t escape it. You can try. But you will fail. And while some may say that “karma’s a funny thing” it shouldn’t be taken lightly!

So what does this seemingly universal law mean for us lowly Game Developers?

Karma for Game Developers:

No surprises here – Simply treat the player like you’d want to be treated yourself while playing games.

Don’t be unfair, just to make your game more “challenging”. Don’t make players redo large chunks if they fail. Don’t add a super nasty enemy, just after the player has completed another hard challenge (unless you give them permission to save first).

The list of evil, karma-wrecking things you can do to the players goes on and on. Here are some more examples:

• Leaving too few coins for the player to buy ANYTHING in the shops he encounter.
• Same as above, but with bullets and enemies!
• Asking the player to do new (previously un-attempted) challenges (like logic/math) while under attack or time pressure.
• Making pitfalls that the player has no living chance to avoid, forcing him to do trial and error – with his life at stake.
• Giving the player a vital resource that drains away (like oxygen, flashlight batteries, themal energy) and forcing him to cross a section where he might not have enough to survice if taking a wrong turn.

…  I’m sure you hear a teeny, tiny voice inside, when you’re about to go too far. Listen to that voice! Don’t soil your Karma!

Most player’s hate it when you strip away their hard-earned powers and/or humiliate them (what a surprise!). If you still want to put a player in a situation like that, you better have a damn good reason (aka “payoff”) for the player, other than your artistic fancies.

“My vision is to really make the player feel downtrodden, because that’s just how life is”, shows you’re already getting what you deserve. You are getting pwnd by Karma. Better start being nice, ’cause next step is Buddhist Hell, and it’s not a nice place to be (you have to stay as long as it takes to empty a bag of sesame seeds, taking out one every 100 years).

On the other hand, you shouldn’t lavish the player with gifts, points and unlocks, before they get a chance to prove themselves and earn them. Karma should work both ways, and you get no brownie points by spoiling the player. It all needs to come together, in harmony you know – like Yin & Yan, Dude.

Thanks for reading. Feel free to confess your own bad karma in the comments.

More Laws of The Universe (for Game Designers):

• Part #2 – The 80-20 Rule

Emergence is a highly interesting topic, which is closely intertwined with the future of gameplay and game development. How basic entities interact to form new unpredictable and “creative” high-level behaviors is one of the keys to understanding complex systems, like societies or biological systems (from swarms to ant colonies) – Yes, even how our brains work – So naturally it has great interest for game developers, who are trying to simulate or create interesting environments, for the player to experience and have fun in.

“Emergent Behavior” has been a buzzword in game development for what seems like more than a decade now, and has become even more popular with the huge success of “sandbox games”, like the Grand Theft Auto series. But more linear games can also benefit from emergent systems, like physics or flocking. It seems like a topic that every serious game developer should look into, and consider designing for, when building the framework for their games.

With this in mind, I was pretty thrilled to get my hands on a copy of “Emergence in Games“. And immediately started tearing through it. Reading the book it quickly became clear that it’s a lot closer related to a scientific or academic paper, than a creative “cookbook”. The book spends a huge amount of the whitespace defining key terms, making bullet point lists, putting things in boxes with labels on, citing sources, and then summing it all up again. Sometimes this makes you ask yourself what the actual content of what you just read was.

The book is definitely a nice primer in the key terms of emergent behavior. It covers areas like “active game environments”, that allow emergence to arise, and zooms all across the spectrum to topics like “emergent narrative/storytelling” and “social emergence” (like the guilds, communities and economies that arise from MMO games). Most senior game developers will probably already have had a few thoughts on most of these topics, and won’t be strangers to the key points. Still, the book nicely covers all the bases and sums up what is known about emergence, from a game designers perspective.

That being said, it often feels like the actual content that all the “defining” relates to is almost wedged in, and you’ve read an entire chapter just to get three very simple (and obvious) terms defined in “academic grown-up language”, then those terms were extrapolated, and then summed up again. Some chapters feel like they put very little meat on the plate, for anyone except the completely uninitiated.

Halfway through the book I was still waiting for it to “get in gear” and deliver some fresh and creative insights into emergence. The book goes on to present a suggested framework for emergent behavior. The system is (understandably) very simple, since it serves as a basic example, but it seems like it could have been explained on a single page, instead of taking up a whole chapter with detailed examples and pseudo-code. I was thinking “yes, I get it – the cells can interact with each other according to simple rules – now get on it it”, but it never shows anything other than very basic fundamental interactions.

The rest of the book keeps on defining the entities that go into various emergent systems, and you realize that its core mission isn’t to be creative, but rather to establish a “language” with which to discuss emergence. While that’s an honest mission, it also serves to make it much less interesting as a tool for creative development, and more like a basic dictionary of terms. It seems a bit of a shame that it spends hundreds of pages teaching a “language”, but then doesn’t venture into the area of creating creative “sentences” with it.

For a creative, non-academic like me, it can at times be a very dry read, and it doesn’t help that there are very few examples from real-world games, to show you what all the big words relate to. This kind of stacking definitions on top of each other might be very appropriate for an analysis of a topic, but it wasn’t what I was looking for.

If emergence is a brand new topic for you, and you want a wide-spanning introduction to the fundamentals of emergence, as seen from a game deveoplers perspective, you should give it a shot. If you are looking for a creative cook-book with inspiration for emergent game design, this most likely isn’t the book for you.

It's a feature - not a bug!

Welcome to the first edition of “Bug or Feature?”. Cue the fireworks and big-ass, flaming logo.

Alright, there. Let’s settle down. This is serious business. An evil walks among us. An insidious ne’erdowell, a gameplay “feature”, known only as “Three Strikes and You’re out”.

Shhh.. I see one prowling over there.. Let’s hide and observe.

New Super Mario Bros

Shhh… Look at him… Do you see the mustache? Do you see the bug? No? Any features then? No, please don’t get mad… Yes, yes, yes… I know. Mario is a hallmark of video game history. How dare I question my betters???

Well, maybe because they’re stuck in design choices from the 80′ies!

Nintendo’s excellent track record in regards to innovation only makes things worse, since “The Big N” has countless of worshipers, all spewing out cheap clones of their games, containing the exact same shortcomings, in feeble attempts to get a piece of the dear plumbers action.

Now that I’m all worked up, we can get down to the point. Let’s have a quick look at the way the players progress in New Super Mario Bros:

Warning: Contains cruelty to turtles

In this, as in most other Mario games, you start your game with 3 lives.

In order to rescue dear Princess Peach you have to get through (clear) several “Worlds”, each consisting of a series of “Challenge Areas” (a single or scrolling screen area, containing many obstacles, platforms, enemies etc.).

If you die it costs you one of you lives, and the game resets you to the start of whatever “Challenge Area” you are currently struggling to overcome.

Great. No Biggie. Just try again! If it was only that simple…

When The Third Time Isn’t the Charm

See, when you die the third time, and lose your last life, you don’t get to restart the current challenge. Instead, the game catapults you further – way back – to the start of the World. In New Super Mario Bros. this can represent more than 15 minutes of gameplay. Actually, the further you’ve gotten towards the end of the World, the more ground you lose.

Click for bigger image

This is what I call, a clear cut case of “Three Strikes and You’re Out!”

So, what’s wrong with this. Adjust your binoculars and let’s zoom in.

First, let me clearly state; there’s nothing wrong with killing your players. It’s completely okay to “punish” players, by making them re-do challenges, when they fail. It’s accepted by all players, that they will “lose some ground” or have to redo a challenge if they fail it. That’s an integral part of a game being a game – Failure is an option.

So nothing wrong with that…

But ask yourself, what does the game designer accomplish by suddenly upping the ante, and punishing the player much more than previously, after a (seemingly arbitrary) number of failures?

Why would you ever want to throw the player further back, than you have just recently done? You make it painfully obvious that she has to cover a lot of the same ground again (and again, and again), just to get back to where she would have otherwise restarted, and then progress to the area where she died (ages ago).

Why not always restart players at the same distance to the current challenge?

It definitely is open to discussion exactly how far back you should push a player, when they die, and how much time and effort they should have to spend to cover the lost ground. But the decision to - only some times – push the player even further back than normal, why is that even considered to be an option?

The only meaningful reason is: To support the feature of having “lives” in the game.

The “lives” feature would be meaningless if it didn’t have any effect when you lost all of them. Then it wouldn’t DO or count for anything. So, you reset a player a bit if he loses a life, but what do you do when no lives remain? Obviously that calls for some EXTRA EVIL punishment to the player, for performing ever so badly in the game. They should be reset the hell back. Right?

Well, guess what. No. They shouldn’t. At least not if you want most players to remain happy and not get frustrated while playing your game. Google “New Super Mario save system” if you are in dobut about that.

The Price of Failure Should Be A Constant
Some might argue that it creates more tension in the game, as the consequences of failing (in terms of “lost time and effort”) gets more and more servere, the further you get. I don’t buy that. It’s a cop-out to strip away the players progress in order to make your game “exiting”. It only creates increased fear of failing – and eventually frustration when you do fail.

Once you establish the punishment for failing is a slap on the wrist, it feels kind of like “cheating”, when the game brings out the rusty-spiked, metal-plated bat, and smacks you to the far side of the world. It adds insult to injury so to speak.

EJECT, EJECT! Oh crap, that was the windshield wiper. There goes 20 hours down the drain!

Besides, if “fear of failure” was a winning formula, surely Steel Batallion must be the greatest game ever. It completely wipes your save games if you die! Fail to eject from your burning Mech-robot-thingy, and your saved games are deleted. Such great fun for the player! Oh, and if you DO manage to eject, you must spend “supply points” to get back into battle. Run out of supply points and – you guessed it – the game wipes your saves.

(Actually, I find this so insane, that it whips around to the other side and becomes effin’ cool. Big props to Steel Batallion. Still, I’d hate to see this save game system incorporated into any of my favorite games.)

Add to this, that New Super Mario Bros. actually DOESN’T allow you to save between every world. You can only save after clearing special castle worlds (which is about every 6th world). This can lead to several hours lost if your DS decides to run out of power while fighting the boss in World 5-6. And even if you don’t lose your battery down a pool of sharks with laser attached to their head, but just happen to lose your last life while fighting the Boss, it’s still all the way back to beginning of world 5-6.

Did I mention that the player does evetually get THE OPTION TO SAVE ANYWHERE in New Super Mario Bros. But you only unlock that feature AFTER completing the entire game!

I believe “Wha… But… Say… Whaaat?” is the correct reply to that statement.

Lives Belong in Arcades

While being a GREAT game, Henry Hatsworth (DS) has the exact same "Three Strikes..." flaw, which seriously lessened my enjoyment of the title. I kept dying at one of the (incredibly hard) later bosses. Sometimes I got to fight the boss all over. Other times (after losing my last life) I would get reset back, waaaay back, and have to cross lots of ground, and battle lots of enemies, to fight the boss yet again. Sigh!

So why do so many games insist on having “lives” and resetting the player like there’s no tomorrow when she dies? I’m guessing it’s mostly a historical thing.

Old Arcade games from the late 1970′ies used to only give the player one “go” – one attempt to win the game = one life. If you died you had to pony up, and toss in another quarter. The message was: “Beat this game or too bad, you need to start over”.

Eventually, lives were added to give the player more chances. On home consoles save games were not a regular feature yet, so the challenge became: “Beat this game in x tries”.

When save games were added it became: “Keep trying until you beat this game, and we’ll remember how far you got”.

Nifty! Players got a chance to see much more of the game, and even turn off the power and resume the game at a later time.

When we add “lives” to a modern game, fully equipped with a save system, the sentence becomes muddled again:

“Beat this game in x tries, however if you fail you can still try again. That is; just as soon as we get finished punishing you for playing badly, and reset you to a point where you have to redo a lot of the stuff you just did – Please do try not to die!”

Many developers, especially of 2d platformers, which seem to retain a strong historical connection to early arcade games, doesn’t seem to have noticed that save games have been invented, and the legacy of the arcades stays with us for good and for worse.

I’m also guessing that some developers might feel they HAVE to incorporate lives as a feature to stay true to their franchise? I can just imagine Myamoto-san yelling: “The big, green 1up mushroom STAYS IN!”

My personal opinion is that you shouldn’t bother having lives in your game; they are a completely outdated feature, provided you have some sane form of save game system in place. I’m really hoping this is one of the issues Nintendo decides to adress before releasing New Super Mario Bros. for the Wii.

Feel free to discuss below! Comment are very welcome.

“Game Design Gems” salutes a game for its outstanding game design. We look at the kind of games that makes us drool in awe, shake our heads, and go on a two-month “why-didn’t-I-think-of-that” drinking binge. This time I’m getting owned by Plants Vs. Zombies from PopCap Games.

Ready, Set - PLANT!

Plants Vs. Zombies has already been hailed as the cream of the casual crop. The game has an outstanding (for its genre) 89/100 Metacritic score and even managed to wrangle a big fat “9″ from the hands of the grumpy ol’ Edge Magazine critics. Not something they willingly throw after any game.

… and I can only join in the choir, and applaud this wonderful title. To speak nothing of it’s amazing style and personality, the core gameplay is beautifully wrought together, and fully deserves to be the topic of GrandTheftBicycle’s first “Game Design Gems” post.

You can find my review (in Danish) on the dr.dk game blog, or read my (poorly) translated version below.

Try out Nevermore and the other free student games.

Nevermore review

Meet Anna & Mr. Huggles - Main protagonists of 'Nevermore'

Have you ever tried getting picked on? Anna sure has. She’s a poor, defenseless girl, with only her teddy bear “Mr. Huggles” to comfort her, when the big boys are teasing. Luckily Mr. Huggles has a plan, which is sure to put an end to the bullying. A plan involving a large, sharp knife. You can probably figure out what happens next. Anna & Mr. Huggles depart on a playground massacre of epic proportions, and live out any  victims dream: Bloody revenge on the tormentors.

Conceptually Nevermore belongs to the school where the bizarre and blood-dripping meets the ultra-cute. The unconformed gets revenge on the establishment by discarding any kind of morals and butchering away. Lovely! While there isn’t much to hold against Nevermore’s concept and graphical style, the gameplay mechanics leaves quite a bit to be desired.

Anna is fairly responsive and easy to control. The big bullies are thrown through the air, with a couple of swift knife-cuts, trailing behind them a long spray of blood. The primary purpose of the game, is collecting this blood splatter, by raising the teddy bear over Anna’s head(!) Unfortunately this central feature is also the game’s biggest source of annoyance. The blood falls quickly to the ground, and you must attempt to correctly time your run towards it. Sadly, it isn’t really possible to get more than a small fraction collected, since your movement speed isn’t matched to the speed of the falling blood splatter. This means you never really feel that you’re doing it “right”. Unless you “cheat” and knock the enemies up against a wall, you will always miss the majority.

Likewise, there seems to be a lack of interaction with the enemies in the game. The big, blunt bullies march randomly around the schoolyard in a zombie-like daze, and don’t seem to notice their friends getting slaughtered around them. Sure, they will start chasing you once you get close enough, but it might have been a thrill to be able to chase THEM once in a while. Vengeance is sweetest when your enemies are driven before you, not quite as sugary when they don’t seem to care about getting stabbed to death.

Nevermore appears as a game where style has been the primary focus, while the game mechanics feels secondary. The game has something going for it, but the developers should have thought more about how the game’s primary “bread & butter” functions work. What is the player actually DOING, and how is this made fun and worthwhile to the player? Anna & Mr. Huggles is a charming couple with big potential, and I wish them the best in the future. The knife needs a bit of sharpening before it cuts to the bone.

Reviewed by Thomas Løfgren, Level Design Lead – IO Interactive.