David Lightbown (who has a day job as a User Experience Director over at Ubisoft) has a personal fondness and fascination for the history of tools in game development. If you saw his 2017 chat with us on Gamasutra, or have read his blog, you’ll know that he thinks there’s a lot for game developers to learn by studying older versions of Unreal Engine, Epic Games’ ZZT Editor, and more.
At GDC Showcase, Lightbown shared some additional lessons he’s picked up in his tools research, which hasn’t just involved breaking out those old tools and examining them, but speaking with the developers who created them, including John Romero, Tim Sweeney and more.
Lightbown’s talk began with a look back at several notable postmortems held at GDC—for games like Myst, Diablo, Goldeneye, etc. When watching these postmortems, Lightbown said a thought came to him. “As far as I know, there haven’t been any tools postmortems—there are very few that focus on the tools.”
“I think as much as we can learn from the history of game development, we can also really learn from the history of tool development, and postmortems.”
He joked that the people who forget the history of tools development would inevitably be doomed to repeat them.
Lightbown then set out to interview a number of game industry tool developers about their work. These included John Romero (The TEd, Tile Editor), Tim Sweeney (Unreal Editor 1), Chris Norden (Deus Ex tools), a number of the developers behind the Gamebryo engine, and Marc Leblanc, creator of ShockEd and DromEd.
After interviewing that array of classic tool developers, Lightbown came up with 3 key questions tool designers can ask themselves when starting work on a new tool.
What is the problem that the users want to solve?
Lightbown urged developers when making tools to remember that it’s not always the tool user’s responsibility to tell you how they want the tool to work. “People who use a tool may not be able to tell you how they want a tool to work, but it is their responsibility to tell you what problem they want to solve.”
Lightbown used the example was a request from a hypothetical user to build a “yes/no” function in the tool, and have the “no” button highlighted red. “Why would you want the no button to be red?” a programmer might ask. If they respond that they keep clicking on the “no” button by mistake, you can ask “why is it bad to click no?”
The back-and-forth can illuminate that the user is concerned about clicking “no” causes the tool to not save their work, revealing a greater concern about backups than the color of a “yes” or “no.” Now the tool programmer can work toward solving the issue of losing work, instead of button colors.
What can you learn from other tools that solve the same problem?
Lightbown shared an anecdote from watching concept artists work, and realizing at just how much they relied on reference art. He was especially impressed by artists who relied on an incredible amount of references to mold and shape their ideas into something useful for the game they were working on.
“One of the things that makes a good concept artist is that they look at other [art] so much,” he said. “In game tools development, we don’t do enough of that.”
“Looking at other tools that solve the same problem can make your tools better.”
Tool programmers paying attention to other tools might notice that certain features show up repeatedly, or are exceptionally popular, what Lightbown calls “natural selection” in game tools. If tools programmers keep implementing similar features, it probably is good at solving the problem that users have.
“It doesn’t mean copying [features] outright, but it does mean being aware of them and being inspired by them,” he said.
He pointed to the contextual menus from the Xerox Alto 1973 as an example, which still appear any time you right-click while working in Windows 10 or software like Microsoft Word. “If [your tool] resembles another tool used in the past, it’ll be immediately familiar to them.
By contrast, Leblanc apparently regrets requiring WXSD as the keys to move around the environment in ShockEd and DromEd. “He feels like he wishes what other people were doing at that time to follow conventions, as opposed to coming up with something different.”
How do people use your tools, and how do they fit in with other tools?
“How well do you know the tools environment at your studio?” Lightbown asked. “If you walked around your studio, could you name the other tools your developers are use at the same time?”
Lightbown said that in the majority of cases, developers won’t spend all day long in your tool, they’ll be interacting with other tools as well. (Think Photoshop, Maya, even Outlook.)
This led to one interesting example from the development of ConEd at Ion Storm (the conversation editor of Deus Ex). Norden explained to Lightbown that Deus Ex lead writer Sheldon Pacotti has a repetitive strain injury, and couldn’t type, so he “wrote” much of Deus Ex using Dragon Dictate voice transcription.
That led to Norden having to adjust the tool to be able to intake Dragon Dictate’s outputs, as opposed to what Pacotti might write in a spreadsheet or .txt file.
“As an engineer, you think a certain way, and you think ’oh I can use the tool this way, and that’s the most efficient way, so that’s the way I’m going to write it.’ You’re almost always wrong.”
This was ultimately Lightbown’s plea to the audience to go out in the studio, sit with developers while they were working, and observe their process firsthand. Examples like Norden’s help tool developers re-evaluate what it means to be “efficient,” and to get closer and closer to exactly what kinds of problems developers need game tools to solve.
Gamasutra and GDC are sibling organizations under Informa Tech