Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 25, 2014
arrowPress Releases
October 25, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

The Rational Design Handbook: An Intro to RLD
by Luke McMillan on 08/06/13 06:22:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.



Design is something that is highly personal - I have no problem with this and I have seen many unique and diverse approaches. What used to bother me was the mysticism that seemed to surround effective design practices. Having come from a music composition background where rules and heuristics reigned supreme, "zen" design was not something that sat well with me - especially when you consider the financial risk associated with "shooting from the hip". Authors like Dan Cook, Raph Koster, Joris Dormins, Steve Swink, Ernest Adams & Jesse Schell (to name but a few!) have made significant inroads in turning alchemy into science. One of the branches of this new approach to understanding games is Rational Design or Rational Level Design [RLD]. I have previously written a few articles about the concept here, here and here but I have never written anything publicly available which starts from the beginning. 

I had originally intended to put all of this into a co-authored, free open source text book called "The Rational Designers Handbook." I have since changed my mind and decided to turn my work in progress handbook into a series of blog posts right here on Gamasutra. This way, I can leave the co-authoring at the discretion of other game developers, scholars and educators. So here it is, the first part of the Rational Designers Handbook - An Introduction. 

What is Rational Level Design / RLD?

Rational level design (RLD) is a way of objectively quantifying elements of user experience in order to create a consistent game play experience. RLD is most commonly used to understand how various game elements impact on difficulty. As difficulty plays such a significant role in determining user experience (a precarious balance between rage and boredom!), we can use the objective, number driven system of RLD to craft user experience. Although RLD is now used to create much more than just game levels, the RLD tag has stuck and is now used to describe design activities using this data driven approach.

Why do we use RLD?

RLD is most often used on projects with significant financial accountability or where we have large teams of people working on the same project. Although RLD is about crafting user experience based on a set of objective metrics, it's wide spread use in large production environments is largely a consequence of risk mitigation.

In RLD game elements are modified and created based on observation of user data and informed approximations created by mathematical regression methods. The key benefit of RLD is that it unites teams of designers by quantifying production process which are usually considered to be too intangible or abstract to be represented by traditional means.

RLD is also a useful tool for students and those learning design. Unlike Zen design which favors experience and intuition over metrics, the RLD approach provides a framework and a process which can help to alleviate some of the mystery of effective design. Many designers who adopt the RLD approach eventually integrate its concepts into their own design style and create a type of Zen / RLD hybrid which is informed by experience and enhanced by logic.

Tools of the Trade & Requisite Knowledge

RLD benefits from the fact that many of the tools required to implement it are readily available, sometimes free and generally well documented. Although some large publishers and developers will have developed their own in house, proprietary tools you will be able to implement your RLD pipeline just as well.

  • Grid Paper (yes I said paper!)
  • Rulers, pens, protractors, set squares, scientific calculators etc.
  • Some form of spread sheet application

Beyond the tools, a good grasp of mathematics will help greatly.

The Purpose of this Article & Subsequent Updates to the RLD Handbook

This article (and subsequent articles) are intended to be a resource for those wishing to use RLD as part of their own design processes. This series covers a number of examples of RLD and how they have been implemented as both development and analytical tools. It is important to note that this series is part of the broad body of knowledge which informs game design. Throughout the series you will see links and references to other sources. I highly recommend that you take the time to read the work of these authors. Most importantly acknowledge that the process of design is usually very personal. You ultimately need to select the models and structures that you have the most resonance with.

Process & “Unsexy” Stuff: How do we create difficulty numbers?

To understand how we create difficulty numbers in RLD process, there are two main issues that we need to understand;

  1. Mathematically speaking, linear increases in complexity tend to create exponential increases in game difficulty.  Think of this as the link between your RLD tables and the actual psychology of players interact with the final products of these tables.
  2. RLD is always a starting point and there will always be elements of your design which cannot be expressed objectively with numbers.
  3. When numbers fail, then look towards chaos to create interesting game level experiences. 

Linear Increases & Exponential Difficulty

In order to understand where our RLD numbers come from, we need to closely examine point number one; linear increases in complexity, create exponential increases in difficulty. One of the key terms used as part of this process is dimensionality. Mathematically speaking, dimensionality is the number of spatial dimensions that we would need in order to enumerate every possible outcome of a set of modifiers.

As an example, let’s say that we are creating a game based around the outcome of a six sided dice. This six sided dice would be considered our one modifier. Statistically, we would say that our six sided diced is one probability space, consisting of six outcomes. The player could roll the dice and have a one-in-six chance of rolling any number. This type of ‘event’ has only one dimension, because we only need one axis to enumerate all of the possible outcomes. Although it is a little mundane, our enumeration would look something like this… (Figure 1)


Figure 1

If we expand our game to include the outcome of two dice (modifiers) then we have a set of events which needs to be enumerated using two axes… (Figure 2)

Figure 2

In the two dice event, we can see how one axis modifies the other – one plus one equals two etc. We can also see how every time one element is added to our designs, it exponentially increases the potential outcomes that the player has to sort through. By using two six-sided dice, we have gone from six outcomes to thirty-six outcomes. Not only this, but by adding one extra modifier, the probability of certain outcomes also becomes much more complex an interesting. By simply having two modifiers, we have a much more complex probability space: Events like rolling a sum total of 2 or 12 become one in thirty-six probability events whilst rolling a sum total of 7 becomes a one in six probability event. Although linear increases in modification lead to exponentially increased probability space, humans are exceptionally capable of dealing with these huge probability spaces. According to many, this is one of the reasons why we find such pleasure in identifying patterns.



We can visualize this concept in a different way by considering the amount of options a player might have at any one point as a branching decision tree. In the image above, we can see how having three options at any one stage (left) is exponentially more complex than only having two (right).

Figure 3

Figure 3 frames the RLD problem – whenever we modify or add a single element to a game, the growth rate of difficulty is not linear, but rather exponential to the point where a game will become impossible. 

Creating our RLD Numbers

Now that we understand how linear increases in complexity cause exponential increases in difficulty, we can now put this into the context of a level design. Let’s say that you have a jumping challenge with linear increments in the gaps between platforms. This example is created in Unreal Development Kit (UDK) using the default physics and control type. Here I have created a test level to get a feel for my spatial metrics – i.e. to understand how the actual spatial measurements relate to my experience as a player. (Figure 4)


Figure 4

Here I have four platforms which I want to jump between. Each successive platform uses a linear increase in the gap. In this example, I have spaced each successive platform 16UU (Unreal Units / approximately 32 cm in real world measurements)[1] further apart each time. Using this spatial test, I will ask a set of new testers to jump between them without any prior training. Once each tester is done, I log the amount of failed attempts at each platform. I also will personally observe these tests so I can equate arbitrary numbers with player experience. What is really interesting about these types of experiments is that you will invariably find that the fail rate will increase exponentially, even with these linear increases in separating the platforms.

Difficulty always reaches a point of exponential growth. This is best represented when you attempt to graph your data. Based on this exact experiment, I found that one in ten testers failed the easy jump on their first attempt. Two in ten testers failed the medium jump on their first attempt and six in ten testers failed the hard jump on their first attempt. This then led me to create a table (Figure 5), with three levels of difficulty; easy medium and hard. Each level of difficulty then gets assigned a number based on the fail rate of the test data. The "RLD Difficulty Value" is the number of failed attempts per ten total attempts. My hardest jump, is now assigned a difficulty of 'six', because six out of ten attempts were unsuccessful and this pattern continues throughout my table.

Figure 5

One important thing to note is that easy tasks will always need to have some element of risk AND that difficulty has a finite limit before it becomes impossible. (Figure 6)

Figure 6


Modifiers & Dimensionality

So we now have a simple set of numbers which we can use to design our jumping challenges. But these numbers make a few assumptions; 1. The player will always jump to platforms which are at the same level AND 2. Having a challenge with eight successive easy jumps is equally as difficulty as a challenge with one hard jump. We know from experience though that this is simply not the case. To correct these two issues, we need to look at what our modifiers are, and what their values should be.

Figure 7

In the context of this example, the first modifier that we should consider should be gravity (Figure 7). We know that there is going to be a finite point to how high a platform can be before the player will simply be unable to reach it. We also know that there will be a point at which the platform is so low, that the player will incur gravitationally induced death when they land on it. By performing a spatial test we can quantify these numbers and use some simple mathematics to work backwards from these points.

Figure 8 is an example of the type of sandbox environment that should be created when working with any new game engine. These environments will change depending on the game, but in the context of a first person game, (which UDK is best suited to) you will need a way to test things like run speed, jump distance etc. Most importantly though, these types of test environments are invaluable for understand the “feel” of your game. Based on this interaction, when then attempt to transcribe feel into a system of objective metrics.

Figure 8

Figure 8 is a series of jump platforms created in UDK – the engine I will be working with. Each set consists of nine different platforms of incrementally increasing height and gap width. The aim of this particular sandbox is to find the limits of what the player can do and then use these as our maximum / impossible values to figure out our RLD metrics.

Figure 9

We know from our initial testing data what our RLD numbers are for a player jumping between level platforms. We know that one in ten testers failed the 128UU jump, two in ten failed the 160UU jump and six in ten failed the 192UU jump (highlighted in red in the table above). Based on this data, we now know that we should never exceed a value of six for any single permutation of width x height in the probability space.

This is the point at which you will need to get your hands dirty with some math – specifically we need to use the data we have and find the best way to interpolate the missing data. We know that difficulty tends to be exponential, so it stands to reason that we should probably consider an exponential regression as our starting point. A suite of regression tools can be found here.

Figure 10

Using this tool (Figure 10), I entered the data that I had at each point. Sometimes you will find that you need to try a number of regression methods before you get to one with an acceptable margin of error. In this case an exponential regression did not work, but a logarithmic regression did. (Figure 11)

Figure 11

Now that I have been provided a formula to use, I can then use this to interpolate all of my missing data for one series. When I graph the result, I can see my exponential curve start to form. What we have now is an approximate fail rate for each permutation along one axis. Our task now is to go back into the spatial test that we have created and try to find the limits of each series. For the purposes of this example, six will be the number that we use to indicate our maximum value.)

Figure 12[2]

At this point you have two options and I will list these in order of preference;

  1. Interpolate the remaining values based on your perception of the problem BUT only use the numbers one, two and six to represent easy through to difficult
  2.  Use the regression tools to mathematically figure these values out.

Although approach two can be mathematically correct, it often does not accurately represent the psychology of the problem. For example, as you run up to one of these ledges, there will be either internal states of doubt, tension, ease etc. that will skew the actual result. It is for this reason that I personally like to interpolate the values manually. Again, this reinforces the point that RLD is a great starting point for some elements of the design.  As you can see from the table above, I found that small increases in height didn’t actual make the challenge noticeably harder until we approached a jumping challenge which was 64UU high. Once we have established these maximum points, we can then define anything that is either off limits – highlighted in black, or anything that really shouldn’t be considered a risk (i.e. values less than one).

For situations similar to this, you will often find that you end up with a set of RLD numbers which mimic this pattern; (Figure 13)

Figure 13[3]

You can use graphing tools to fine tune each one of these curves via a system of trial and error, or you could also use the regression tools which were employed to create the original series. The trial an error method involves graphing the data in real time on a per-series basis and then adjusting the numbers in each series until you achieve a graphed slope, similar to the one created using the proper logarithmic regression method.

Now if you are a designer and you a freaking out about the amount of math used to interpolate these values then you need to hear my dirty secret for figuring these values out. Believe it or not, aftermarket car ECU tuning software often has table systems which will automatically perform logarithmic, exponential and polynomial regressions based on limited data sets! They tend to work the same way that Microsoft Excel’s linear regression tool work, but with modified formulas. The best part is if you normalize your RLD number, punch them into the tuning software of your choice, it will give you a pretty get complete set of data points ready for tweaking!

Arbitrary Modifiers

In the context of this example, the last modifier which we need to consider is the amount of consecutive jumps required before the player can reach a check point.  The more consecutive steps, the greater the difficulty - sometimes though it is very difficult to find an objective source to help us define a number for modifiers like this. Unlike the gravity modifier, this could potentially be a near infinite number before we consider it to be “impossible.” It is situations like this you will need to employ arbitrary modifier numbers. Even though these numbers are arbitrary you need to base them on some type of logic.

Figure 14

In Figure 14 we have a jumping challenge with three distinct sections. Each section is divided by a ‘safe zone’ – an area in which the player can rest and opt-in to the next section of the challenge. As designers, we need some way to define how difficulty is impacted by the amount of steps in each section. As the amount of steps per safe zone can be quite long, it important to select a number sequence which when graphed, maintains a fairly consistent slope. A good rule of thumb can actually be derived from the field of audio engineering. If you have one violin player which is too quiet how many extra violin players will you need to double the volume? As odd as it sounds, you would need about ten violin players to create double the volume! The same principle could be applied to this example and the perception of difficulty. For this reason, your sequence of numbers should be a near linear progression.

Figure 15

In my example above, I have created a series of modifiers which I can then use to modify the overall difficulty of each section of the jumping challenge. These numbers are based on the violin example above – when we multiply something by ten; we roughly double the perceived difficulty. As a lead designer, you will always needs to specify a cap for systems like this so that others in your team will share a consistent set of rules for the development of game spaces.


The Psychology of the Numbers

Some argue that RLD is an overly deconstructionist, mathematical and sterile way of designing game experiences. When used in isolation, without any type of testing this may seem to be the case, however when used correctly and consistently, RLD is a powerful tool when it comes to shaping user experience. Difficulty plays a significant role in the play experience. A game should always been designed with peaks and troughs of anxiety in order to keep the player engaged, however unexpected breaks in this “natural” progression can be highly detrimental. (Figure 16)

Figure 16[4] 

Crafting Experience with RLD

Now that we have a clear idea of the impact of our modifiers, we can then look at crafting an element of our level – specifically a jumping challenge. Although RLD may seem clinical and sterile there is a very measurable psychological element to getting it right (and wrong!). The ideal game experience is one in which anxiety rises over time and where there are no flow, or immersion breaking elements in the design. Difficulty has the largest impact on this sense of immersion and flow. When things are too easy we tend to become bored, when things are too hard we become frustrated. By using RLD to craft our game experience, we ensure that difficulty follows this tried and true formula.

To demonstrate the link between the game experience and careful level construction via RLD, let us continue the jumping challenge example. We want to craft a jumping challenge with three distinct sections (Figure 17). Each section is punctuated by a safe zone which acts as a check point. We have defined our RLD numbers for each jump type first based on user testing and then via mathematical regression (and more testing). We have also expanded the dimensionality of our challenge via the inclusion of two more modifiers: gravity and the number of steps. Now it’s time to pull out the graph paper and draw a concept.

Figure 17

If we were to graph this example without the modifiers then we come up with something like the example below (Figure 18). We have a challenge which starts off easily, yet has a massive jump in difficulty.

Figure 18

By graphing only one modifier our graph suggests that we have created an experience breaking challenge. When the anxiety / boredom labels are applied to this graph you can see how we step out of the flow channel and into dangerous territory (Figure 19). But we are missing two important modifiers of this jumping challenge.

Figure 19

Once we add in our extra modifiers, our graph starts to become more indicative of the actual player’s perception of the challenge (Figure 20). The extreme spike that we saw in the second part of the challenge is somewhat mitigated. However the second part of the challenge is still problematic.

Figure 20

RLD is always a process of revision and refinement. The most obvious thing that stands out about this challenge is that the middle section is far too difficult in its current form. We need to look back to our modifiers and see what we can do to address this. We have a few options which we can use based on our metrics;

  1. Make the gaps smaller
  2. Leave the gaps the same and adjust verticality
  3. Reduce the amount of steps

One of the most important elements of RLD is to discern the priority of your system of metrics. You will want at least three metrics – primary, secondary and tertiary. The relationship between your metrics will generally always be transitive. That is, adjusting the primary metric will have the greatest impact and will have a cascade effect on the secondary and tertiary metrics and so on.

In the case of this challenge, if I simply use smaller jumps (i.e. the easy jumps) then I know that this will more than likely change the challenge from being too hard, to being too easy. I then defer to my secondary metric – vertical modification / gravity modification. Logic dictates that asking the player to jump to a lower platform will be slightly easier. We still keep the same gap, but simply apply one of the modifiers to tweak the numbers.

Based on this logic, you can use the table you created earlier in order to create a combination of jumps which result in a slight lowering of difficulty. In the case of this jumping challenge, simply lowering each consecutive step by 16UU should give me the desired result (Figure 21). It is important to note that I referenced the table BEFORE drawing and calculating the actual example. This is the benefit of doing RLD work as part of your pre-production – iterations become quicker and solving design issues becomes more process orientated rather than a process of arbitrary guestimations.

Figure 21

When we graph the end result, we come up with a much improved distribution of difficulty (Figure 22). Remember that difficulty is always relative - as the players skill increases, so too will there perception of what is (and is not) difficult. Although this graph shows the third part of the jumping challenge moving into anxiety territory, this is where your distributions should roughly be.

Figure 22

Chaos & the Primary Metrics of RLD

Chaos is what happens to a player’s perception of difficulty when you jumping challenge goes from this… (Figure 23)

Figure 23

To this…. (Figure 24)

Figure 24

In both instances, our jump platforms are distributed using the same height and distance metrics, yet the representation of the challenge is different – maybe even chaotic.

Now when I say chaos, I don’t mean disorganization or haphazard, random & uninformed design decisions. What chaos is in the context of RLD is all of the modifiers, (both of the game and of the players mind which are evident in the game play experience) which are not able to be easily expressed in a quantifiable and objective manner. Although we do not quantify these phenomenon, we nevertheless use them and consider them in the process of RLD. Put another way, chaos is the part of RLD which we do not represent numerically, but is nevertheless an integral element of player experience.

A good example of the chaos element would be considering the role that aesthetics play on the perception of difficulty in our jumping challenge. We could implement the same jumping challenge numerous ways aesthetically. Although we may change how the puzzle or challenge is implemented using various artistic approaches, the numerical difficulty and percieved difficult may be very different. For instance, one implementation of the puzzle or challenge might have deafening, atonal audio overwhelming the player and another version may be identical, bar the audio. Which one is more difficult? The answer is that both of them are equally as difficult from an RLD perspective, it is just that one would be perceived to be more difficult based on aesthetic alone.

In my next post, I will explore the notion of global metrics and how we can account for these 'other' elements which impact on difficulty metrics.

[1] The conversion between UU and real world measurements depends largely on how the underlying physics system has been written. Although many different games use Unreal Engine, the translation of UU to real world measurements varies slightly.

[2] The black sections indicate permutations that are off limits. In the case of Figure 12, this blacked out sections are impossible under normal circumstances

[3] Just like the example given in Figure 12, more sections have been blacked out in this table to represent permutations which are too simple to be considered a puzzle.

[4] This explanation of the “Flow Channel” is derived from Jesse Schell. The art of game design a book of lenses. Elsevier/Morgan Kaufmann, 1st edition, August 2008.

Related Jobs

Forio — San Francisco, California, United States

Project Manager / Producer (Games)
Yoh — Vancouver, British Columbia, Canada

Build & Test Engineer
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States

Senior Sound Designer - Infinity Ward
Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States

Multiplayer Level Designer - Treyarch


Paul Nisenbaum
profile image
As a 62 year old newbie to games/game development, is see game play:

- Too easy=boredom=abandonment
- Too hard=frustration=abandonment

And this varies by a players experience with games in general.

Christopher James
profile image
Exactly why a game needs to be properly balanced.

But generally 'too hard' is more complex than that, as players want challenge. The 'why is this frustrating' is the more important question to answer and solve for from a designer's perspective.

Essentially if the player says "I could have done that better", then they feel in control and are actively problem solving. If they say "The game is cheating / broken / etc..." than they are not thinking about the problem and see it as negative feedback as they are not in control over the solution.

Roberta Davies
profile image
This was very interesting! And not just because RLD is my initials.

Michael Joseph
profile image
"Design is something that is highly personal - I have no problem with this..."

Except you do. I'm not sure how we can interpret it any other way than a desire to depersonalize game design when you immediately go on to say...

"What used to bother me was the mysticism that seemed to surround effective design practices."
""zen" design was not something that sat well with me"
"...especially when you consider the financial risk associated with "shooting from the hip"."

as well as link to a REALLY BAD (to be honest) loaded piece by Dan Cook.

Except that
a) Dan Cook's description in the link you provided is biased and makes a bunch of unfounded accusations and assumptions. (e.g cowboy designers are only good at creating clones. what?!)

b) Neither Dan Cook or yourself (or Koster or others) have proved that "zen" style of game design is a significant problem. You only SAY that it is a problem. I would SAY the biggest problem with game design has little to do with style and more to do with business encroachment into the design process.

c) RLD actually sounds like another design encroachment tool by the business side so that any hairless monkey can churn out a game. (i.e the creative designer's role and power is marginalized and the "hack" designer's role and power is increased)

d) How many talented designers actually want to make games this way? I don't think RLD is for them.

I think your RLD solution (which introduces a host of new potential problems) is presented without first proving that there is any actual need. In my mind, zen/cowboy game designers are not the problem with games turning out poorly.

RLD reminds me of the Auto-Tune used by some singers with questionable talent. I would much rather just work with quality talent in the first place.

Lot's of pretty pictures and graphs here though.

p.s. I think I mostly have a problem with the Dan Cook article you linked to. I do think there's value in trying to find optimal settings and layouts for things at least on a micro level. But so-called "cowboy" designers have already been doing this since the beginning. The caricature described by Cook doesn't really exist. Designers have been practicing rationality all along. The choice between "zen" and "rational" doesn't exist.

Luke McMillan
profile image
A passionate reply! :)

I have worked with a number of designers who would describe themselves as Zen designers, but the deeper you dig, the more you find that they have an internal system which they apply BUT they aren't very good at articulating how it works. As design is often about rationalizing your assumptions, it helps to have some type of framework to use. (and a system is even more powerful if it is a shared approach with common and consistent terminology.)

You make an interesting point about Auto-tune though. It's funny how commercial music is largely considered 'illegitimate' artistically due to its processes of production. It wasn't so long ago where the application of science to music (in the form of drum machines etc) was considered artistically new and novel.

As I said in the intro - acknowledge that the process of design is usually very personal. You ultimately need to select the models and structures that you have the most resonance with.

Also keep in mind that RLD is a tool for risk mitigation (from a financial sense) so it's usage is determined mostly by financial accountability, rather than artistic integrity. :)

Paul Tozour
profile image
@Michael: I am with Luke on this 100%.

He's presented a useful tool for design; whether you use it or not is up to you, but it's undeniably useful for solving certain problems.

Trying to denigrate it as "auto-tuning" or writing off people who use design tools as "hairless monkeys" or as not being "quality talent" really doesn't help at all.

When you describe "encroachment" by the "business side," it's very revealing. We're all on the "business side" in the end; if we're not, our businesses won't make it very far.

From everything I've seen, design is the biggest source of risk in game development by far. It's been responsible for countless project delays and failed launches. Trying to create and provide better formal design tools and processes and build a shared design language can only help us move design toward a genuine discipline.

Daniel Cook
profile image
I will note that my essay is from 2005 in a time before social games or the rise of F2P in the West. There were several intriguing examples of what might come, but I failed to fully account for the influx of venture capital and the resulting bubble of grubby capitalism.

Tools can be used for good and for evil. The tools of math gives us both these computers and weapons of vile destruction. One should always be wary of demonizing the tool when it is the user of the tool that deserves censure. A lot of good can be buried with knee-jerk Luddite reactions to advancing tools.

Independent of all the horrors of misusing theory in game design, the basic concepts work quite well. It is another means of understanding the experience you seek to provide. Putting number on something doesn't invalidate an emotional gut response, it gives you additional insight.

What I have noticed is that building your game from the ground up with the various combinatoric properties and modifiers ends up resulting in games that are often easier to refactor, easier to add content to and can result in lower development costs.

Of course you may get none of these benefits. Tools depend greatly on the competence of their wielders.

Re: Cowboy Designers. Yeah, this extreme stereotype exists. I've worked with several in my career. But it is very much a spectrum and most folks are somewhere along it.

Paul Tozour
profile image
@Michael: Raph Koster just wrote a really well-thought-out reply to this:

I agree with Raph.

Jason Carter
profile image
From what I've seen this is common practice. I remember reading an article / post by one of the guys who worked on Super Adventure Box in GW2 and they were using colored difficulty painting for jumps in it.

At least to me design is part mathematics (balancing) but a lot of creativity. And Creativity should be the primary focus. Then you can balance it if you want to / if it's way out of tune.

Lewis Pulsipher
profile image
Game fans tend to fall into these categories in their beliefs about games:
All Games Are Math. (I recall one designer saying RPGs are just spreadsheets.)
Games are About People (Psychology).
Games are About Stories (which can be seen as a subset of People).

RLD appears to be turning all games into math. Is it practical to try to quantify psychology? Or the human desire for stories?

Reducing it from "game design" to "level design" ought to make it less impractical.

RLD is certainly an interesting point of view. . .

Paul Tozour
profile image
I don't see it that way.

Math is just a tool.

It doesn't mean your game is "about" math. It can be about whatever you want it to be.

Just because you use math to help design your game doesn't make it "about" that any more than using wood and nails to build your house makes your house a statement about wood and nails.

TC Weidner
profile image
@Paul I agree, and to be honest building a house at its core is all about math. Math is what allows it to be a viable structure.

Paul Tozour
profile image
Yes, but so what? Building a house isn't about math; it's about providing a space where people can live and be happy and go about their daily lives and not have to think about the way the house was built. No one should have to see the wood and the nails or worry about the math behind their house when they walk through the door after work.

Same thing with game design. Math is a tool to help us create spaces for people to play in, nothing more.

And yes, it's an important tool, and one I think every designer should be very familiar with -- but it's still just a tool we use in construction, not part of the goal for the final product.

TC Weidner
profile image
who said anything about having players worry about the math? Good game design and art and gameplay is all about hiding the math. That being said, the structure of the Game/house still totally rely on the math.

And I sure hope who ever built your house worried about the math, because the math and the physics are the only thing keeping it standing. A blueprint is really nothing more than math and design. And this blueprint principle is what I take this whole diary to be about.

Rowan Edmondson
profile image
I think this is also somewhat analogous to music. The fact that there may be reference to underlying math in the form of time signatures or key by the musician doesn't reduce it's creative of expressive validity.

TC Weidner
profile image
I agree, the foundation of a game and its design has to be about the math. The core of the design is math, all the other more fun aspects, art design and so forth are just ways to hide, brighten up the math. Math allows for balanced fun games. While I tend to think in single players games, math can be fudged here in there in favor of fun, in multi player games however, math has to rule. Its what will allow balance and a fair playing field. Without balance and a fair playing field nothing else really matters, your game is doomed.

Look at sports, at the heart of all our beloved sports is math. Math spells out the rules, it why sports work. Math allow for a concrete set of fair rules.

quick example ( pet peeve of mine)I watch MMO game designers seemingly create character classes on the fly while the game is already deep in alpha /beta, and think, how? why? Math tells me these classes all have to be built together at the very beginning, as they all must be part of the same equation. All balancing out as without balance you have inequality and an unfair playing field. In alpha and beta it should all be about disguising the math in the classes.

There is beauty in math, that same beauty IMHO also needs to be chased in game design.

Great article.

Patrick Haslow
profile image
I think this is a helpful system for generating best practices, and I also look forward to RLD Part 2: RLD and the Art Department.

Tom Smith
profile image
I like the thought behind the approach, but it seems too laboratory to be practical in most situations. Toward the end, you allude to psychology as an external factor that can invalidate these numbers. I think there are a lot of factors like that - pacing relative to other neighboring content, multiple gameplay features mixing (shooting while jumping, to continue the Unreal), control input types, etc. etc. It quickly becomes more data than you can reasonably extrapolate into defined difficulty numbers. That said, this does seem like a good starting point - test a few variable against actual players to get difficulty range, then extrapolate to set starting values for the rest of the game. But I think tweaking from there is always going to be more Zen, by necessity. Which is not a bad thing.

Luke McMillan
profile image
Thanks for the comments Tom. In terms of practicality, an approach like this really helps on large scale productions where you need to create lots of content, particularly in relation to game spaces.

From a level design sense, often the end result of this process is not a set of tables, but rather a set of modular building blocks which can be set as pre-fabs in the level editor / scene manager OR defined in a document which is used by people undertaking greyboxing.

Taking this approach may seem impractical to begin with, however it greatly speeds up production where you have large teams of people all working on the same content. I'll elaborate more on this in future posts in this series.

You are right though, there are a lot of variables which could potentially be mapped, however certain variables have more impact on difficulty and therefor need to be figured out first.

I am aiming to cover the entire process in this series so please stay tuned.

R. Hunter Gough
profile image
You lost me at the "arbitrary modifiers" section. Previously you'd presented the axiom "linear increases in complexity, create exponential increases in difficulty", and everything was subsequently presented to support this axiom, but then you say "when we multiply something by ten; we roughly double the perceived difficulty" which seems like the opposite of what you'd said before.

Can you please clarify?

At the very least, this article has inspired me to make a single map with zillions of little "jumping tests" for my next game (or whatever the gameplay equivalent is for that next game) rather than just one jumping test which I tweak between attempts. :)

Luke McMillan
profile image
Thanks for taking the time to comment.

I see what you are saying and it looks like I could have better introduced this element. Although I present the modifiers one after the other, their value is not equal. In most cases, these modifiers tend to work in a hierarchy or in some cases in a transitive relationship.

The lower in a hierarchy a modifier is, the more it needs to be used to make any noticeable impact on difficulty. In my RLD shorthand, I try to visualize this by placing lower importance modifiers lower in the overall order. Often this comes naturally because you may not have thought of something like the amount of jumps before it becomes an anomaly in your testing data, so you as a designer will add it into the next available slot of your table.

R. Hunter Gough
profile image
For clarity, I would also suggest adding something along the lines of "At this point I decided that a 60% first-attempt fail rate was the maximum difficulty I wanted for this game. For the rest of my examples, I'll use that '6/10' as the maximum desired difficulty." somewhere around Figure 5. I kept seeing 6s popping up in the text later on, and I didn't understand why you were fixated on the number 6 until it dawned on me halfway through writing my first comment.

Luke McMillan
profile image
Good point! I'll add that in.

Freek Hoekstra
profile image
thank you, you delved quite deep into the nitty gritty of the design process.
I find that there are two parts to a design, the numbers, the difficutl the layout, and the parts where you go with your gut and "ignore" them. these parts are the soul of a level, sometimes the storytelling elements (not to say these aren;t following a ruleset of their own) but the most memorable parts are distinct in one way or another.

that is not to invalidate your approach, actually I believe that getting these values will give you more time to tune, and "break the rules" where that can be beneficial, while having a safetynet to fall back on. it is a great basis from which one can build. and because less time is wasted on the mundane more time can be allotted for the special, unique memorable moments/areas.

I see it as the great painters of old,
the good painters knew the rules and abided them,
the great painters knew the rules and knew when and where they could break them for effect!

Nat Tan
profile image
There seem to be a sizable population of skeptics who all like to define design under the "creative" portion. That is true, but I guess the problem is that they're also missing the core concept of RGD which to me is the foundation of RLD.

The idea is that as designers, we need to properly articulate and define out the challenges and it's controls well in advance on paper, then RIP, and then iterate on those controls. Creativity comes from defining your intended game/player experience and determining the challenges that arise in crafting your game to provide that experience. From that point on, we then create the separate mechanics and how we scale them with the RGD process. Once the RGD defines the core mechanics and it's metrics, then we derive the RLD from there.

How does this help? Well, we are able to do this all on paper in a quicker amount of time than it takes to code anything. It structures the game mechanics in a way that the programmers understand what needs to be "modifiable" by the design team, and what can stay static. Most importantly, it helps us visually plan out progression and flow on paper before anything is created, which can cut down on a lot of time spent needlessly wandering around and hoping a "creatively undefined" mechanic works.

That being said, it is not the end of all and rationalization is only part of the process that helps us in the design and creation of the particular game that it is being applied to.

Luke McMillan
profile image
I have found the RLD approach to really support RIPs as it gives you something very concrete to test.

You could always base your RIPs on specific data sets to test your logic as well.

Liviu Focsa
profile image

Very interesting article and I would like to use it more in my games because it would save a lot of time tweaking and tuning difficulty progressions, but you lost me a bit at figure 10, could you please be a little more precise on what you did there to get the 2-nd variable? I mean the 1,3.

Thank you.

Luke McMillan
profile image
Hi Liviu. In figure 10, I have manually set 4 data points (instead of 3) to test the margin of error and also to see if the regression model is producing the types of results that I saw in testing.

Chirag Chopra
profile image
One of the best post I've read on Gamasutra! Thanks for sharing the info!

Mathias Neukam
profile image
Hey Luke,
First of all, I liked this article a lot, not only because I am very new to Game / Level Design (just graduated) but also because it reminds me of a common problem I encoutner when working with my team: Explaining myself to them. Explaining why I want my design decision like that and not like that. This is, in my opinion, a necessary skill for any designer in general. Thats why I also can't agree with a lot of the "arguing" here about wheter Zen design is better or RLD is only limiting our creativity. I really think it helps a lot having tools to explain why we do things certain ways. Just by saying "oh well I just have a feeling this is good" usually doesn't convince a coder to program a feature that might be more effort.

Anyways, I have a question about the jumping puzzle part 3. In the table above Figure 15. it says there is 2 easy jumps and 1 hard jump but I can't really figure out where the 2 easy jumps are in Figure 17.
Furthermore, from where do you get the values of Figure 21? (1,45 and 4,34) I suppose they are from the logarthmic regressen but are not included in this article?