First, let’s think about making a new mission for the launch of SoH. What has to happen?

At one level, it’s kind of simple: somebody writes the initial concept and story, and then we modify it. We write a mission document, then we send it to the technical art team that creates missions, while the coders add anything new or special needed for the current mission. Maybe one month later we send it to quality assurance to make sure it functions, then to quality control to make sure it is fun to play. There are several rounds of repairs and improvements, but eventually the mission is deemed playable! We can now pull in some supporters for beta testing of that mission. But what does this look like if we drill down a little bit?

We write a story/mission document for almost every mission in SoH, but it’s more like a screenplay than a short story. What does the player see? How big is the map? What’s in the map? What does the mission contact actually say? But more than that, we debate every mission before any work starts. Is this mission consistent with the lore? Does Sword Blossom’s outlook on life seem consistent with what she says in other, unrelated missions? Why is SB the one giving heroes this mission, instead of Ambassador? To prevent tunnel vision and check for consistency, we have multiple people write and edit every mission.

When we create the mission in the Unreal Engine, the process gets even more complex.

The first step, in the green box marked “Mission Map”, is where we create the first rough version of the mission instance, and confirm that this should work with the story that the story team has provided. We’re going to publish a short video in the near future about what this step entails, because it’s somewhat complex. For example, if we are doing any baked lighting, we generally put that into the static pass. This flowchart skips over some steps, like situations where different outcomes or scores are possible in the same mission. In one mission, enemies can change sides and help you – or not – and that takes extra thought to implement. This process allows us to get to a point where the mission works in the game engine editor. Sometimes it behaves differently on the server… but that will show up later, in the QA process.

We were warned not overload a game newsletter with process flowcharts, but we ignored that. We’re kind of geeky that way. However, people have asked us what the most common problems were as we made the first couple of dozens of missions for Ship of Heroes. So here’s a partial list from our talented QA team:

• The door doesn’t actually lead to the mission. I’m stuck in gray nothingness.
• The door now leads to the mission. Specifically, it leads to a hole in the floor. I’m falling through gray nothingness.
• I got past the door and the hole, but then all of the enemies on the map saw me at once and swarmed me. So I’m dead.
• I finished the mission, but I can’t get out. That’s why we give heroes a teleport power, by the way…
• The enemies in this mission are far too hard to kill…

Of course we have solved all of these issues for the missions in which they were reported. In fact, the process described above allows us to uncover and solve new issues pretty quickly. So the game is being developed steadily. But we want to get past this level of problem before we bring in the community testers. We’re getting closer…

We hope this newsletter isn’t too “inside baseball” for you guys. But we thought you’d like to know what really happens when devs build new content for an MMORPG. One of the results of using a process like this is that there are always missions being written, edited, started, polished, tested, etc. All in parallel, as the steps are mainly handled by different people. This means that once we launch, you, as a community can be completely certain that we’ll already have a pipeline of new missions and content under construction for the first major update of the game after launch.