Design Docs: IC Tooltips


I recently posted a challenge to game designers to share more of their documentation, so academia had more examples to learn from. And then I posted an Outline of Game Documentation, with some high level descriptions of different types of game design documents. Time for me to share some!

From 2012-2014 I worked on a DC Comics MOBA called Infinite Crisis. I was one of the Champion Designers: our team was responsible for designing the character abilities and overall balance. I ended up as the tooltip guru: I cared a lot about their conventions and the way we used language and keywords. I have a small collection of documents related to this work!

Note that these documents are all 6-8 years old at this point.

Tooltip Style Guide

About halfway through my time on the project I decided to write a style guide. Our old standards had grown confusing and inconsistent over time as we added more stats, keywords, status effects, and complex abilities to the game. This is an example of a “best practices” type document, and was maintained over time once it was written.

Simple Tooltips Proposal

Much later I still had concerns about our ability tooltips: they were too long and complex, even with improvements from the style guide. They were difficult for players to quickly understand when learning new characters. I wanted to greatly simplify them by default, and let players opt into full detail.

Working documents

I started by finding examples from other MOBAs and Diablo-style Action RPGs. I have an example of a “working” document, just personal notes, where I listed the information contained in those other games’ tooltips:

I also have a simple text file, another personal working document, where I tried writing examples of what simplified tooltips might look like:

The Proposal document

Finally, I have the actual proposal document! It contains details for the changes I wanted to make, and a high-level overview of the work I’d be requesting. I have a list of stories (Agile project management work tasks) to describe that work. It looks like I also tried to sneak in some OTHER tangential work because it would be cheaper to do together instead of separately.