I’m Jim Weinhart, the Lead Systems Designer at Xaviant. Every two weeks, team members are posting articles to this blog giving you a glimpse into our studio, our methodologies and challenges, and even sometimes, our products. This article dives into our feature documentation methods and where we’ve found success refining them in terms of Combat Design.

Creating a product where Combat makes up a large portion of your core gameplay loop has its challenges. It sets an overall tone for the way each team member approaches their work throughout the project, yet isn’t truly defined until all that work has been created. Furthermore, providing adequate documentation for each member to truly understand how the system will impact their output provides its own challenges; your audience is both wide and incredibly varied.

- Visualization Sketch by John Bridges

Typically, documentation is generated to outline a specific feature of Combat, whether it’s AI combatants, player-facing mechanics, or behind-the-scenes managerial systems. No matter how concise your documentation is, words are always open to the reader’s interpretation; this is one of the reasons books are so engaging and fertile for debate. Unfortunately, this phenomenon can make communication within the team difficult until a point at which the feature is physically prototyped. While documentation can frequently create a strong foundation for engineering-related tasks, in that the requirements are usually quite literal, other teams aren’t always served as well as they could. It’s one thing to define a combatant’s attack – their range, their speed, and their damage values, for instance – but, that only goes so far for the Animator who has to build the physicality of those attacks, or the Level Designers who have to create engaging scenarios for that enemy.

We wanted to find a way to reinforce our documentation and better communicate our ideas and goals to each member of the team, regardless of discipline. To accomplish that, we tackle each new feature by generating two complementary products: the documentation that outlines and defines it, and rapid visualization sketches to both demonstrate the feature and convey the emotion behind it. By generating these rapid sketches, we reinforce our documentation and gain a great deal of understanding through demonstration. Now, when creating an enemy’s attack like the example above, the Engineers and Animators have the framework and definitions they need, and a visualization of that dataset applied.

These combined products are capable of supporting the large audience that makes up our team: the Engineers implementing the systems and AI characters, the Animators creating the motion that makes up combat, the Environment Artists creating the visuals to feature that combat, and finally the Level Designers creating the unique combat scenarios. In the included image, you can see an example of these visualization sketches created for one of our AI combatants.