|
Some of you may have read my recent Gamasutra article, Game Tools Tune-Up: Optimize Your Pipeline Through Usability but I wanted to discuss something that writing that article has really brought to the forefront of my mind.
As an industry, we aren't very reflective on the methodologies we use regarding the development of tools. This blog as well as other sources may be bringing about a change in that regard, but it is progressing very slowly. There are techniques in use in other industries that have significantly increased the usability of software, and many have been around for many years.
While at GDC this year, the idea of usability came up at the Tools Round Table. Now, I'm pretty sure John had included the topic at the round table, in part because he had gotten a very early preview (and several revisions) of my article before it went up on Gamasutra.
I appreciated the effort on his part, but I was a little surprised at the total lack of response from the group. When asked who was using what techniques for usability, the room was completely silent. I expected that if anyone in the industry was doing anything at all with usability, surely this was the group.
Although it was a bit disheartening, it illuminated a real issue in game development that most of us have known in our hearts for quite a while. Very few people are serious about making game development tools accessible to their users. Artists, designers and even programmers spend a great deal of time dealing with tool issues for the length of every new project.
The tools developers wonder why they have so much trouble, without ever realizing that there are techniques in existence that could answer that very question and could help them make better tools that got fewer complaints and more work done.
I recommend every tool developer out there take a look at these resources:
The Usability Professionals' Association website
Jeff Sauro's Measuring Usability website
Also, read Alan Cooper's excellent books on usability:
About Face
and
The Inmates Are Running the Asylum
|
The added bonus of having usable tools is that this directly affects the team's ability to make the game, itself, more usable because they can iterate faster in response to game usability feedback.
One of the most frustrating things for both myself and my clients is when we realize far too late that the changes we want to make are far too expensive (time-intensive) or risky (due to fragile tools) even though our user research suggests that the changes would greatly improve the user experience.
Usable tools can mean the difference between the 2nd and 3rd round of polish and balance on content -- and allow developers and publishers to test further into the game and make refinements closer to hard deadlines with confidence.
Stay on that soapbox!
J
If I have some money for I might try one of those Alan Cooper books, any recommendations on which one? My target is explicitly game design, not webdesign.
What are your thoughts about using the game itself as an editor? As in, you go in the game, enable a "editors menu" that allows you to drop and drag new items into the world you are walking in at the same time. This is a way you see rarely (I think) and I think it would save time for the developers, as it is easier to create a small Editor layer on top of the game than to make a completely seperate editor. And I think it's usability would be a lot higher, since you are in a familiar environment and see directly how it would influence the game.
If the game is running on a console then you might lose the ability to access external services or apps that the editor could take advantage of (eg, source control).
What I prefer is some kind of realtime link between the editor and the game. So any change you make in the editor is immediately reflected in the running instance of the game. This has the same advantage of shorter iteration time. Also, in my experience, the game tends to be less stable than the dedicated editor, so you won't lose your changes quite so often.
to solve many of usability problems of your tools (but not all), You should first think about the different kind of context your tools will be use, and about the different sort of users. Next there is some good (free) usability checklist that can really help you.