Most of this week I've spent working on the side-quest storyline I mentioned previously. To avoid spoilers, I won't go into much detail here.

Instead I'm going to post some of my rough notes on mission design. I had the idea of making a video on this, but recording and editing videos take a lot of time, so I decided to post the notes lightly edited together. Note that these have some very mild spoilers for current game.


Here are the major elements that I think make a good mission, both from a player perspective and from a practical development perspective (an otherwise good mission idea might not be worth pursuing if it will take three times as long to develop and test, or has a high likelihood of introducing game breaking bugs).


The core of the game is exploration, discovery and unexpected events. Players are very astute at recognizing patterns and so every mission needs to be unique and structured in a way that doesn't feel like the game is creating a conspicuous loop of ticking off the same three check boxes.

This means not only changing up the goals, but also how missions are revealed/discovered, how the player is guided to objectives, what actions are needed to resolve them, etc.

An unfortunate side effect of this is that every mission can potentially introduce a new problem: either narrative inconsistency or flow bug, but also ways that players might find themselves "stuck".


While having interconnected missions can lead to "brittleness" both due to changes in one mission potentially affecting another, as well as possible sequencing problems (see Robust below), having missions connect to other missions in subtle ways helps the universe feel more alive.


In terms of efficiency, I mean that generally I want a mission to be accomplishing multiple design objectives while the player is completing it. Examples of design goals are:

• Introduce a game feature
  
• Teach the player a game mechanic
  
• Remind the player of a previously introduced mechanic
  
• Put the player in a position to notice a region or object
  
• Foreshadow some future content
  
• Present a choice
  
• Progress a narrative
  
• Develop a character
  
• Promise a reward
  
• Create a connection with a previous piece of content
  
• Fix an issue with existing content

In an open-world game, the player can theoretically reach any location at any point at any time. This presents a challenge from a mission design standpoint. If the "happy path" for a mission is player visits region A, gets a clue that leads to region B, which activates an artifact in region C, we must consider what happens if the player goes B->C->A or A-C->B or C->B->A, etc. The mission logic must account for these scenarios in a way that cannot break the game, and ideally doesn't break immersion in a conspicuous way.

This is harder to achieve than you might think.

Ideally, you'd like it if all textual elements, such as dialogues, crew banter, logs, etc. are consistent with the way events actually unfold. Sometimes this simply isn't feasible. There are several major story elements that the player is expected to have encountered early on, such as the Devout. It would be impractical to have every piece of content that references the Devout changes its wording depending on whether player knows who they are at that point.

Even in very polished AAA RPG games you will occasionally notice points where the designers have allowed some inconsistency to slip through because of the graph complexity of handling all potential "narrative states", such as a PC bark noticing for the first time something you've just spent the last hour exploring.

But the most important thing though is you don't want the ordering of the player's actions to put the game in an unanticipated and possibly broken state.

In many games, this can be solved with physical blockers that prevent the player from accessing certain areas until the mission is in a known, well-defined state: locked doors, rock slides, or "city guard" cut scenes. Since Starcom: Unknown Space takes place in space, these options aren't available. Still, many interactions take place in the context of an anomaly or dialogue, some constraints can be put there.

But this doesn't work in all cases. For regions with more involved interactions, I use a different trick: Space is really big. So sometimes the player will learn of a new region which coincidentally turns out to be in one of those parts of really big space they haven't explored yet. This allows me to enforce some assumptions before certain areas are visited.


When designing a mission, it is very natural to imagine it unfolding like a story. While a good mission should feel story-like, I think it is a mistake to approach mission design from the perspective of starting with a story and trying to turn it into a mission. Most stories wouldn't make good missions: they have a well defined narrative structure that demands things unfold in a certain order and put too many constraints on the player's actions.

It is much easier, in my opinion, to begin a list of things I want the mission to accomplish from the above, construct a fairly robust path that goes through those things, then write a story around that path.

For example, one post-launch mini mission had the following goals:

• Added some narrative foreshadowing for the Devout's increased interest in the player
  
• Encouraged the player to search their ship logs to find a previously visited location
  
• Give the player some way of finding ships of different factions more easily

These elements suggested the rough outline of a story to me: the player finds a derelict that hints at some Devout nefariousness. Later, someone suggests returning to that location (prompting a search of the logs). Once there, a new location is revealed where the player finds more information on the Devout and a tech that improves ship detection.

That's all my notes for now, maybe at some point I'll flesh them out further and make a video.

Thanks for reading, until next week!

- Kevin

Quick update this week:

I've continued work on a new side-quest storyline. Without too many spoilers, the storyline has a number of design goals, including guiding players a bit more in parts of the existing story where players are getting stuck, as well as providing additional resolution to one of the game's narratives.

It's still a work in progress and there's a fair amount of work left, so I'm being deliberately vague to avoid overpromising.

I'm creating the story using the new Experimental "Starcom Creator" tool. As mentioned previously, if you're interested in playing with it and giving feedback, shoot me an email at kevin@wx3.com and include "Starcom Creator" in the subject (see the Creator sub-forum for details and updates on that).

Until next week!
- Kevin