Foreword
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 coauthored, 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 coauthoring 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.
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;
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 oneinsix 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 sixsided dice, we have gone from six outcomes to thirtysix 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 thirtysix 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;
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 perseries 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 optin 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;
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 preproduction – 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.
Paul Nisenbaum 
8 Aug 2013 at 3:53 pm PST

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. 




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



Michael Joseph 
"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 AutoTune 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 socalled "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. 










Jason Carter 
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 
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. . . 












TC Weidner 
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 
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 
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.





R. Hunter Gough 
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. :) 




R. Hunter Gough 
For clarity, I would also suggest adding something along the lines of "At this point I decided that a 60% firstattempt 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.





Freek Hoekstra 
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 
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. 




Liviu Focsa 
Hello,
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 2nd variable? I mean the 1,3. Thank you. 




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



Mathias Neukam 
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? 

