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

Goals

Week Twenty

(or Again, You Aren't Missing Something)

It's now the second week of the semester and I'm hard at work on AIM< along with the rest of Violent Traversal. So far the past couple weeks have been a flurry of catching up on what everyone's been working on and plotting out a tentative roadmap for the next 12-ish weeks of development until we publicly demo AIM< gameplay at SGX17.We are planning to have playtest events, which will be detailed on the AIM< Facebook page.

Over break I worked on some concepts for the cannon's (now a "mech") leg design as well as design document odds and ends. See the gallery below for a look at the mech art.

The past couple weeks have included work on textures, models, mechanics, gameplay, and level design. On Monday we will be presenting the current state of AIM< to our producer and adjusting elements based on his feedback.

In my first blog post, "Initial Game Design and Ideation", I talked about the nature of AIM< as a capstone game design project at UW Stout. Fall semester can be summarized as a lot of ideation and pivots. Spring semester heralds the second "half" of the course and a bit of a shift in focus. AIM< now has a set mission statement, which will be used as the goal by which further decisions are made. I'll be trying to focus my blog posts more on the reasons behind the game design decisions I'm involved in and how matches up with the mission statement. Ideation still continues but there won't be anymore pivots since the endgame is set.

So what does a mission statement mean in game design? In a nutshell, the mission statement is the essential overall elements that create a game's identity. My professor here at UW Stout, Jay Little, teaches that a game's mission statement is three things; who you (the player) are, what you do, and how do you win. It should be short enough to explain what the game is as a concise pitch. The mission statement I wrote for AIM< looks like this:

"You (the player) control a mech that shoots projectiles and drones and seek to destroy an AI."

The mission statement can be expanded upon with details for the "back of the box" marketing bullet-points. My working version for AIM< so far:

"Take control of a futuristic mech able to launch drones and fire projectiles created out of recycled scrap materials. Gain the ability to create different types of drones and projectiles through power-ups.  

Experience compelling platforming gameplay where each shot fired reveals more possibilities through the planet’s dangerous terrain. Drones and projectiles are not just weapons but tools to provide solutions to challenges.  

The mech, drones, and projectiles all rely on one another. The mech creates specialized drones and fires projectiles. Drones collect resources, can be used as batteries, and explore out-of-the way places. Projectiles turn certain objects into scrap, siphon energy, and send resources back to the mech or a drone.  

Explore varied environments across the planet’s harsh surface, through claustrophobic caverns and an abandoned settlement.  

Use the mech’s resources wisely to outwit malicious technology and survive devastating environmental hazards." 

As a game designer, my goal with the mission statement and "back of the box" blurb is to give a potential audience enough info to decide whether to play the game.

Thanks for reading and have a great weekend!

AIM< Mech Leg Ideation by Aram Wahler