The First Two Tests
I am slowly going through my growing pile of emails from designers taking me up on my offer for assistance in 2018. It's very cool, a bit stressful, and a bit of work. With that in mind, folks commonly ask about testing, how to evolve a game, what to look for. Just this week I conducted the first two tests for my new game Ringworld (no relation to the novel). Following these two tests, I made updates. Using this as a case study, I'm going to try to cover this, both in detail and at a high level, to provide insights on how I went about this. Hopefully, you can gain information for your own designs that's useful.
To set the stage, some quick background. Ringworld is a 2-4 player euro-ish action efficiency game that plays in about 45 minutes. It's meant to be about a mid-weight game. The thematic setting is that a vibrant new planet has been discovered and a colony ship has been dispatched. Rival corporations/government entities have dispatched pioneer robots to prep the planet for human settlement. While on the ship, operators use control rings to send orders to the robots, but as you might expect from the distances involved, there is some confusion and errors. The heart of ringworld is its ring component. That's the origin of my placeholder name: Ringworld. The idea was inspired by the Exit decoder ring component. It seemed to me like a natural fit for an action wheel to control workers. The effect is a mechanism that's a little bit rondel, a little bit programming, and a little bit fun, toylike game component.
When ordering your robots (A, B, and C), you need to align the robot (outer ring) with an action (middle ring) and a strength (inner ring). In the image above green's Robot C will Move 4 spaces. The thing is, the ring is precise. It isn't up to 4 spaces, it is exactly four spaces. This means you need to manage a resource called Charge to modify your actions. The goal of the game is to build personal structures that provide benefits (a tableau of sorts) as well as communal habitats to house, hopefully, your colonists. Colonists are called down from dropships, but if left on the surface too long outside of a habitat, they die (gulp). There is no conflict in the game, aside from pulling somebody's colonists down early (and that's just a threat of tension mostly).
You can read the rules for Ringworld here. Comments allowed in the document.
The First Test
Above is an image of the very first test in progress. On the first test of a game, you need to have clear goals for the test itself. Those goals should focus on the heart of the game, not its supplemental supporting features. Here are some examples:
- Core mechanism: Is the primary thing a player does on their turn interesting, compelling, and functional?
- Unique: Does this game attempt to do something different than another game?
- Victory: Does your hypothesis for how to win the game, or its core method of conflict, indicate it can work? Does it have incentives and pressures?
- Structure: Does the overall structure seem to make sense?
- Content Types: Does it make sense for your game to have Event cards, or tableau actions? Focus there, less on the specific pieces of content.
- Determining first player
- Values behind scoring
- Tuning (aside from outright broken tuning, such as I get 5 actions per turn, versus 2 actions per turn)
- Tie breakers
- Individual pieces of content (Don't stress specific cards or powers)
To use Ringworld to apply some specificity to this, I needed to see if the core mechanism worked. This is less about all the actions on the ring, but if the core notion of rotating wheels to align actions made sense, was a thing players can fundamentally grasp, and provided difficult decisions. The result, I believe, is that it did. There was often tension between maximizing the output of one action - and potentially losing an action entirely for another robot - and thinking about future turns and where the ring roughly needed to be. The control card mechanism, which dictated the amount your ring turned, was a bit fiddly. There were also some tuning issues to address on the ring, namely the middle ring not having a blank/null space, to provide additional tension. There were also issues of timing resolution for Outposts, which are new bonus actions you can gain throughout the game to customize your ring. Something with which I was pleased was that typically within a minute, players would program their ring and have it ready to go. This meant little downtime for folks. NOW, this is something that can be a potential source of Analysis Paralysis for some players, but more on that later.
I wanted to test if the game's core victory condition worked. In Ringworld, you need to pull colonists down from the ship and get them into habitats before they die. Here, my game had some fundamental flaws. Firstly, the path to victory was too narrow. Players needed to be given incentives to diversify their strategy. Secondly, there was too much uncertainty involved. I had players pull colonists randomly from the bag to then populate the habitats. But, this was deeply unsatisfying. It was too risky for players to build a habitat, pull colonists belonging to someone else, and seeing those colonists fill up the habitat. It felt like having the rug constantly pulled out from you, so players played a game of chicken where they'd stare at each other. The game would stalemate.
I needed to see if the structures enhancing your tableau was meaningful. Aside from some content that wasn't very good, the options felt compelling, clear, and people were working against them. This was a good win.
Finally, I wanted to see if the approximate flow of the game worked. I think it did. Players get and give orders to their robots, quickly move them around and execute things, over time you see the board diversify and change, and the end game is clear and worked towards. However, the board was too open, which removed tension. Players could just go anywhere, so they saw little reason to move, or be wary of company. That needed to be fixed.
Ultimately, we stopped playing the game about 2/3 through what I think a full game would be. We found too many problems with the game's incentives that it made further playing pointless. I had what I needed.
After the first test, I made the following changes.
- I removed some of the hexes on the board to tighten it. I also added impassable terrain to further add texture and force movement.
- I cleaned up the outer ring to accomodate the new custom actions. I added a null space to the center ring to add tension. I also merged the two building options into a single one, as it was more confusing than interesting. Finally, I turned the null space on the strength ring to a 0, as that's what it is. Null elsewhere means nothing, but you can technically modify the strength with charge. A tiny UX improvement.
- I completely replaced all the Outpost custom actions. Some were too good (a fourth robot), some were too confusing, and some were pointless. I turned them into simple bonus actions using the existing actions.
- I re-tuned the control cards so that some of the "bad" ones had good options as well, to make it an actual choice. I also simplified how they are chosen.
- I provided point incentives for building structures to diversify options.
- Instead of pulling colonists randomly, at game start, you create pools of 5 random colonists. When you pull them, you must pull from a single pool. This means you'll mostly pull your own, but you'll also pull some from an opponent. This provided the right balance between having some variance and giving players some control.
- Instead of starting opponents on the edge of the board in clumps, I let players just place them at the start. It creates the "scramble" that I desire without frustrating and weird bunching.
- Colonists were originally placed on the board and there was a spatial relationship. This was stupid. But, I didn't have a good way to track how long until they expired. One round was too few. I made it so colonists are not "on the board," but in a board space called the Planet (Green). After one round they go to the Planet (Orange - Warning). Finally, they go to the Planet (Red - Expired). A simple, intuitive track.
That's a wrap for test one.
The Second Test
Above is an image of the second test of Ringworld. You can see the impassable terrain cardboard standees, and you can see where I shaded in hexes that are now "not on the board." At the top, you can see pools of colonists, sets of 5 random cubes, from which you can pull to put into habitats.
With the second test, and really, any subsequent test, you want to primarily see if your changes are good ones. At the end of a test you want to make assumptions that Solution X will solve Problem A. As you eliminate problems, you can move onto the next ones. Keep in mind though that your game is a living organism. In some cases, yes, you can remove an appendage cleanly. But in others, a tiny tweak will have a ripple effect. This may require a change to tuning, or a fundamental change to structures.
For example, when making York, I wanted to remove the Building Activations from Cry Havoc. They're notoriously confusing. I just made buildings passive. Once built, they did what they do. However, this dramatically reduced the value of the building resource. If you only build one or two times per game, as opposed to building and activating structures every round, you don't need that resource. It ruined the game's economy and made it far too easy to recruit, move, and do other things. It created card inflation! I had to create a new use for that third resource. I did, and it immediately fixed the issue and the economy stabilized again. Your game is an organism and you must think of it as such.
I made several tuning tweaks following the first game. Tightening the board, tightening the ring, tightening the game's content. But, my fundamental changes were to the game's incentives and victory conditions and how colonists were grabbed. As you win the game by housing colonists, these two are deeply connected. The quality of this change was immediately apparent! Players were grabbing colonists with confidence, but were also grabbing other players' to put the timer on them. Players would build Habitats and move folks in. You could see players taking risks, hoping to do everything in a turn with how they arranged their control ring, and you could see them creating less optimal, but more guaranteed turns. It had a really good effect.
Fantastic. Big change works. Now, let's say this wasn't the case. I still have that problem, and now I know two things that don't work. Also, I would hopefully have more information regarding why these didn't work, which should focus my behaviors and solutions. Ultimately, you should take actual notes on what you try, especially early, so you can better triangulate functioning solutions.
With the main change dramatically improved, my testers began chittering about other problems. Movement rules. Adjacency rules. The fiddliness of the control cards once again reared its ugly head. It would be time to fix that after two tests of meh. Also by the end, I could see some of my scoring options worked, others didn't. For one, giving players a bonus for having the most colonists in habitat was just a "rich get richer" situation. I removed that. But, I could also see that by making every colonist in a habitat one point, there weren't incentives to take bigger risks on building bigger habitats. Something to ponder.
I could also see that managing the wheel sometimes could be a little bit fiddly. As this is my core component, that's a huge red flag. I needed to address that. We finished the second test to completion, which is great as it meant we played a full game by the second test! We had good scores of 16/14/11. Dave, who won, did a little bit of everything. I went heavy on colonists, and Gibson got behind and struggled to get his wheel back in shape. Good stuff.
After the second test, I made the following changes.
- Scoring: No more end bonus for having the most colonists. I did, however, provide points for having the majority colonists in big habitats. Basically, take the risk to get bonus points. Simple, should be effective.
- I clarified movement and adjacency rules.
- I removed the control card mechanism and replaced it with something far simpler. Every round, you turn ONE wheel twice, clockwise. That's it. However...
- ...I made it so that every round has an event. This is to add a little spice and uncertainty. In many ways, it's a revised look at control cards. Instead of a fiddly draft, you now have a standard two moves. But, the event might add moves, reward bonus charge, turn off certain robots, or activate outposts. Thinking about the game as an organism, this makes charge more valuable, it makes the trade action more valuable (it allows wheel manipulation), and it improves the value of some of the tableau rewards. This should be a good, cohesive change that adds depth while simplifying the game. It also makes controlling the wheel less fiddly!
How did things end up going so well so quickly? Much of this has to do with the work I did before I started testing. Many people stress you should test your idea as quickly as possible. While I mostly agree with that, I think there are many things you can do to better improve your chances of early success. Five tests that reveal everything is bad are not inherently more valuable than two tests that confirm many things are on the right track. I suppose it all depends on where you want to spend your time and capital: early thought, or early live experiments.
I did a few things to bolster my chances for success.
Firstly, I took a "no text" approach. What this means is that I ensured all of the actions were intuitive and clear without a text explanation. My actions are move, build, gain the charge resource, settle colonists, and tweak the wheel. Now, if I want I can add new tableau powers that get more tricky, I can add assymetry to those so that every player's tableau is unique, or I can create a wider pool of outpost customization options. But, before thinking about how to expand my game, or make promos, or even add setup variety, I made a tight core suite of simple, intuitive, and useful pieces of content.
Secondly, I focused on my core mechanism and simplified the rest. The heart of this game and what makes it special is manipulating that wheel. Therefore, I used standard concepts of movement and adjacency. I use a very simple point structure for victory. I use a very standard first player rotation option. I use a simple, intuitive hex board without a great deal of commotion (though again, creating different boards is an opportunity for the game down the road, just like Concordia). One of the greatest mistakes designers of all experience levels repeatedly make is trying to innovate everywhere. They try to make every part of the game unique, or different, and it just isn't necessary. Firstly, it makes your job far more difficult. Secondly, it makes learning the game far more challenging. And thirdly, it makes the proposition publication that much more risky from the perspective of a publisher.
Thirdly, I wrote the rules out. Many designers hate doing this, but it's fundamental to the process. By writing the rules, you're forced to think through setup, first turns, mid turns, late turns, how the game ends, how you score, and all the pieces of content. As you write one thing, you'll remember that it conflicts with something you wrote earlier. It will help you create more cohesive and thoughtful designs sooner. Here is why this is important: most of us have friends who tolerate our prototypes. They like us, I think, so they agree to test. Testing is the most valuable resource as a designer. The more you squander it with stupid, avoidable errors, the less you get on testing the actual, quality game. Basically, write your rules so that you don't waste people's time. You do that early work to discover the early, avoidable bugs, and preserve your friendships for testing.
Fourthly, I devoted effort to layout and UX from the very beginning. I thought about how to make the game easier to learn and play. For example, as you build structures, you remove the tokens from the tableau and are shown their powers. If you look at the tableau below, Structures 2 and 3 have been built, revealing their powers underneath. I used icons from Game-Icons.net, and took the time to choose ones that helped communicate the action. I gave players simple round order on their tableau. The thing is, after I explained the game, I heard very few questions. Yes, people might ask clarification on the adjacency rules (which I fixed after test two), or ask to be reminded of end game scoring, but very few questions were asked about the actions, the tableau, or the flow of play. If you don't do things like this, and write rules, again, you're going to spend your first several tests on basic, avoidable errors that derail from the main challenges.
In Conclusion, your first tests don't have to be dreadful! From the start, focus on the core of your game. Focus on the heart that will make or break your project, the thesis statement of your design. Make sure the core of the game is fun, or has the potential for fun. Make sure that it has something unique, and that the incentives to win are useful and there. Address obvious content and tuning errors, but don't be distracted by them. Until your heart is in the right place, you're just changing the organism of your design too much. Try to isolate issues and address them one at a time.
After you have the heart in the right place, begin trimming away at the most glaring issues. Fix your broken scoring system. Nerf the overly powerful and obvious power. Clean up your text. Test these things and focus on them after you fix them. If they don't work, check your notes to figure out a new, better solution. If they do work, put them on the shelf and move to the next issue.
Start your games strongly by doing more work before that first test. Think through your game's structure and write the full rules. At least an outline! Keep your content simple and avoid complicated text as much as possible. Avoid thinking about setup variability and expansions for a long time. Put those thoughts away. Put serious thought towards your game's UX to get in front of simple questions you shouldn't have to answer.
Your first tests are important. If you get excited and start making something cool, that passion and enthusiasm will show forth as you keep at the game for a long, long time.