Design Process

I like to approach solving problems by making data-driven decisions, so it's no surprise my design process follows a similar methodology. Whether it’s game, level, or system design, the process is usually the same, just applied in different ways since the goals are a little different in each case.

For an applied example of my design process, please take a look at the Cubi Design Process.

For an insight into level design theory on Brass Tactics, please take a loot at this three part blog.

Brass Tactics Level Design Theory, Part 1
Brass Tactics Level Design Theory, Part 2
Brass Tactics Level Design Theory, Part 3

Determine Goals

Designing a feature has both player experience goals as well as developer goals. Identifying what those are upfront gives both direction for the team as well as guides the development feature.

Form a Core Team

Creating a game, let alone a feature, is something that happens in a team environment. A small, interdisciplinary team that requires the talent and skill set necessary to develop the feature should be formed, and by working together they develop the feature every step of the way.

The different disciplines are all needed to take the feature from concept to reality, so having the core team made of up members from all those disciplines at the start saves time in the long run since everyone is on the same page from day one and identifying what’s required to make it happen from day one.

Research and Brainstorm

After establishing goals and forming the team, researching what has and hasn’t been done, successes and failures, and different implementations of what’s already out there is next for the core team. Additionally, discovering the unknowns and questions to answer during the prototype phase is great to do during this time.

This helps not just avoiding reinventing the wheel and determining risks, but also sheds light on opportunities to improve what has been established as well as finding opportunities for something entirely new and promising that accomplish the goals.

Prototype

After researching and determining promising methods of achieving the goals, prototyping these methods and answering questions comes next. Rapidly developing, implementing, and playtesting features in game to identify their potential is what’s key, and doing multiple prototypes testing different ways to accomplish the goal is ideal to see which approach seems the most promising for the game as a whole.

If a prototype doesn’t seem promising at this point, the Research and Prototype phases keep going until something does, or the goals may need re-evaluated.

Playtesting is paramount starting at this part of the process and remains so during the rest of the process for collecting both quantitative and qualitative data, which allows for informed decision making and iteration.

First Playable

For the prototypes that show promise, the next step is getting implementing them in a player experience that’s more representative of the actual game. This allows for viewing the feature outside of a controlled test map and seeing how it plays with other features in the game. A controlled experiment is useful for showing the prototype’s promise, but seeing it in the wild is ultimately the real judge as it shows the gestalt of the features thus far.

Playtesting and iterating is key to getting the desired First Playable experience. Getting data points for iteration helps get the First Playable to a great state.

If the First playable after several playtest and iterating cycles isn’t getting desired results, it may be worth going back to Researching and Prototyping for rethinking the feature.

For Reals

When the First Playable demonstrates the feature plays well with the other features in the game, the feature can now be implemented “For Reals”, as it is now a part of the game.

This means that the systems used in the prototype are cleaned up and the architecture for them are set up in a way that works for the game as a whole. It also means that developing content for the game should begin incorporating the feature, and the feature should be communicated to the player.

As always, frequent playtesting of the game as a whole will show where the feature is doing well and where it still has room for improvement, as well as the overall game experience. More data from the different use cases gives more opportunity for smart iteration and bug fixing.

Polish and Optimization

As the game and feature get more defined and solid, polish and optimization become more of a focus than in previous phases of the process. This is where the bells and whistles for presentation come in, as the feature is now developed enough to know how to best polish it.

From the optimization side, the feature is far enough along to know how it interacts with the other parts of the game, so looking at how those interactions can take place in the most efficient, performance friendly way will help the overall player experience.

Playtesting gives data points to see if the polish and optimization passes are giving the desired results and will help identify what other areas could use polish , optimization, bug fixing passes.

“Done”

Once the feature has gone through the entire process and is ready for player consumption in the wild, the feature or content is “done”. Done is taken with a grain of salt because bug fixing and iterations still occur based on players playing the game for in the wild!