The Importance of Goals - Captaining a Ship

Developing any game, even a fast follow at a big studio, involves a lot of speculation. Short of a few truly auteur-driven titles from time to time, I believe it is impossible to just write up a design and implement it whole with the expectation that the result is going to be fun and engaging. You have to make calls in the moment with a steady hand. You need a complete belief of where you want to end up, knowing that the route there cannot ever be trusted or predicted. Often you need to guide a crew to a destination based on that crew's faith in your ability to guide. I highly recommend watching Black Sails to gain some perspective.

While each character is exceedingly different, they all have strong goals. Whenever one of these folks wavers, it is when their goal gets murky. Cap'n Flint (front left) is amazingly driven by his goal. He's played by Toby Stephens, whose performance is astounding. Fun fact, Toby's mom is Professor McGonagall. Pretty cool.

Milestones

Even at its most organized, game design is dirty work. Quite often some of the most important design decisions are made under fire. Infinite time does not a great game make. We all lament when a game is released half-baked. "It just needed more time". Happens all the time. I would argue though, that not having strict enough milestones early on is what gets a half-baked game into its perpetual development state to begin with. Games do need to breathe. They do take time. They also need to make tough calls perpetually or they will never reach completion.

Funny thing is, as designers we often think that milestones are the bailiwick of producers. Some quartermaster needs to crack the whip and lash the crew when things don't go well. Some overlord has to have the business sense to keep us from going on twiddling hit points and armor until the end of time. I felt this way for years.

There is no amount of organization, production, or most importantly time, that will get a game to a complete state. You can move as fast and efficiently as possible, but if you don't have solid goals (a destination), you will just be vectoring blind. Lost at sea.

Somehow, with hand-drawn maps and no ability to control the weather, pirate captains were able to get to where they needed to go, relying on a bunch of wingnut criminals to do most of the work. Sure, lots of ships sank. You have to make the right call most of the time. You need expertise. There is competition out there and you might not be up to the task. But systemically, it worked. Folks feared pirates with good reason.

The best producers I have worked with did not directly set design milestones per se. They were deeply skilled navigators and knew the ship and crew intimately. I would say where we wanted to go and these amazing navigators would sort out what route to take and why. No surprise that when you put time constraints in there sometimes you find out your goal is not possible. Here's where the fun part should begin. As a designer, incorporating all you have learned about the game you are making right now, have you really thought about how your goals should be accomplished?

Milestones, to me, are more about having reality check moments on the evolving design of the game. If you are not where you should be, there should be very clear reasons. Be ambitious, but let go of things the moment they don't fit anymore. Look for things that no longer support the over goal of the game and actively drive them out of the priority list. Cut things. Change things. Do this with enough clarity and honesty on the whys and hows. Pirate crews do not stay together based on empty promises. You need to show gold. Every milestone is an opportunity to do just that.

Cutting

You should never just cut something to cut it, but you should be learning more and more about what actually matters to your game as you move forward through development. You should definitely have things you actively want to do differently now, as opposed to when you wrote them up a few months ago. You buy the time to do more and better things by continuously updating the game's design to be more on target and by solving problems faster. The closer you get to the target, the more accurate your planning should get. If the opposite is true, you are either sailing blind or lying to yourself... or perhaps your goals are too rigid.

There's millions of ways to solve any problem. I'm pretty good at putting forward good solutions. I'm overjoyed when I get to kill my solution and go with someone else's call... one that is faster and better for the game. Happens all the time, but only if you let it. By cutting or altering your own first pass solution, you are making it clear that there is room for creativity and learning as you all move forward as a crew. This applies to large teams but even solo work. If you marry an idea on paper, even just by yourself, you are going to struggle to find the right solutions when the work gets underway.

As an example in CRUFT, I had this idea of a big old skill tree as the governing structure of long-term progression and goal formation. I've since scrapped it. It wasn't that it was untenable. Filling out skill trees can be pretty rote and efficient stuff when you've done it a few times.

Who wouldn't want to start in the middle of this thing and meander about getting tiny bonuses and unlocking cool stuff? It's pretty cool and I love me some trees. But, after a lot of play, was it the right solution? Nope, and it was clear before even writing any code for the feature.

The fact is, after playing the core of the game a bunch, it became pretty obvious to me that taking the player out of the primary play space to go hunt and peck at what to do next was just not really that awesome. The experience of being in the yard and doing things by hand became more of the game than I initially thought it would. So I cut the tree.

Does it matter that this tree in Miro had many incarnations on paper that were awesome to me? Not really. The tree was there to reach a goal, specifically, "Replayability is paramount." Turns out, the core play space of the game can handle this and keeps the player in a more focused space.

Now if my goal was more like, "The player should be able to progress through play along many vectors of a skill tree that each reward distinct choices", I would have had less room to maneuver once the cannons started firing. A skill tree is a means not a goal. At the start of this project the tree seemed like a pretty good solution. I still believe it is a pretty good solution. The moment I found something better and more efficient, the skill tree didn't matter at all. Happy to be rid of it.

I love skill trees. I can make one in a different game some time.

In Black Sails, almost nothing ends up going smoothly. The best captains make a call with an eye on the prize. Oops! The treasure is not where it is supposed to be? Here's what we do next.

Being Right Most of the Time

Growing up, a friend's dad had the following saying: "I may not be right, but I'm never in doubt."

I hate that saying, but I return to it often. It is boastful and pretty dangerous but there is a reason it pops into my head on a regular basis. Blindly pressing forward through foreseeable failure is a recipe for mutiny, BUT... your ability to make the right decisions is often governed by how well you have laid out your goals.

In order to lead a pirate crew, you have to be right most of the time. This isn't magic. If you know where you are going, you should be able to arbitrate a bunch of blocking issues along the way. I don't believe it is about confidence or bravado, or at worst just being loud. That only buys you a little credit and the longer you work with the same people the more they see through that veneer.

When you are wrong you have to actively adjust course and do so in a way that the people you are working with can agree is a better course. You have to learn and there is more to learning than saying "Today I Learned." You have to grow with your crew. If you are doing all this learning and the project is still stumbling then it does not really matter how smart you are getting.

The amount of wrongs needs to decrease the further you get through development phases. It just has to. If you are growing with your team this should happen pretty organically. Eventually, you should almost never be wrong because you yourself are not positing every course of action. Eventually, you should be spending time getting out of the way and removing roadblocks more than steering the wheel and pointing to the horizon. You should be focusing more on what you will do when you reach your destination than the day-to-day sailing of the ship. If the crew is operating as a real team, members should be tuned into the game to the point where they are the ones correcting course, and even better, improving the design of the game.

It's almost impossible to be right most of the time if you insist on making every design call yourself. Everybody rolls ones. Share the wealth. Let other folks roll some ones. Work with them on sorting out the wrong call with as much vigor as you celebrate the great decisions they make. Ya can't just say "we're a crew". You have to enforce the bond continuously.

If your goals are sound, everyone on the crew will over time be able to make increasingly important decisions. With solid goals, the ship runs itself. It's your job to create and curate this environment. If you cannot go below deck and catch some shut eye (or just spend some time blogging), then you have not done your job.

Sometimes the Treasure Isn't There.

Sometimes the Spanish are There Guarding it.

We don't control the market. When you finally find land, follow the map to the 'X', and dig under that weird looking palm tree... there might not be all the riches you ever dreamed of there. I'm not hand waving the importance of finding a good market fit and having that be an essential part of the overall journey. Some stuff is just out of your control though, especially if you innovate. You need as much intel as possible, through testing, along the way to adjust as needed.

But...

If you don't reach the intended shore you will never know if you have to fight through a bunch of Spaniards to get to the gold. If you never stand under that weird looking palm tree with shovel in hand and make a speech to the crew as you open the chest, you'll never know if it was empty all along.

Shipping a game is terrifying. It is genuinely terrifying. I dread this now as I have dreaded every single moment around shipping a game in the last 20 years or so. That fear is poisonous to development. That fear is what pushes us to meander around in the open ocean attempting to meticulously lead each crewmember through every small decision. You cannot tie every knot, batten every hatch, do whatever small thing distracts you from the end goal.

You do need to man the wheel when you are the best person for the task on deck, but solving for every immediate problem is just a defense mechanism. The immediate problems are comfortable ones. They divert our eye away from the reveal, the moment of truth, though. You have to ship. You have a crew to solve all sorts of problems and if you respect their expertise you can just let them work through things. Be available, but let the crew earn its share.

Every day you have to eat up the fear, and get closer to Treasure Island. There's a lot of pirate ships out there and some of the best ones have dug up empty chests. You have to go find out and if things don't go the way you hoped at least you are in good company. Lost at sea is a far worse fate. Get your game in front of players. Dig at that 'X'. Revise your design if need be (hint: it need be).

Appendix - Goals

The numbers are design goals. The sub-letters are supporting means. Means are not goals.

1. A few simple interactions govern the vast majority of play:

   1. acquire raw materials

   2. exploit materials at a location and let recipe cook

   3. collect outputs

   4. invest in better capability

2. Replayability is paramount. CRUFT is about leading many lives.

   1. The options for progression are myriad and in one playthrough you may only work with a subset.

   2. Prestiging is an important way to make permanent progress.

   3. Many avenues of production lead to diverse goal setting and accomplishment.

3. While the player is free to optimize their operations, at it's core CRUFT is a cozy, incremental, crafter.

   1. We offer the carrot assertively, and the stick passively.

   2. The player opts in to more challenge.

   3. CRUFT creation and diminishing returns are surmountable, though progression may need a prestige from time to time if you want to make meaningful advances.