Posted April 02, 2021 by Bernardo Pinto
With the addition of two additional members to our team, we are now a team of 4 game designers/developers (that’s us!), 2 artists and 2 game writers. The pair of writers joined the team, and had some questions for us, as it was normal. What wasn’t normal though, was our inability to properly answer them. We all had some ideas in our mind, mostly aligned, of what the game would/could be, but not much was written on paper.
Thus, we decided to create an internal document, focusing on answering a lot of the conceptualization questions, while also deciding on a baseline setting for art and story, so all members can work on something more concrete.
Regarding prototyping, we first talked together as team to discuss potential player experience problems in our game. In our opinion, it is very important to know how the player interacts and understands what is going on during the battle, so it’s crucial to prototype how much information will be shown and how.
To that end, I prototyped the game UI during battle, to answer questions that could be condensed into this one: How does a player interact with the game during a battle?
Fast and easy to create, a good choice to get an overall idea of where major elements will be.
Although a paper is relatively fast and easy to create, the same cannot be said to modifications. Because of that, I opted to do it in a more digital format. Regrettably, I chose paint. I regret using paint because creating was hard and slow. Thankfully, modifying it is not hard.
It’s worth noting, I did not follow the paper prototype a lot here. I wanted to try something things, such as combat and movement buttons, and shapes of the abilities.
This version was not tested with users. It was mainly done to understand internally if it made sense to have combat and movement buttons, and shapes of the abilities, as well as a different layout of the ability’s description.
We decided that the changes the second iteration introduced made it worse, and so I reverted them.
Having information such as shapes is useless since the user can see it on the grid when clicking the ability and will also learn it. Movement and combat buttons are not needed too: To select a move, the user can click his own character – something which all the users were able to understand very fast. And the combat button can be skipped by choosing an ability.
I found this app which is honestly great to work with. It was easy to make, allows organization, and easy modification. The key selling point for me was that it can achieve high functionality if needed. For example, the “?” icon after an ability description shows some text when hovered. Sadly, you need to upgrade your plan if you want to export it. Oh well.
Either way, more changes with user feedback:
Some users and members of the team were not a fan of information in the grid being blocked, so I tried a new prototype: The grid takes a little less space, but it's clear from obstructions now. A menu button was also added, which opens some space for new information, such as whose action plays first, instead of using a marker.
Our artists want to draw in an isometric point of view, and we don’t mind it at all. To check if the users prefer this view, I changed the prototype to have an isometric grid.
The round and timer information were also occupying too much space, so the timer was replaced with a progress bar, with the end turn button below it, making it clear what it means. The floor and round information were packed together on the upper right corner.
There are still a few things I would like to experiment, such as removing all text from abilities, and have instead a “?” symbol, that shows information about the ability when hovered. But I have to stop iterating somewhere, or this would go on forever, and I’m content with the final prototype.