UI

Week Twenty-three

(or Work, Work)

Violent Traversal has been hard at work developing AIM< over the past couple weeks. As I talked about in my last post, we recently established a concrete mission statement for the game. We also prepared for and conducted another play-test, specifically addressing player movement, controls, and moving platforms. All of the recent developments paved the way for me to start developing a more robust UI (user interface).

I discovered through research and analyzing other games, that UI design and control schemes are closely tied to one another. Both systems allow players to interact with a game and receive feedback, essentially forming the connection between the players physical presence and digital avatar. Often, controls and UI are integral to the way a game "feels", significantly influencing a player's decision to interact. So it's only natural that as controls and movement were addressed, I was better able to continue designing the UI.

Many games feature a UI design referred to as a HUD (heads up display), which displays heuristics to players on an invisible border between the audience and the digital game space. It's a fairly intuitive method for giving players the information they need to see without any obstructions. Clarity is key for the audience successfully interacting with a game.


The traditional HUD-style approach has been used since early arcade games and is still pretty common in many modern games. Part of the reason the design has been used so long is due to the immediacy of the information provided by the design.

Another UI type is "diegetic". The term "diegetic" is borrowed from film and other entertainment design and refers to sound that exists within the space a narrative is taking place. Like music played by the jukebox in a bar scene, for example. When used referring to a game's UI, the term applies to elements that are present in the environment for both the characters in the game and the player experiencing the game as a part of an audience. When implemented well, this design provides information clearly in an immersive manner, which allows the audience to stay connected to a games narrative. The design tells the player what they need to know to play without breaking the "fourth wall".

What does all of this mean for AIM<? Well, I came to the conclusion that a blend of different UI designs would be appropriate for our game. I designed some elements as diegetic; like the resources a player currently has stored and mech damage. Information on currently deployed drones and their durability or "health", is conveyed to the audience in a more traditional HUD fashion.

Even though I chose to design certain aspects of the UI  as a traditional HUD, I borrowed design language from other games that might not immediately suggest "HUD". When AIM< players select ammo or look to see what drones are already deployed, the interface looks like a card from a TCG (trading card game). The elements are arranged to communicate a unit's (the drone or shell) resource cost and reflect the current state of a deployed drone. I appreciate the way cards from TCGs communicate heuristics to players immediately and concisely. I wanted to bring some of that beautiful design and efficiency into AIM<.

The most important function of a UI is communication. If the player's needs aren't met by the UI, a beautiful or technically impressive game will be crippled and unplayable. Players quickly stop playing when frustrated by a lack of feedback and/or poor controls. Games don't exist without players, so designing a solid interface and controls is imperative.

That's all for this week. Thanks for reading and check back for more soon!

AIM< UI Concept by Aram Wahler

AIM< UI Concept Revision by Aram Wahler