Last summer I had the opportunity to work as the developer for SeaFall, a Legacy game from Rob Daviau and Plaid Hat Games that’s set in a fictional world in the dawn of the Age of Sail. It’s Rob’s third published Legacy game (Risk Legacy, Pandemic Legacy: Season 1), and the first that was created from scratch, without incorporating an existing game.
I learned a lot working daily with Rob, and he pushed me to be a better designer and developer every day. Here are some things I learned while working with one of my heroes.
1) Player experience is the most important thing
When I first started making games, I was completely convinced that they came from one of three places – theme, mechanics, or components. That’s where you’d start, right? The first time somebody told me, “It’s about the player experience” I shrugged it off like the new-age nonsense it was. Predictably, my first games were boring or hard to understand.
As it turns out, the nonsense isn’t nonsense. It’s the most important thing in a game. SeaFall is a long, intricate campaign that tells a story in no specific order, a story players both weave and have woven for them. The experience of being a part of the overall narrative is the most important part of the game.
Rob has said before that a legacy game only means that the game tells a story that players take a part in. That story has to be reinforced in every way possible – through the game mechanics, of course, and in what players do for themselves and to each other, how they gain information and use it, where they go and what they do. It all ties together to support this beautiful dive into a thematic, interesting world.
2) “Good enough” isn’t good enough
Every single game I’ve worked on has had a piece of it that fit pretty well, but didn’t exactly work the way I wanted or didn’t completely reinforce the theme of the game. As a developer, my job is to find those things and weed them out, to show them to the designer and ask, “Why is this here? And how could we do it better?”
I watched Rob pour hours into systems that already worked well, and pick through hundreds of playtest notes and questions to hone in on seemingly small issues. As it turned out, some of these issues gave us perspective into whole systems of SeaFall that were antiquated and could be updated, or removed altogether.
I told Rob that I thought SeaFall was a publishable, very good game the first time I played it, and we spent six more months on it after that. Before this experience, I never would have put that much extra work into a game I thought was already good enough. Lesson learned: ‘Good enough’ isn’t enough.
3) Solve the biggest problems first
Those long lists of notes and questions are called “punch lists” and they were the highlight of my morning for months. It’s tempting to start with the small things you know you can fix – “should I roll two dice, or three?” – but often that’s wasted work. Rob taught me pretty quickly that you should identify the one or two biggest problems you’re currently faced with, and solve them first.
SeaFall is a big game, and if we’d spent the time to solve every little problem first there would have been a lot of wasted time. As it was, we were able to revise and update quickly and efficiently, and push through sets of problems efficiently.
4) Every rule has a cost
I might be wrong about this, but I think every rule in a game has a cost. That cost is expressed in accessibility, in teaching time, in how often players will put a game on a table. People like to express mastery over things they understand, like to play games that make them feel smart and capable and confident. The fewer rules there are to understand, the more those rules flow naturally from the theme of the game, and the easier it is for players to develop the heuristics necessary to play well. Players that play a game well will play that game more often.
If a rule doesn’t make sense, or you can’t explain it easily, find a way to cut it. It’s that simple. Eric Lang has said in numerous places that inexperienced designers often want to fix problems by adding complexity. Rob showed me in SeaFall the virtue of addition by subtraction – masterful design work done by removing unneeded thing to introduce clarity and draw the focus to the best parts of the game.
I think about this every single day that I work on games now – what can I remove from this, what can I combine, what can I simplify, that will make it easier to get this to the table and bring the fun to light?
5) The last thing you add is often the best
In the late stages of development, Rob and I finally felt comfortable with where SeaFall was, and were very nearly ready to turn it over to Plaid Hat to print. As it turned out, there was still room for improvement, and it took playing the game with people with zero previous context to see this new, exciting design space.
Two days later Rob showed me an entire set of new additions that absolutely upgraded the game. At that point I was already in love with what he had created, but even so the new additions fit perfectly and seemed to reinforce the SeaFall theme even more than what we had. I was surprised Rob was willing to do that much destruction and creation when we were that close to the finish line, and yet here he was creating new systems that, in retrospect, are among the very coolest things that happen in SeaFall.
That’s a lesson that will stick with me always – even when you think you’re done, challenge that assumption, take the game to new places with open eyes and an open mind, and be willing to be humble about the thing you’ve created and still willing to improve it. That final push on SeaFall was one of the the most impressive creative things I’ve ever witnessed.
SeaFall is available for pre-order from Plaid Hat Games right now, and is set to be released later this year.
Latest posts by JR Honeycutt (see all)
- Five Things I Learned While Developing SeaFall – July 8, 2016
- Cooperative Games: Advice From the Experts – May 18, 2016
- Player Autonomy: How to Let Players Have Fun – July 15, 2015
11 Readers CommentedJoin discussion
“1) Player experience is the most important thing” This is my thinking on approaching a game design; however, before your post I believe I tended to equate “theme” with “Player Experience”. Player Experience is more than theme but theme is a way to start an approach to player experience.
I agree – often, “theme” is “what do I want players to think about, feel, or enjoy while they play?”
Great article JR. I think those lessons really resonate with me in that “I think I knew that” even if I didn’t recognize it kind of way.
JR, great post. I am so glad you are starting to get excited about incorporating player-experience into your design process– for me it is the only important aspect. I’ve posted about this before.
Mechanics matter zero. Literally zero. Dungeons and Dragons only has mechanics at all because people would have thought Gary Gygax was just telling a story if dice weren’t involved.
Game design is similar to what brand managers do at ad companies– distill complexity into components that are easier to understand. Pepsi is better than Coke because blue is softer on the eyes than red. Really, it’s that simple. A good GM in a bad game is better than a bad GM in a good game.
So many fantastic suggestions here. I especially appreciate the line “If a rule doesn’t make sense, or you can’t explain it easily, find a way to cut it.” I’m printing that out and hanging it on my wall.
Great article that (like many great articles) raises more questions than it answers:
How do you tally player experience?
-When is something finished if “good enough” isn’t it?
-what -is- the cost of a rule?
I’ll ponder these myself, but further insight is more than welcome!
the game is “good enough” when it consistently delivers the experience you intend – that’s the only way I can explain it, and I’m sure much better designers will have a better answer
the cost of a rule is in player immersion and engagement – the more time they have to spend thinking about how to play the game, the less they can spend inside the game, thinking about how to play it well
Great article. I feel like many of the things your said fall under software design. They are very very similar in approach. I hope people read this article and glean the great nuggets that are there. Keep developing great games.
Great 5 points to think about! I hope someday the games will came with a documentary film of how the game came to life , with all the creation process . I feel designing games is an art , and know what were thinking the designers when doing the game is one movie I would love to watch.
Seafall has received some negative feedback, its selling el cheepo on Amazon, I have wanted to play the game but fear taking it to my game group would only dampen their spirits, how do you answer the overwhelming criticism Seafall has received and why hasn’t a solution ever been works on?
I’ve also heard Rob on a podcast talking about Seafall’s disappointing reception (he was very candid and generous about it) and one of his takeaways was that it needed a few more rounds of playtesting, that it was sent out juuuust a bit too early, and was slightly undercooked. Would be really interested to hear your thoughts JR, especially considering here your point that “good enough” isn’t good enough. All in the interest of learning more from your experience of course – I think I speak for all designers when I say we’re on your side on this one!