The WildStar Creation Process and Maintaining Deadlines

So you want to create and track content for an MMO, eh?

Massive Multiplayer Online Role Playing Games (MMORPGs) are some of the most difficultgames to develop, if not the most difficult, in the Gaming Industry. They are gargantuan in scope, and they have design parameters that are unique to the industry due to the fact that they are so multiplayer-centric.

Ultimately for these games to be successful, developers need to realizethat MMORPG’s are not one game, but really multiple games that need to be equally developed. There are multiple gamer communities that revolve around one particular aspect of these games, and should be developed as such. These sections within the MMO family can be broken down into game types such as PvE, PvP, Housing, Dungeons, Raids, Tradeskills, etc. For the purpose of this article, I am going to explain how we started, maintained, tracked, and polished PvE content in the development of Wildstar.

Getting Started

We have a massive team of content designers here at Carbine. One of the challenges we first ran into was ensuring that every one of the content creating teams understood the intellectual property and the type of game the Executive Producer, Creative Director and Design Director wanted to make. To establish this vision we needed to solidify and easily communicate this to the team, and here’s how we did it:

Intellectual Property: The Narrative Design Team and the Creative Director worked to create a style guide of all our character races in Wildstar. Player races, non-playable characters, enemy factions, etc. These documents include personality traits, history, iconic characters, touchstones (from other media for personality reference), their likes, dislikes, hobbies, phrases, favorite deodorant, terminology and other aspects that helped the designers understand what makes these characters tick.

After a designer read these documents, they then had the ability to make content that worked for the specific race. We also encouraged our designers to use this personality when designing their content. On the inverse, sometimes a designer would create an iconic NPC that needed a backstory and or a larger place in the game, and our Narrative team would help create this as well.

World Story: The Lead Narrative Designer then spawned the idea for something we called the Content Road Map.

The Lead/Senior Narrative Designers, Creative Director, Design Director and I (Design Producer) worked to create an overarching map of high level story content throughout the game. Each zone (a specified thematically independent area of content) in the game has sections with different factions and events that unfold, as the player progresses. This gave the designers an understanding of what they needed to create when they were creating content for a zone. (This person dies here, that space-ship-blows-up there.) Each zone had its own documentation that explained the context, enemy factions, story points, and NPCs in the area.

Establishing Content System Types

Wildstar is packed to the brim with content. We wanted to make sure that the leveling process wasn’t just the same “kill 10 rats quests” that are abundant in other MMO’s, so we made various types of Content Systems to interact with while playing the game. Initially we prototyped these different types of content, then refined them, and ultimately systemized them. What that means, is creating templates/editors in game that can allow faster implementation of content. Although that sounds neat and organized, it really stemmed from late night passion projects, bribing programmers, arguing, and horse-trading with artists to get extra assets. Here are some examples of these content types in their most basic form:

Quests – NPC’s ask the player to kill something in the world, deliver a message to another character, interact with items, or collect items and bring them back to the Quest Giver. 

Paths – Content geared toward player styles. (Based on the Bartle types) Soldiers, Scientists, Settlers and Explorers all had content systems created to help create Paths, faster. (Want to learn more about Paths? Watch this Dev Speak video narrated by yours truly!)

Challenges – Time based content that rewards the player based on their ability to complete content within a certain amount of time. (Can you disarm 20 mines in two minutes?)

The Importance of Training

When working on a massive project like an MMO, it is imperative that new employees learn systems and processes. This may sound obvious, but I’ve worked at four video game development companies, and Carbine is the first development studio to have an informative training regimen for new hires. At the insistence of the Design Director and one of our senior designers we were able to setup a training program. JIRA navigation, proprietary software, game design practices and lore are taught to new designers to get them up-to-speed. This training time is also mapped out in the schedule when they start, so we can allow them to learn and set production expectations when they finish their training. The training also needs to be updated when systems change, so we have one person that we charge with upkeep of said program.

Layered Content and Development

All the aforementioned sections helped provide our designers with the building blocks we needed to start the development process. When our content design begins, designers use the Content Road Map information to establish specific story points in the content. They then create content based on the characters and lore already created by the narrative design team. Then they use the Content Systems to implement the content. As an example, let’s say a designer is assigned to create content based on our Marauders that are stealing from a local mining-town, and the player helps an Iconic NPC fight off the pilfering space pirates. (You can see a marauder example in this hilarious Classes Flick!) The designer reads up on Marauder lore, brainstorms/maps out some ideas in which they combat the Marauders with an Iconic NPC, then they use the Content Systems to implement said ideas through gameplay.

Quest Examples: Rescue captured townsfolk, blow up Marauder ships, kill Marauders, retrieve stolen beer kegs for Granoks back in town, kill a named boss that taunts the player via radio the entire time they are questing, etc.

Path Examples: The designers then place Path content throughout the questing areas. (Soldiers may get a prototype weapon to test on Marauders, Scientists scan and reprogram Marauder defense turrets to use on baddies, etc.)

Challenge Examples: Finally the designers add challenges that will also reflect what the player is engaging in the content. Challenges like “Blow Up 10 Occupied Marauder Outhouses in less than 1 minute.” or “Kill 15 Marauders in less than 2 minutes.”

The goal of placing all this content in this fashion was to reward players that multi-task. We call it “Layered Content.” A quest may ask the player to kill Marauders, a Path Mission might be to test a weapon on Marauders and a Challenge might be to kill 15 Marauders in 2 minutes. Effectively you are doing one action (killing Marauders), and getting credit for 3 systems. Once this designer and the rest of their team have implemented a first pass of this content, it’s now onto the review stage.

Content Review and Maintaining Design Vision

The Content Design Lead or Design Director would then review the content that was created. Our review process involves playing the content like a player. Yep. I bolded, italicized, and underlined that statement… so you know we are super-duper-for-serious about that one. We try to avoid cheating whenever possible so that we can experience the game as closely as the player would encounter the world. We also have multiple people play the game at the same time to see if the content can hold up to multiple people completing quests or content simultaneously. 

The designer and their lead watch as the Content Design Lead or Design Director and I play the game together. Can content be exploited, are we separated from our friends through phasing, can we access areas we’re not supposed to access? Basically we try to break it and play the game in a way the designer didn’t consider. We won’t catch every exploit, but it certainly helps identify problems earlier in the development process, when they are easier to fix.

It’s also helpful for the designer who created the content to see how we are breaking their content, so they won’t create content like that in the future. We were once told by a designer that we were “playing the content wrong.” That’s not really an option in our game. If you can exploit something, players will certainly use that exploit to their advantage. As all of these points are made, I take action item notes that are sent to the team for them to implement by the following week, when we start the review process over once more. We ultimately repeat this process until we reach the planning week for the next milestone where we start planning the next batch of content.

This process is similar to the Toyota Production System PDCA. (Plan, Do, Check, Act.)

Production Tracking Overview

Similarly to our layered system of development, our content production tracking has a similar methodology. From a Macro level, we have a high level overview schedule that defines what we will be creating in the coming months. Drilling down further into the process, each milestone is identified therein and deliverables are assigned out to designers each milestone. We then create deliverables in the bug tracking/task management software JIRA. Every day we then monitor these tasks individually in team standups using a digital Agile/Kanban board in JIRA, based on deliverable dates estimated in the milestone.

The Importance of Fun… and what that means to schedules

One of the core philosophies of our game is that fun is a vital deliverable. This can sometimes fly in the face of delivering something on time. We’ve had features that folks concocted after-hours that were exceptionally fun, but these features fundamentally changed the game. When we encounter these situations, we have to ask ourselves the following:

1.) Can we get more time?

2.) If we can’t get more time, what can we cut to make more time?

3.) Is the feature worth working extra hours to get in if we can’t replace it with something already on the schedule?

4.) Can we get more people to help implement this feature so we don’t have to cut any features?

5.) Is this feature actually more important than another? Do we really need it?

6.) Can we blackmail anyone to get more time? (We have artists that are reeeeeally good at Photoshop, and can make some compromising photos if needed.)

This also means that the macro level schedule (and especially at the beginning of a project) was a guide, as opposed to a set-in-stone-list of deliverables. We’re lucky to have a publisher (NCsoft) that has allowed us to find the fun in these systems first. Because we would sometimes add these systems, and that would mean that we would have to cut deliverables. I’ve worked on previous projects where publishers were not this flexible regarding deliverables and scope, and as a result, the game usually suffered. (More content at a lower quality level vs. less content at a higher quality level.) Once we found the mechanics and features we wanted to use, we’d then systemize the content and make implementation easier on the designer so we could regularly start implementing content on a reliable schedule.

Scope and Understanding Deadlines

Once these content systems were in place for the designer to use, I worked with the Content Design Lead to gather estimates regarding implementation time per content system. Quests take x amount of time to implement, Paths take y amount of time to implement, etc. We then mapped out the milestone to allow time for planning, implementation, iteration, polish and bug fixes. Because we had these deadlines in place, it forced our designers to be creative within the limitations of time and the systems they had available to create content.

The expectation was and is, at the end of the milestone, the content needs to be fun and functional. Because our review process monitors this progress on a weekly basis, the Content Design Lead can usually spot a piece of content that is becoming too ambitious or not ambitious enough, and make course corrections mid development. (As opposed to later in the development process when the designer has moved onto other content.)

Communication

Because there are so many interdependencies in games of this size, it is imperative that communication between teams stays as open as possible. Again, I know this sounds obvious, but I can’t tell you how many times standups or weekly playtest reviews have illuminated poor communication between teams. “I’m blocked on x, so I can’t get my deliverable done.”

As a producer, it’s my job to unblock this issue. Sometimes it is as simple as a five minute conversation with someone across the building. Sometimes it is talking to five different people for two hours to come to one solution. Sometimes it is bringing in doughnuts. No matter what the resolution is, communication is usually the solution… That, or baked goods.

Time for Polish, Beta Reaction, and Bug Fixes

The importance of polish and bug fixes is something that all game companies should strive to understand. We work to keep at least one week of the milestone dedicated to polishing reviewed content. We also mapped out time at the end of the project to polish as much as humanly possible. Department heads and leads play through all the previously implemented content and provide polish action items. This time is also used for maintaining bugs to keep the quality level stable. There was also a period of time where we took our closed beta offline so we could fully react to player feedback and metrics. (That sentence alone could be turned into a full article.)

Without this time, we could not have put forth a solid experience.

Conclusion

The WildStar creation process was something that we came to through massive amounts of failure, success, Sriracha sauce, learning, reacting, reading, arguing, and high fives. Effectively we created a system that allowed us to track deliverables, regularly create content, monitor quality and react to unplanned fun.