Designing a Game: Part 2 - The Framework

With research done and the core of the game scoped out, the next phase is to start digging into some high level mechanics to suss out the overall gameplay flow. This is a broad topic, so before we dive in, I want to cover off two assumptions or conceits I'll be making here.

First, I want to remind you that this represents one approach to game design, specifically how we tackled the design of Highest Adventure. There's a lot of ways to achieve similar results, so I don't want to lock your mind into one single solution.

Second, I firmly believe in starting with a theme before diving into mechanics. There's a lot of debate about this in designer circles, but for me, I'm here to design games that are about stories. Therefore, communicating the story is paramount in my approach and thus the theme comes first, supported by mechanics. Sometimes I've thought about an interesting mechanic in isolation to a theme, but I mentally shelve these ideas in a mechanics bank for a later date. Again, there's a lot of debate about this, and perhaps I can dig into this in more detail later, but I just wanted to put my preference out there, because it informs how I tackle a project, as you'll see.

With that said, on to phase two!

Phase 2: Gameplay Framework

As I pour through the source materials (books, podcasts, etc), I start getting a picture of how I want players to move through the game. I know what I want them to experience, I know what I want them to feel, and I know what stories I want them to walk away with. Linking those three things together forms my gameplay framework, or flow.

Immersion

Let's take a moment and talk about immersion a bit because I think its super vital to a successful (in my estimation) game. To achieve immersion, I believe a designer needs to bring a player along for a journey where they can feel like they are a part of it, relate to the world, make decisions that make sense within the context of the theme, and come away from the game with a story.

For me, this is central to all of my games. In a world full of distraction, I believe the time a player gives you is an insanely precious gift. I want to make sure that I do my absolute best in spending that time by telling a story; creating a space for the player to explore and experience something.

Above: Theo and I map out the game's tension. There's a whole article to be written about how I map tension, but the short answer is that I map out the variables of x=play time vs. y=challenge. Here, Theo has mapped the locations' numbers to X and the locations' Threat/Danger levels to Y to come up with the tension curve as the player moves through the adventure. Using math models like this helps balance your game well before the first playtest.

So for Highest Adventure, it's all about making sure that the player senses the tension and stress of climbing the rockface, feels the thrill of a narrow miss, uses their cunning to overcome seemingly insurmountable challenges, and the exhilarating and satisfying sense of success as they finally reach the top of the mountain. So the next question is, how to craft that experience?

Beg, Borrow, & Steal

So in the case of Highest Adventure, Theo and I sort of "cheated" a little and used Lonely Cairn (LC) as a template for our gameplay. A word or two about this. It's often the case that new designers feel guilty about using frameworks and mechanics from other games, as though they are not being original. My comment to this is that there's not a modern game out there that doesn't "steal" at least part of their mechanics from other games. If you stripped Monopoly of its preexisting mechanics, you'd be left with a collection of random metal figurines. Dice rolling, trading money, random event cards, collecting cards of similar color, etc. all existed in games before 1935. What makes a game unique is not it's individual mechanics, rather how they are selected, combined together, synergized, modified, and woven together to make a wholly new experience. Anyway, back to Highest Adventure...

Choosing a Framework

So part of why we chose to pattern Highest Adventure on Lonely Cairn is that the latter told the story of a perilous journey where how you solved a problem determined life and death.

When I'm looking to find a framework for a project, I like to try and find games that tell a similar story to the one I'm making. I could have just as easily chosen Portal Games' Robinson Crusoe to pattern the game on. It tells a similar story, has the right level of detail, and offers a solid foundation. But here our game's parameters come into play. If you'll recall, we were aiming for age 8+ and a playtime of about 30min. Robinson Crusoe does not fit in that bucket, so, while it might serve as a good source of inspiration, it wasn't suitable as a framework.

Above: The gameplay flow for Lonely Cairn

On the other hand, Lonely Cairn (which indeed drew some inspiration from Robinson Crusoe) was a familiar framework to both Theo and myself. Theo, reflecting on the core fantasy points in the previous article, hit on the idea of turning LC's location line into a mountain where the player ascends to the summit, facing dangerous encounters along the way. For my part, I was keen to keep the game in the LC family (as you might recall from the product design image in the previous article). So with that, we settled on the Lonely Cairn framework for our game.

Adjusting the Framework

One thing to remember is that although a framework might provide an excellent skeleton to wrap a narrative around, sometimes you need to add new bones to cover specific outcomes. In other words, frameworks rarely fit 100% out of the gate and will need to be adjusted.

Above: The gameplay framework for Highest Adventure, note the subtle and not-so-subtle changes between this and the Lonely Cairn example above. These changes brought the game more into alignment with a climb up Everest.

For example, in Lonely Cairn, the player's token is a single ship, representing the whole Franklin expedition cutting through the arctic ice. Initially the thought was to have a single Expedition Token for Highest Adventure as well, but the more we listened to podcasts and read books, the more we felt that it wasn't going to work by viewing the expedition as a monolith. The expedition leader, John Hunt, needed to make decisions about who to send to the summit. The expedition was organized into assault teams that would make the attempt, and the rest of the support personnel. He had to juggle his two assault teams, and position them to help each other as they made their way up. Again referring back to our core fantasy points, we felt that the player needed to make similar choices. This meant that the Expedition Card would split into several cards, which in turn had knock on effects in the movement rules and balancing encounters.

Above: Theo maps out the game's locations on a map of Everest. At this point, we're validating if Lonely Cairn's nine locations works for Highest Adventure, or if fewer or more locations will be needed. As it happened, nine fit the story and mapped well to our Tension Curve above.

Not wanting to go into the details here, the point I'm trying to make is that the original LC framework got us most of the way there, but there was still a bit of work to be done to make sure that mechanics fit the theme and didn't contradict expectations. This is important because I believe anything that greatly risks pulling the player out of their immersion is to be avoided. Each time you do this, there's a risk that the player won't follow you back in to the story, and that's a chance that I'm not usually prepared to take.

Validating the Framework

I'm all about validation wherever and whenever possible. This is how I design and build swiftly. The more and earlier that you can test your mechanics, make adjustments, and re-test, the better. This concept is often referred to as "fail faster." Using math models and logic mapping you can catch a fair amount of imbalance in your core mechanics early on, well before the first playtest. So I've spent a lot of time coming up with processes and tools to do this. Again, this topic worth it's own article, but I'll cover it off at a high level here.

Once we knew the general gameplay framework and a high level view of the mechanics to include, it was time to map out a bit of a flow. I do this in Miro and it's here I'll dig into that tool a little. Miro is a collaborative whiteboard tool that's free to use. What I like about it is that you can map out the framework and test the logic by linking elements together. This helps give me a sense of what phases the player's turn needs to be broken down into, where mechanics slot in (or don't as you might find).

When mapping out the framework, I begin with the player's first action or decision at the start of the turn. I then play out the turn hypothetically, taking care to note each subsequent action and decision. This helps flesh out gaps in the logic and validate the core mechanics.

Above: This is the logic map of a mechanic I am developing for an exploration-themed game called Magellan, based on the Lonely Cairn system. Magellan faces several mutinies so I wanted to make sure it was something the player encountered as well. So I mapped out a draft of the Mutiny mechanic. This allowed me to mentally validate and iterate on the loop well before the first playtests.

Above: After a few mental playthroughs of the first Mutiny Loop, I noticed a few issues with the flow and made some corrections. I documented the new version and ran through that a few times. To be honest, I wasn't sold on 2.0 either, but that's OK because this process is doing its job and highlighting issues early on so that I can continue to iterate on the concept a little more. As a note I always keep the older versions to help trace my decisions.

Now that we had a core gameplay framework and flow mapped out, it was time for Theo and I to figure out what components were needed to manifest the framework on the tabletop. Stay tuned for next time when we dig into figuring out Highest Adventure's components list.