Post by: Grant Rodiek
I hit a very big milestone for Sol Rising last night: the campaign is content complete. That’s right! After about 6 months I’ve completed 12 scenarios that tell the story of the Terran invasion of the Jovian system. This was a really big undertaking, arguably the greatest thing (using great to mean large) I’ve designed.
Every scenario includes a composition of ships for both sides, their starting positions, interesting objectives (other than just destruction), new Events, new rules, and story moments to precede and modify every mission. Just typing that gives me flash backs. The campaign booklet is 28 pages and over 11,000 words.
I’ve learned a great deal doing this work, much of which can be applied to other designs and work. The game is not finished, obviously, as it needs to go through more testing and iteration, but I thought it would be fun to draft a “mid-mortem” to write about what I’ve learned so far.
You may read the rules for Sol Rising here. You may read the campaign here.
Remove Passive Effects: This is a lesson that took a few iterations to really drive home, but it’s such an important one. Most of the ships in the game have abilities you can activate. The majority of them were abilities that you’d activate and use immediately. Cause and effect. However, about 25% of them were passive defensive abilities that would leave a status on the board. For example, you could activate shields that would modify a ship’s defensive properties the next time it was attacked.
This caused some issues:
- I needed to design a method to easily track this. This meant more tokens.
- Tracking these effects increased complexity in a bad way. Players had to pay attention to more to make decisions and play.
- I had to craft rules to deal with odd situations. What if the ship isn’t attacked? How long do the shields last?
On two occasions, my friend and design peer Cole Medeiros noted I needed to simplify them. He kept stressing cause and effect and how that simplifies things. After the first time I addressed some, but others remained. I thought it was better. After the second time, he offered the feedback with a twist.
“This ability prevents one damage when attacked next. Instead of forcing me to remember that, just remove a damage that’s already on the ship.”
Much. Simpler.
I applied this to all remaining abilities and removed them. Now, every ability in the game has an immediate effect. This has simplified the rules, simplified the abilities, removed components, and removed edge cases.
Passive abilities have absolutely ruined some games for me. I quit playing Seasons because I was sick of tracking what seemed like an endless stream of passive effects. I should have paid attention for my own game, but it took time to do so. Nonetheless, the lesson has sunk in (again).
Remove Conditional Abilities: In a game where you have activated abilities, it is crucial that in as many cases as possible you remove conditional requirements. By this, I mean: If X is the status, then do Y.
This is bad for a few reasons. One, it’s more complicated. The simplest form is to say: Do Y. By adding a layer, you’re making it more difficult for players to do things.
You’re also removing flexibility from the experience. Instead of letting players use simple abilities in new, unexpected ways, you force them to use the ability the same way every time. It makes the game more predictable and static.
Finally, and this was often the case for my game, I was creating conditions that were so unlikely to setup. They didn’t sync with the experience or the mechanics, which essentially rendered the abilities useless.
Your task when designing abilities is to focus on simple, flexible, highly usable abilities that excite the player. Give your players the tools to craft dynamic experiences. Don’t give them rigidly scripted game cards.
Design Mechanics and Content for the Game you Want: This sounds silly, but it is something you can overlook and fight against. In Sol Rising, I made the decision a few iterations ago to make the game a simpler, turn-based structure. This meant 1 player activates a squadron (move and attack). Then, the next player did so. And so forth.
However, I would frequently design odd mechanics or abilities that would fight with this structure. This continues the previous lesson, but I would craft abilities that would state: If 2 squadrons are in this specific position, you can do a thing. However, because players moved 1 squadron at a time, not 2 or more, it meant these systems weren’t playing nicely with each other.
Eventually, I found a way to keep the main mechanics very simple. Turn based, 1 at a time. However, I crafted a few simple, non-conditional abilities to let you move or attack with additional units.
The key lesson is to not fight against the framework you’ve created. Determine the experience you want, then craft a framework and the content to provide it. Keep your goals and mechanics in sync with one another.
When creating scenario based games, focusing on replayability at the outset is key. As a lesson from York, which has received feedback that it lacks replayability, and recognizing some of the faults with some scenario based games, I decided to really focus on replayability from the outset with Sol Rising.
Some games accomplish this better than others. With Memoir ’44, there isn’t much change between plays of the same scenario. The cards aren’t highly varied and the units remain the same.
One of my favorite scenario games, Mice and Mystics, adds in more varying elements. These include:
- Players can choose different characters.
- Players can choose different Abilities for characters.
- The item deck is large, so what players “find” as they play changes.
- The enemies that spawn in most rooms are randomized.
- The timing of surges really changes things.
- Optional side quests and routes to take.
- Dice based combat system.
One more good example is Robinson Crusoe. It randomizes scenarios in a few ways:
- You choose a random subset of Event cards every time you begin the scenario.
- You choose a random subset of Inventions every time you begin the scenario.
- The Event decks for each action are quite large and varied. Your successes and failures will change every game at different times.
- The order in which you unveil tiles on the island will change things.
- Players can choose different characters.
- Dice based resolution system.
For Sol, I started with “what good looks like” and evolved it for my own game. Although I pre-define ships and starting positions, I hope advanced players will modify these things. Other variables include:
- Dice based combat system.
- Events that take effect at different times, or not at all, and affect players differently.
- Completing bonus objectives.
- Persistent campaign effects as a result of bonus objectives.
- System failures to change how ships behave as the battle continues.
Finally, unlike Mice and Mystics and Robinson Crusoe, you’re fighting against a human opponent, not an AI. I’ve found this makes a huge difference on how missions play out.
The lesson, overall, is that if you prioritize something like variance and replayability at the beginning and factor it into your designs, you’ll see much better results. This isn’t something you can typically just layer in afterwards. The fact is that most players won’t play missions twice. I doubt most players even finish the scenarios shipped with campaigns. But, I want them to know they CAN play them multiple times and have a lot of fun.
Focus on the core first. This is definitely something for the “win” column so far. I knew from the beginning I wanted to make a scenario driven game of some sort. However, I didn’t even touch scenarios for roughly the first 6 months of development. Instead, I worked on how you command ships, how ships attack, how turn structure works, how abilities work, and more. This took a long time and in fact, I’ve continued to develop and change these things since I began scenarios. But, trying to build scenarios is very difficult. Doing so on top of a wobbly core foundation seems impossible.
The lesson is that before you go content crazy, or design scenarios, focus on the core. Make sure you know what a player’s turn entails and how your game works from start to finish.
Focus on one piece of content first. Another win, and a continuation of the previous point, is that I worked on Scenario 1 of Sol Rising far longer than any other. Before I made 12 scenarios, I needed to make one that worked really well. I had to revise the writing style for the narrative. I had to figure out what sort of Events were interesting and which ones weren’t. I needed to get a feel for objectives and communicating unique rules.
I’ve tested the first scenario far more than any other, but the lessons learned from it have informed and aided every other scenario. If you’re crafting a game with scenarios, or content sets, make one really really good before you make any more. Otherwise, you’ll be doing a lot of tedious iteration that could have been avoided.
The longer you work on a game, the more comfortable you’ll be with it. I have a few games I’ve been working on for a year or longer. Farmageddon and its expansion, York, and Sol Rising all qualify. What I’ve found with Sol, like I’ve found with the others, is that by spending a long time on something, the more comfortable you’ll be with it. Many of my best revelations and ideas for these have come about as a result of truly understanding the game, its strengths, and its weaknesses.
Obviously, if you can get a game signed quickly and it all works out, awesome. Congrats. Enjoy this heaping pile of my jealousy. But, if you’re working on more complex games (as I have a habit of doing, curses), give your game time to grow. Give it time to mature and evolve as it needs to. There are so many avenues these days to rush out a game, but I think you’ll find determined patience will render its own rewards.
At least, it has for me.
I’m excited to take Sol Rising into the next stages. I’m also chasing down some publishing leads and hope it’ll be something folks can experience in their own homes before our sun collapses.
Questions? Comments? Put ‘em below!