The Rule of the Loop (Part 2)

posted in: Game Design | 0

Hi! As promised, here’s part 2 of the Rule of the Loop. In Part 1, I discussed the basics of the rule. Now, I’ll go into the specifics like how we use it in Balangay Entertainment™.  If you didn’t catch Part 1, you can do so here.

The Loop we use at Balangay

The Simple Loop

In Part 1, I discussed the simple iteration loop involved in Game Design.

Simple Iteration Loop

The simple loop is good as a theoretical framework but it’s not detailed enough for actual use. As I said in Part 1, the challenge of game design is squeezing as many Effective and Efficient Iterations out of your development timeline. This simple model doesn’t give any guidelines on how to make iterations effective and efficient.

Not-as-Simple Loop

At Balangay, we use a more detailed model with more steps in order to ensure effectiveness and efficiency. This loop was heavily influenced by the one “Art of Game Design” but edited to suit our own needs.

Balangay Game Dev Loop- did I mention I suck at Photoshop?

Breakdown of Steps

Before I discuss how this loop ensures effectiveness and efficiency, I’ll just briefly discuss each step.

  1. Defining the current Design State
    • What is the current game design?
    • Before you know what has to be tackled in the next iteration, you have to review what you currently have.
  2. Listing of Risks
    • What are the Risks (problems) with the current game design? List them down.
    • It’s here we start looking for problems to tackle.
  3. Shorlisting of Priority Risks
    • Among the list of current Risks, which are the riskiest? Which are the biggest problems that are closest to the core of your design? Which are the most important problems to address?
    • We usually shortlist the Priority Risks per iteration to 2-3. We’ll sometimes tackle some non-priority Risks if they are inconsequential or “easy-to-fix”. (Warning: describing a Risk as “easy-to-fix” can be dangerous thinking and will be discussed later).
  4. Generating Solutions and Ideas
    • What are the ideas to solve the Priority Risks?
    • Now that you know what problems to tackle, it’s time to use your game design skillz to fix them.
  5. Prototyping of Solutions and Ideas
  6. Testing of Solutions and Ideas
  7. Assessment of Tests
    • Which ideas worked? Which didn’t work?
    • Which ideas/solutions do we add to the current design state? Which do we abandon?
    • It’s not uncommon for a Priority Risk to not be solved in one iteration. Solutions can not work out as intended.

After Step 7, it’s back to Step 1 for the next iteration. Usually Step 7 and 1 are mixed since the assessment of the tests will be what defines your current design.

Risk Analysis

Risk Analysis is what we use to make sure each iteration is Effective and Efficient. An Effective iteration substantially improves your design while an Efficient iteration is completed in a minimal amount of time. Risk Analysis is Steps 2 and 3 in the Not-so-simple Loop. 

risk analysis
1337 PS skillz yo

(Reading “Art of Game Design” again, I found the term Jesse Schell uses is Risk Assessment. They’re the same thing; we just ended up calling it Risk Analysis by habit.)

If iterations are the building blocks of a good game design project, Risk Analysis is the planning stage for each iteration. We always frame each iteration in the Risk/s (problem/s) we are trying to solve.

Risk Analysis starts as an open session where team members just say all the problems they see with the current design (Step 2). Once the problems are exhausted, we analyze each Risk to see if it’s a Priority Risk (Step 3). Priority Risks are the biggest problems with the current game design. They can be as specific as “The action economy is unbalanced to player X” or as generic as “The game still isn’t fun.”

I’m looking at you 2k and Marx

To determine which Risks are the “biggest”, we analyze them with respect to the core design. We ask the following questions:

  • What part/s of the game is this Risk associated to and how close is this part to the system core of the game?
  • How dependent are other parts of the game to the problematic part?
  • How many parts of the game are affected by this problem?
  • How drastically will the game design change in order to solve this problem?

Risk Analysis ensures effectiveness by focusing the efforts of the iteration into solving specific problems. It ensures efficiency by bringing order and steps to the process.

Games as a System

To help answer the questions above, I have to first state that a game is a System.

A system is a complex whole made up of different interconnected parts.

What makes a system complex is that the parts are not independent of each other. In other words, if you change one part, the change affects every other part of the system. Sometimes these changes can affect your game in large and unexpected ways. Keep this in mind when doing changes to your game design. Get into the frame of thinking that you can’t truly predict the results of each design change you make.

How “Core” is a Part?

Game parts are not made equal. Some are more at the center of your design than others. The more “core” a part is, the higher the likelihood that making a change to it will cause a rippling effect and change other parts. The closer your problem is to the core of the design, the higher it’s priority. If you deal with the “non-core” problems first, you are building on top of a flawed system. When you finally go about fixing the core problem, the solution might change your design so radically that it will make your solutions to the non-priority risks obsolete or irrelevant.

All that hard work…

A simple example is a design overhaul. There are times when your design is a dead-end. For example. you’ve come to a realization that it just isn’t fun and you’ll have to start from scratch. If you already had all the layouts and art commissioned, you’ll be left with tons of assets that you can’t use. You could probably recycle the art but how about the layouts? Why even put yourself in that situation when a little planning could have avoided the headache. Art is often not a core issue until later on when you approach production. Tackle the Priority Risk first: Was your game fun?

Why you’d end up Tackling Non-Priority Risks First

In practice, there are a couple of things that can go wrong though with your Risk Analysis. Here are some problems I’ve had.

  • Not listing all the Risks
    • Seeing the Risks in your design is a skill that is honed through experience. Games have so many parts and it is not uncommon to miss out on a few Risks every now and then. Learn from your mistakes to foresee Risks before your game is built on wrong assumptions.
    • For example: As a tabletop game designer, one of the Risks you have to always be conscious of is production cost. To make a game commercially viable, you must minimize the components in your design as much as possible. It is always a Risk up until you get the quote from the manufacturer and are happy with the cost.
  • Not writing Risks just because they are too vague
    • “Not fun” is a perfectly valid Risk. Sometimes, you might feel hesitant to write it down because it’s too general. Writing it down is the first step to reflecting on what make your game “not fun”.
  • Wrong Priority Assessment
    • Sometimes, you may rank a Risk as non-priority. In my experience, this happens either because of inexperience or “Laziness”.
  • “Laziness”
    • Testing takes time and effort. Sometimes you might feel that the change you introduced is too small to justify the effort for testing it so you choose to test something else instead. Sometimes, you may be right (especially if you’re doing public playtests that cost money and a time to organize). Since it’s your project, it’s up to you how you want to skin it; just be aware of the danger you’re putting your design in by not tackling Priority Risks first.
    • Earlier I said that we sometimes tackle non-priority Risks because we feel they are “easy-to-fix”. Sometimes they are simple issues like typos. Other times, we are definitely putting ourselves in danger by assuming they are “easy-to-fix”. You can allow yourself the leeway as long as you’re ready to deal with the consequences.
  • “Procrastination”
    • Priority Risks can be daunting to tackle. They could be difficult issues that need a lot of brainwork to solve. They could be also be scary to deal with since their solvability can make or break your design. You might be tempted to “procrastinate” by tackling non-priority Risks instead. “Procrastination” gives the feeling of being busy without really pushing your design forward. To avoid “procrastinating”, learn to sometimes take a step backward and view the “big picture” of your game. Stop and do a proper Risk Analysis. Then, be brave and slay the biggest foe! You’ll have to tackle that big Risk eventually if you want to finish your game. The more you delay, the more problems you’ll have later on.
They will haunt you.

Fun is not the only concern

At this point, it’s also important to note that fun isn’t your only concern as a designer. Risks can come from all sorts of place: manufacturing cost, target audience, artwork, funding, marketing, shipping, etc. Be aware of these and add them to your Risk Analysis to get the complete picture on your project.


In summary:

  1. Games are made in iterations.
  2. Efficiency: Keep each iteration as short as possible to maximize the number of iterations in a given amount of time.
  3. Effectiveness: In each iteration, tackle the biggest and riskiest problems in your design FIRST.
    • Smaller problems might go away when you solve the big problems so don’t waste your valuable time and resources on them.
  4. Don’t assume your game is fun. Test it!
  5. Always properly assess each iteration to make sure you’re pushing your design forward.

But where are the Horror Stories?

In Part 1, I promised to share some Horror Stories from when you don’t follow the Rule of the Loop but this post is already really long. I try to keep my posts at 1,000 words and this is already way beyond that. Maybe in the future I can make a post about those specific incidents

Thank you for reading. 🙂 Follow my blog if you like what you read. As always, leave a suggestion, question, violent reaction, and/or comment. Until next time 🙂


Follow Nico Valdez:

Game Designer

Nico is a game designer, programmer, songwriter, ex-audio engineer, amateur fiction writer, and president of Balangay Entertainment®. One of the less competitive members of Balangay, Nico only wins against 2k, Marx, and Aya when he's played the game before and they haven't. Nico always wins against Aa. He'll play almost anything as long as it's not loud. He likes euro games for their strategy and thematic games for their roleplaying. He doesn't like party games that much because they get too noisy for his ear disability.

Comments are closed.