Thursday 16 October 2014

Vine Venture: UI development

What is UI?
This post will cover development of the User Interface for the Vine Venture.
It is easy to underestimate the significance of this, perhaps clumsy phrase- "User Interface". If you are not familiar with the term, it might appear as a fancy catchphrase for little icons in a game, and it might not sound like it has anything to do with the core aspects of the games design, such as: goals, challenge, resistance and so on. Nevertheless, when it comes to video games, User Interface is vital for a game to be playable at all. Simply put, User Interface is the means of interaction between the program and the player.




Good User Interface provides intuitive gameplay- the player can experience a sensation of holistic understanding on a deep instinctive level before ever playing anything alike. This is hours and hours of intricate and meticulous design, making sure that player can: interpret and understand the functionality of all objects, how they communicate among themselves, how they can be manipulated, how does it feel to interact with the system, how well system responds to the player and so on and so forth. The main concern of the User Interface as a discipline is usability.

Our Game Concept
 Now that I have discussed the importance of the UI, I will move on to its implementation, after briefly explaining our game concept (Link to a more detailed game design concept is here). Nicola and I have came up with an idea for an exploration game, where the player builds a vine to reach a certain goal. The way to the goal is obstructed by various obstacles, hence the challenge is to grow the vine all the way to the goal.
The idea has been visualised in our heads... Now, how do we translate it in to a playable game? Including all the features that we have envisioned?

Well, there is no correct answer to this, but a logical thing would be to- start with the main mechanic and go from there. Let the design live. In fact, I believe it is impossible to create an initial design document that will resemble more than 40% of the final game; crafting an experience heavily relies on playtesting and user feedback; it is only natural that the design will change and evolve. That being said, a design document is a viable foundation for a project.

Core Mechanic and Initial Design
In order to avoid excessively long writing about  all of the UI implemented in our game; from now on I will focus only on our main mechanic and I will supply as many images as possible to keep it readable.

The main mechanic in our game is adding/removing branches. When we were developing the idea, we sketched out some rough comic-style images of how the core mechanic should feel like.  



After that it was easier to create a logic pattern that governs the game, aka finite-state machine. Here are some of the early FSMs, they simply explain how different states are interconnected.

With a clear visualization of different game states, I moved on to programming our first prototype.
Initial prototype was made in Flash using ActionScript 3, (it did not have physics or a goal) the sole purpose was to test- if the UI element for spawning the branches is comprehendible and more importantly playable. (Below are annotated screenshots of the prototype)


As the players play-tested our first mechanic,  it was clear that the concept is working. Our players could easily comprehend the concept of stemming branches, as they could relate to the nature. It might sound like an overstatement, however- objects in the game should use the most of their affordability, for example: a tree can grow; a fire can be hazardous; the game could quickly become counterintuitive ,if -let's say- a tree had to collect fire to grow.


Problems and Solutions
Our research was good enough to start building a stronger prototype in Unity. Even though the research showed us that the game has a potential, there was only one way to test that- I had to program the core gameplay, to get some valuable answers. This was the time when, a lot of ideas that looked great on paper, simply did not translate in to the game, a whole lot of ideas had to be scrapped, replaced and adjusted, so that the game was playable and fun. ( These design decisions will be explained in a different post)
Fast forward to our third Unity prototype, where the gameplay was more or less stable. The game has changed from building a tree to building a vine; resource that we initially intended to use had to be changed. Also there was a problem with spawning branches. The player could spam a lot of branches, which was not game breaking, but it made the gameplay sporadic and hectic, whereas we intended slow-paced, strategic experience. This had to be circumvented.
Adding a time limit to restrict availability of new branches, seemingly dealt with that problem, but the gameplay became stilted and ambiguous. We needed a better new solution.

At that point I came up with what seemed to be the most appropriate way to play our game at the time- "the 5 seed UI". It consisted of: a circle, which represents how far the next branch can reach; 5 dots (or seeds) that show the available amount of branches, as well as the angle of the next branch. With every new branch a seed would subtract from the UI element, after all 5 seeds are gone the player has to wait until seeds renew (approx. 3 seconds per seed). I have tried to convey to the player when she can and cannot build- I intentionally designed it so that the player has to aim with the seeds line to choose the angle of the next branch, as when all the seeds are gone there is nothing to aim with, hence the player cannot build. Also the circle changes colour and starts rotating- the intention was to create a sense of a clock/time, so hopefully the player can realize that she has to wait to renew the seeds.




After all this effort playtesting showed that the UI was only understood by about 60% of the people and understandably it needed further improvement. To be continued...