User Interface iteration for our browser game
As our game idea and story start to take form, our User Interface (UI) is also slowly starting to take shape. Besides the storyline, the biggest topic we wrestled with the last week was to find a form that fits with all of the constraints we have — both technical and content based.
A brief iteration overview – from pages to components
One of our first interface ideas was to seperate the different game functions into seperate pages. This was at an earlier stage when were still pursuing the “human society” concept and were leaning much more towards a typical website structure that can be seen in several other recent cryptogames. However, as the game concept developed further it became clear that not only did we need to differentiate ourselves from other games, but that the entire concept of the game could not be displayed in such a structure. It became important to find a way for the interface to represent the story and game system, just as the opposite was true.
So what were our constraints? We’re trying not to spoil too much here, but in general the interface needs to…
- Have 6 main components — these correspond roughly to the pages we mention above.
- Have a minimum of 2 of these components visible at all times — a navigation bar and progress indicator being the main ones that come to mind.
- Provide easy access to starting a new minigame without overtaking the interface too much.
- Needs to perform flawlessly in modern web browsers on both desktop and mobile devices.
- Provide simple and intuitive mechanisms to make Dash transactions that are an integral part of gameplay in for e.g. the marketplace. This means hooking into established standards such as QR codes and mobile app URL schemes.
Thus, we decided on using just one game screen to both show players their progress as well as allow them to interact with their game within a single view. We had a workshop to work on interface ideas using pen and paper to determine requirements and find solutions for the different components. Thinking in a more modular way made it easier to identify problems and challenges and to find solutions to them.
A modular interface system has the advantage of being more easily expandable meaning new interface elements can be added reasonably quickly without too much friction. The goal is always to reduce a UI to it’s absolute essentials so that it is as usable and intuitive as possible without getting in the way of the player. For this reason, only really crucial elements like navigation and score are always displayed, while the visibility of other components can be toggled on and off as needed. Maintaining the component’s independence from each other has many advantages, from more easy work distribution to the design and development teams, to a more straightforward reconfiguraiton of the interface elements for mobile and tablet sized screens.
In the images above, the desktop version (left) has several modules concurrently activated, while the mobile screen (right) shows only the most vital interface elements at any one time, while still allowing access through a globally visible navigational element.
Combining this modular system with the in-game Dash transactions should also be possible in this way. To make Dash payments, generally a player would need to scan a QR code or copy transaction information quickly with a simple button. A modal window with this information can be presented to connect the players game with their Dash wallet of choice facilitating transactions in just a few clicks.
The first steps on a long interface journey
As we further clarify ideas in the coming weeks we will surely see further big changes to the User Interface. The addition of our new UI designer—Welcome aboard Adam!—will mean the fidelity of our mock-ups and designs should start to increase at a much higher rate, taking us one step closer to the game we envisioned when we started this whole process.
