Hi my name is Jonathan and I want to help people feel smarter in their day to day lives by building technology that is more accessible. The following article shares lessons that I learned over the course of my final year game development project in 2019, from when I was studying BIS Multimedia at the University of Pretoria in South Africa. I am currently a User Experience Designer at Sand Dollar Design, as well as host of the Guidelines podcast, which is an ongoing series of discussions about User Centred Design within Africa and beyond.
Over a 10 month period I had the opportunity to build a video-game as my final-year project. BIS Multimedia broadly focusses on Computer Science, Information Science and Visual Design, so myself and three team mates were tasked with developing a game that showed off our skills in each of these areas. After many late-nights and Saturday work parties, we developed a game that landed us the runner-up prize for best game. In this post I am going to share what I learned along the way, as well as, the user centred process that we followed over the course of this project.
Paths: The Brave Kodama is the story of a forest dwelling spirit who prevents the eruption of the active volcano looming above its forest home. Along the spirit’s journey it is helped by the creatures of the forest, as well as, by a mysterious machine which falls from the sky. In order to prevail, the two seemingly opposite worlds of nature and technology unite to prevent the destruction of the forest below the volcano. Players will navigate through four unique levels, each complete with its own biome, cutscene, and an original soundtrack. Along the way players will need to collect items, and switch between abilities in order to find a way through the various paths that each level presents.
Lesson 1: Understand the broader context
One of my biggest learning moments of this year happened whilst consulting with Sand Dollar Design alongside our CEO, Jaco, and other team mates. I was busy designing the wireframes for one of the key screens, and was battling to figure out the best way to display the content that it needed to contain.
About two hours into this I was getting frustrated and Jaco looked over at what I had done and told me that I was, “getting too caught up in the details,” and “should rather move onto the next screen and revisit this one once I understood the broader context of the project.”
Looking back at our game, it would have benefited greatly from us taking a step back early on in it’s lifecycle and applying this same wisdom. Understanding the broader context would have been building simple levels, without any art, for the entire game. Once those levels had been created, we could have put together simple cut-scenes as well as mechanics and played through the skeleton of the game. This would have given us a perspective on what was working and what was not. Although our process of fully building one level after another resulted in a good game, getting everything laid out early on would have resulted in a more robust and consistent foundation, giving us room to innovate later on in the project.
What we decided on in April was mostly what we ended up handing-over in October. This proves that it’s better to get the big-picture thinking done early on before you are locked into a trajectory.
🥡 UX take-out
During your next project, do as much analysis as possible before committing to any specific UI or UX design. Build wireframes for the entire project first and then once everything is laid out, start to make adjustments. Modern design tools such as Figma make it easy to build wireframes collaboratively, and then share these wireframes as clickable prototypes with the product’s various stakeholders. An added bonus is that as when you are assembling your wireframes you can identify key components to reuse across your project, and then once your wireframes have been signed off you can simply style these components to finish off your project.
Lesson 2: Share and Iterate
From early on into building Paths we followed a process of sharing specific features, then iterating on those features based on feedback that we received.
This is how we chose our game mechanics, established our art style and even composed our soundtrack — sharing specific features and then iterating based on feedback that we received. The useful thing about getting feedback early on in the process is that it prevents you from growing too attached to your ideas, and possibly wasting time by going down a rabbit hole.
Resist the urge to wait until your work is ready to show people and rather be open about what you are still figuring out. Let people into the unknown at the beginning of a project and listen to guidance from smart colleagues, mentors and users.
There was a critical point in September when two of our lecturers pointed out that our game was too simple and that it required more complexity within the gameplay. We sat down with them in their office and threw around ideas on how we could make improvements. With their help we realised that the trajectory we were heading on was going to result in us making an interactive movie, and not a game. Their advice was incredibly valuable and resulted in us getting the project back on course. Being open to their feedback and making the necessary changes made this possible.
In addition to consulting our lectures, we bounced ideas off of each other as we were working, moving through the process of sharing and iterating for the cutscenes, voice overs, coding, level design and story building.
Sharing also took place in the form of showing the game to friends and family whenever time permitted. With all of this you are trying to get over your initial assumptions. Through a lengthy process of sharing and iterating go from something being an idea to a finished product.
During your next project, focus on creating concrete and specific demos of features within your product and then sharing them with colleagues, mentors and users. This might be a sign-up process, menu, colour combination or animation. Implement them as realistically as possible, and share quickly. Apple Keynote‘s Magic Move transition makes it easy to test out product animations; in fact, all of our in-game menu animations were first built in Keynote and then used video reference files during development.
Lesson 3: Facilitate Meaningful Interactions
In Rules of Play: Game Design Fundamentals, Salen and Zimmerman define meaningful play as the end-goal of game design. They define meaningful play in the following way: “Meaningful play occurs within a game when player action is both discernible and integrated.”
What it means for player action to be discernible is that there needs to be a clear relationship between player action and outcome within the game.
What it means for a player action to be integrated is that any action a player takes not only has immediate significance in the game, but also affects the play experience at a later point in the game.
In the context of our game, some of the ways that we made player actions feel integrated was by guiding the player to complete objectives and choose different paths in order to move the story forward. One of the ways that we made player actions discernible was through interactive prompts that showed players how to perform an ability, these interactive prompts then dropped out of view once the player had successfully used the new ability.
This concept of meaningful play is similar to that of affordances, a term which American psychologist James J. Gibson coined in his book The Ecological Approach to Visual Perception. Affordances are the properties of an object which indicate the possible actions that a user can take with it. The term is used within UX design, especially within the context of perceived affordances. Perceived affordances, a term introduced by Don Norman in his book Psychology of Everyday Things, are the actions that a user perceives to be possible, which are distinct from what is actually possible.
As designers we need to consider our users’ perceived affordances, as well as, educate them about the consequences of their actions within the systems that we create for them. At any point in a user’s journey they should be able to understand how and why they reached the place that they are in and be able to look at all of the information in front of them and make sense of it in the broader context of the product.
During your next project, pay special attention to the design of robust user journey maps. Whenever adding a new screen or feature ask yourself where it fits into the overall product in terms of the user’s perspective. Make it as simple as possible for users to understand how they arrived at their current context. Navigational beacons such as breadcrumbs are a simple example of this at work.
What makes a great game also makes a great digital product, and there are many similarities between the worlds of UX design and Game design.
Paths: The Brave Kodama was built as a part of IMY 300 for the BIS Multimedia degree at the University of Pretoria, 🇿🇦 South Africa.