Hero Arena

HeroArena_ConceptDoc.pdf (© 2014 Rich Rowan)

For my User Experience class at DigiPen, one of the assignments was to take the concept for a game - Hero Arena - and lay out wireframes for it. I started with a mind map, then sketched up wireframes for it on graph paper. After that, with a group, we revisited the mindmap and refactored it, then redoing the wireframes in much the same way. Finally, we took our low-fidelity wireframe to a high-fidelity wireframe with a lot of pretty artwork.

Information Architecture Approach

In general, I tried to keep track of all of the UI states the game would need, but also the individual pieces of information that the player would need to have access to. These pieces of information are important, but not “big” enough to have their own UI state.

Additionally, there are some pieces of information, big or small, that players should have access to most of the time. Hence, the “Mostly Available” category. Now, these pieces of information have a few times where they are inaccessible (Resources or Party information from the Main Menu, for example). I denote when states unavailable with a list of children to that state indicated by an exclamation mark (“!”). This comes from the convention in C where an exclamation mark means “not”. So, for example:

Resources → !Main Menu

To mean you cannot access information about your Resources from the Main Menu.

In fact, “Mostly Accessible” had absorbed almost all of the “Outside Game” category, so I just gave it Main Menu too.

Finally, I split each game state off from the greater “Hero Arena” topic. This was mostly for aesthetic purposes, as large substates get messy quickly. However, this also allowed me to construct a rough UI State Map for this as well. It is not thorough by any means, but much of it is implied by the “Mostly Available” section.

Now, I'll go into greater detail about each subsection.

Mind Map Key

Unmodified text = Has it's own UI state

Italicized text = A smaller piece of information contained within the currently running UI state

Bold text = Text meant mostly as a reminder to myself while developing wireframes

!Text prefixed by exclamation mark = Indication of state where the parent state is inaccessible

Text postfixed by an asterisk* = Indication of state where I will be making a wireframe.

Text before a question mark ? More text afterwards = Condition ? (If condition is true) Do this

Mostly Accessible

This is information that players have access to (more or less) all the time. This is where I put all of the reference menus. In addition, it seemed like Main Menu seemed to fit there as well, to provide a game state that doesn't have any pressures of the game itself present. Quit Game is here as well, allowing players to stop playing at (almost) any time. Quit Game guarantees a character save and a clean exit. If you try to Quit Game while in an online match, you must agree to forfeit it.

I organized all of the menus into subsections – Transition Menus (menus that exist to facilitate transitions between states), Reference Menus (menus that exist to display information), and Character Select (character management, basically). It was getting pretty messy otherwise.

Party Info and Resources are pieces of information that should be integrated with every “in-game” state. Therefore, this information should be visible from every UI state except for Transition Menus, Reference Menus, and Character Select.

This is the most complicated game state, as the logic for it's existence is basically “Why shouldn't the player have access to this information all the time?”. Which is true, I always want my player to be able to get to “How to Play”.

In-Game

This is where all gameplay that isn't combat or minigames occurs. There's not a whole lot to this, as it's basically transitioning between combat, story, and minigames, or otherwise maintaining your resources/party. This contains the City Map and World Map, which basically serve the aforementioned functions.

Battle Mode

This is where combat takes place. There's a lot of information that got shifting into sub menus on this screen. For instance, controlling units happens when you select a unit, then select the command. And when you're issuing an attack, you can see the combat results screen, etc. But the main things I thought should be visible are: Turn Indicator, the Objective, % complete of the objective, the unit you have selected, a snapshot of that unit's capabilities, the terrain or structure you have select, and a blurb about that terrain/structure. Finally, the move timer, which could be disabled during offline play, but is always active in online play, and doubles as the online indicator. That's all in the main UI display on the left.

Next to that is the unit stack, which shows the next unit and can be expanded to show all of the units. Finally, on the right is the Flee, Reference, and Pause buttons.

Mini-Games

Mini-games have their own interface, but I tried to stay within the confines of the interface I'd developed for the rest of the game. For instance, the Gem Mine interface is nearly identical, except with the addition of some empty space on the right to make the main gameplay window square. The Sulphur Pit interface had the bottom portion removed because there was no use for it.

Wireframe Sketches

These are the sketches I did to figure out the wireframes. You can see I started with a pretty bulky interface, but I liked it because it was very consistent between screens. In the Sulphur Pit sketches (the last two) you can see me starting to move towards a more compact interface.

High Fidelity Wireframes

Here are the final wireframes, after my group and I compared our wireframes against each other's and took the best parts of all of them. The group liked my idea of having a consistent UI throughout most screens, but pointed out that I was using way too much of the screen space. So we heavily condensed it to the screens you see above. 

For reference, I did little of the actual artwork seen here, but I handled the layout of most of the wireframes.