During the development of our capstone project Shattered, some design features called for modular, functional level elements. To create these elements, such as ‘hazards’, objects enemies can damage themselves on, I wrote several scripts which provided the appropriate functionality, notified the team, and carried on.
A Call to Action
My attention returned to these tools when an iteration on the level design including these elements was not completed during its sprint despite our level designer’s tireless work. As a result, I realized the scripts, though providing the desired gameplay functionality, did not provide the desired user experience to the development team, and were therefore counterintuitive and discouraging use. To create tools with greater usability for my team, I identified three key concepts for creating more useful editor tools:
1. Design for the user
2. Provide useful documentation
3. Iterate and communicate
Design for the User
When designing the tools, I planned them from a development and functionality perspective. As a designer, it is ironic that I failed to identify the target user of the tool, and design its use for them. Technically, the tool can work however it needs to, but the way that it is interfaced with can be adjusted to fit the user most effectively. To fulfill these symbiotic technical and experiential elements, the tool should be designed from both user-facing and technical perspectives. Why and what the tool does should have equal consideration with how the tool is used, and by who.
For example, the original script required, beyond its own exposed fields, specific layering, tagging, and hierarchy ordering. There were far too many loose elements to easily work with, regardless of documentation. It was designed for its designer, not a team environment.
Redesigning this tool with front-facing accessibility in mind, I discussed with the target user and identified their needs from the tool. As a result, I found that being able to easily change the volume used for damaging enemies, such as going from a primitive cylindrical pillar to a long box wall or large rock with a mesh was critical, so I emphasized that functionality. Furthermore, I ensured the loose elements described above such as layering, tagging, and the creation of child objects were consistent across the tool’s use and automated them.
Lastly, I segmented the tool’s functionality so that parts could be used in isolation. When I was examining the tool, I realized a massive accessibility and usability gatekeeper was that the script required the implementation of other complex scripts I had not designed for others’ use, such as the shattering visual effect which included many objects and scripts. As such, I uncoupled that functionality so that the tool could be used for its pure purpose, creating hazards, and the shattering could be added afterwards if desired.
Provide Useful Documentation
Initially, the tool had prefabricates which showcased how the script and related objects worked together to create the intended effect. However, these objects did not describe how to build the finished piece, and the individual components were too complex and scattered throughout the project files to experiment with (if one even had the time for that).
When redesigning the tool, I firstly ensured it was self-documenting. When creating a hazard, the user would only require one script which would set itself up without further requirements by making use of self-initializing properties and the required component attribute. Furthermore, exposed fields were simplified into enums so that the user could simply select options from a drop-down menu.
In addition to this, I provided several simple prefabricates which showed the end product again, which were simpler this time.
Going forward, I plan on providing a one-page brief on the tools’ use. This could be hyperlinked from the script’s inspector page to wherever the documentation is stored, such as a Confluence page.
Iterate and Communicate
Reach out and request features, functionality, and explanations. Identifying and discussing with the target user how they want to use the tool and for what purpose made it significantly easier to design a useful user-facing interface. Otherwise, one designs for their own capabilities and desires.
After creating the tool’s first iteration, I didn’t open a conversation on how the tool could be improved to facilitate its teamwide use. Doing so would have made many of the challenges which built up with it apparent beforehand. As with any design, tools also require iteration to reach their potential.
Conclusion
After redesigning the tool to fit the user, providing useful documentation, and communicating, the level promptly began including new, experimental types of hazards. These provided a breadth of interaction to the game, Shattered, which was previously unseen. They were concepts our level designer had wanted to test, but which the tool had prevented them from doing.
As game developers, we often strive to realize the dreams of our players, but we should never forget that our coworkers also have dreams and desires and that by effectively designing for them, providing documentation, and through iteration, we can unlock their fullest potential, and create great games.
Comments