Category Archives: Uncategorized

Screen Shot 2016-08-02 at 3.06.12 PM

Zen and the Art of Game Design

While chomping through the remainder of Robert M. Parsig’s epic book during this flight my thoughts pondered over how game design might exist within a qualitative value system in both a practical and metaphysical sense.

While reading a few things became apparent:

We are becoming lost in our own mythos.

As this gaming medium grows older its concerned professionals and academics, talented & hardworking, have become hopelessly wrapped up in Aristotelian method. New genres, definitions, mechanics, and algorithms are churned out continually, ‘experts’ of the medium go to enormous lengths to rationalise & categorise these entities into rigid defined objective blocks. Why experts do this? …Because of our faith that we can design our own successful games out of these blocks. The problem is that belief is  a complete lot of offal, and has lead in an awful lot of smart people to squander their time making low quality games.

Any salty developer who has seen the tides of change knows there will never be a formula to winning, no matter what infallible tower of logic we try to build.

Scientific method applied to game design makes little sense.

In science we try our best to approximate the rules of nature. Through testing and hypothesis mankind brings itself closer to finding what’s ultimately ‘true’ in our universe. Over time we have come to regard this scientific method of hypothesis and testing as the beacon of civilisation. To the extent that as a collective we consider it our manifest destiny to shine a light on all of natures secrets.

It will come as no surprise that game developers and academics are mere humans. Being wrapped up in our value system we diligently apply scientific reasoning to games in order to seek out the pure ‘truth’ of it. Only that the ‘truth’ designers seek in our field is ultimately engagement, a totally subjective phenomenon experienced by individuals.

Our beliefs are proven wrong continually, yet we are incapable of letting go of them. Because to let go seems crazy.

Routinely we see games that do not adhere to established formulas of engagement become successes. When this happens designers: A) Twist existing success formulas to incorporate our new reality B) Create new hypothesis on what creates engagement, add it to our forever growing list C) Be devout, hold on to existing beliefs and dismiss anomaly as a fluke.

We cling to objectivity as it seems that to let go of it is to admit that game design is a purely subjective discipline, hence cannot be rationalised. On the shop floor its far easier these days to say things like ‘Our parts mechanic will drive revenue and retention’ rather than ‘Our game will succeed because we care about it, hence players will care about it’.

Our methodology is cheapening what we make.

We butcher games up into subjective and objective chunks, game teams will commonly consist of people who are classical (concerned with underlying forms and architecture) and romantic (concerned with aesthetic, connotation and feeling) thinkers who work on each chunk. Game design could be considered the thread that joins these equally important schools of thought to create something engaging and stimulating. When game design as a profession becomes scientific and objective in nature we wind up shipping ugly products that are objectively good but very often subjectively bad.

Game design should not be regarded as objective nor subjective, but qualitative.

Game designers are seekers of high quality experiences. If you are a designer and you do not strive to live a high quality life how can you hope to create a high quality game? Without a natural feeling for what is ‘good’ we often rely on tips and tricks as a shortcut to try and achieve it, throwing in mechanics, features and flourishes that we have seen elsewhere and often coming up short. If one truly wanted to make the perfect game that engages millions, then it follows you must strive to live perfectly, then design naturally.

It’s 2am now and this plane is shuddering through the early Bangalore mist, soon we will touch down. Thanks Parsig.

Math in Game Design Pt1: The Level Curve

Game system design can seem like sort of a dark art to the more creatively inclined. Which is a shame as it can prove to be a powerful tool in your arsenal. Furthermore you needn’t have knowledge of material any more advanced than what you learned in high school. All you have to do is learn to apply math to simple game problems.

I feel that I can usually get a good idea of a designers pepper by looking at their formulas. In general there are three levels of understanding:

  • A designer can create a system that makes sense.
  • A good designer can find ways to make that system intricate and scalable.
  • A great designer will see how numbers translate into player enjoyment and frustration.

In this blog I’m going to start to share some game problems and examples of how the power of math can solve them. This post is aimed as an introduction so I will start with the most basic examples:

Problem #1: The Level Curve.

This is such a staple, but a lot of aspiring designers I know have never even made a level curve, the mind boggles!

A level curve is straight forward in isolation, but it could impact a great many faucets of your game. So, It’s best to ask yourself some general questions before you begin.

  • How many days should it take to experience everything your game has to offer?
  • How much EXP are you dishing out per kill/race /click?
  • How many battles/races/puzzles do you want per level?

Try your best to conjure up some solid numbers in answer to these questions. You may think it too difficult to accurately pin it down. Some people prefer to playtest prototypes constantly to get a feel for the underlying numbers. Others build elaborate simulations and run those thousands of times. If you are starting from scratch, it’s best to go with what you ideally want in your game. Personally I love plucking ideal numbers out of the air, its roughly 100x faster then building anything!

These numbers will be your guiding star, your constants in a sea of digits. They are the framework of your level curve. Your level curve could well be the central nervous system of your game. Don’t be scared to make these seemingly big decisions on the spot, just dive in, it will be alright.

If you are building an RPG your answers to the above questions might look something like this:

  • (8 days) ~ 200 hours to complete
  • Player gets 10exp per battle + another 6 per level they are at.
  • (lvl1) = 1 battle, (lvl2) = 2 battles, (lvl3) = 3 battles, (lvl4) = 4 battles, (lvl5) = 5 battles, (lvl6) = 6 battles, (lvl7) = 7 etc…

Great job! Thanks to these values the math seems like a zero brainer. Let’s open a spreadsheet and make a simple graph.

Level Battles required EXP won per battle Total EXP accumulated
1 1 16 16
2 2 22 38
3 3 28 66
4 4 34 100
5 5 40 140
6 6 52 186

Xp Curve

One basic curve! But wait… How do we know how long it will take a player to actually reach level 6 in the above example? It’s impossible to know if you don’t have an idea of the time it takes a player to perform an action that awards EXP in your game.

Again, I suggest aim for your ideal, and later build your game according to that ideal. You are the designer after all. As the designer I might say that a race in my kart game should take on average 3 minutes to complete. Also I believe that my game should last 20 hours. Following the 1 race for each level rule I wind up with the following progression:

XP Curve 

If each race is 3 minutes and I want my game to last 20h that means my game is ~400 races long. Wow! But let’s be honest, the player won’t spend all that time racing right? Ideally I want 5 minutes between each race for tuning the car/ decorating. Accounting for the extra 5 minutes per race changes our level curve to this:

Xp Curve

The number of races seems reasonable to me. But it now takes the player 20 hours to reach only level 17. Ouch! I want the player to get to level 40 by the time they have sunk 20h into it. In order to do this I need to make them level up faster in fewer races.

To do this we must increment the number of races required to level up a lot more gradually each level, to do that we have to introduce a delta value that we use to increment the number of races by every level.

Level Races required to level up Races Delta EXP required  (rounded) Total EXP accumulated (Rounded) Total races run
1 1 0 16 16 1
2 1 0.1 22 38 2
3 1.1 0.1 31 69 3.1
4 1.2 0.1 41 110 4.3
5 1.3 0.1 40 162 5.6
6 1.4 0.1 64 226 7

 

Simply put, the number of actions (races) required to level up = the number of actions it took to level up previously + the delta. Your delta can increase or even decrease as the levels rise. Depending on where you want the player to grind or simply take it easy.

I have to calculate the XP required per level a little differently adjusting for this smoother, more gradual curve. The amount of XP earned from a race is still 10+(6*player level). But I multiply this value by the ‘races required to level up’ number to get a more accurate measurement of how much XP the player should have to earn to attain the next level.

Deltas are my go-to technique for level curves because it gives me the ability to control the curve as closely as I would like. This is particularly important in earlier levels.

Resulting curve:

Xp curve

Other methods:

I have not seen it done on live games but I have often seen budding designers attempt a completely formulaic approach, usually leveraging the Fibonacci sequence (or similar). Curves of this nature generally use a derivative of the following formula:

Basic Formula:

  • Current level = F
  • XP required to reach current level = N
  • N = (Xp required to reach level F-1) + (Xp required to reach level F-2)

Curve Result:

Fibonacci curve

So this curve is obviously not practical due to the rate that it escalates. But we can alter the formula to make it nice and smooth.

Basic Formula:

  • Xp = (Xp required to reach level F-1) + ((Xp required to reach level F-2)*0.1)

By multiplying part of the formula by a factor of *0.1 we slow the climb of our curve quite visibly.

bad xp curve

While you might make a neat curve from 1 – 100 using this kind of technique, you have set your game up poorly for any additional levels you may want to add down the line. You will likely wind up dishing out exorbitant amounts of XP to keep up with new level requirements. It seems inevitable that you would find the need to slow down the curve at some point.

Conclusion

By now it should be clear that building a lovely level curve is not rocket science. As long as you define your constants before you start. If you are struggling to think of some clear numbers, ask yourself the following questions to get started:

  • How many days should it take to experience everything your game has to offer?
  • How much EXP are you dishing out per kill/race/puzzle?
  • How many battles/races/puzzles do you want per level?
  • How much time does it take to perform one battle/race/puzzle?

Use your constants as a set of requirements that your level curve has to conform to. Initially identify the primary action of your game (such as fighting) and figure out how many primary actions a player should perform to get to the next level.

Secondly, you should build your curve formula to be easily adjustable and scalable. As most games released now are often actively updated and maintained, level cap extensions are common occurrences. If you don’t have control over the XP requirement ramp in later levels, you may wind up placing unreasonable requests on players. Bad numbers = unhappy players, after all.

Oliart.co.uk

Dungeon Keeper – Teaching us how to play or pay? FTUE gets greedy

What is this hullabaloo over Dungeon Keeper? I’m certain that I spied it as an editors choice only a few days ago. If it really is so rotten, how could it be featured on Apple’s storefront? I decided to take a whiff of the alleged stink and make my own judgement.

IMG_0426

I derived the most fun during the first session from slapping the imps. But ho! There is a game beyond this. A game that MYTHIC insists being taught to us one devious step at a time via an FTUE.

IMG_0422

Gamers of my generation…Demographically defined as a core gamer aged 20+ Cash rich but time poor (generally monetizes at $0.25+ per DAU). Never like being spoon fed an FTUE. MYTHIC games are probably well aware of this. But alas here we are being taught how to ride a bicycle again. Or are we?

While watching my first building being constructed the Horned Reaper’s voice blurts out “don’t be stingy!”. Feeling disparaged I begin question my accuser. Why does this game dish out petty insults while forcing me to watch a countdown timer anyway? I have learned how to build a building, may I move on with my life? Except MYTHIC says I’m not done, MYTHIC does not care about the building or the timer, I’m missing the real lesson.

IMG_0423

None of that construction nonsense matters! I must learn to click the big green gem button. Why? Because statistically once a player has clicked the green gem button they are likely to click it again next time they see it. Humans are pretty silly like that, we can make a habit out of clicking on buttons.

Honestly, I make freemium games for a living, I could let one simple button press slide off me like spilled curry, heck I might even think of implementing something similar. But here’s the kicker, I have to watch the reapers hand jab at the gem button no fewer than four times throughout the FTUE. In fact I watch the floating hand longer then I actually play.

IMG_0424As a grand finale to this farce of a tutorial, the creature summoning menu becomes completely inactive for over three minuets while the dreaded hand continues its tireless jabbing. I know the agenda, and perhaps I’m just being stubborn at this point. However, I’m 25 years old, by now I know how to swipe a credit card and don’t care for further practice.

In conclusion, It seems there are now two distinct types of FTUE that exist in the field of Game Design today, there’s our beloved “First Time User Experience” and now the “Forced Training for Unwitting Expenditure”.