Briefing:

Combopedia is intended to be a resource for learning and sharing combos for Persona 4 Arena, a 2D fighting game for video game consoles. Players control a single character to attack and defend against an opponent character, controlled by another player or by the computer.

Instead of a mouse and a keyboard, players use specialized game pads to control their characters. The controller consists of four buttons labeled A through D and a joystick. The joystick can be pressed in 8 directions: up, down, left, right, and the diagonal directions. The joystick can also be used to sweep through 90 degree arcs; these are called quarter-circles.

Certain sets of button presses and joystick maneuvers can be performed in sequence to create powerful attacks; these are called “combos.” A combo consists of a set of moves, where a single move is defined as a set of buttons pressed simultaneously, a single joystick maneuver, or both performed together.

There is a complex keyboard notation for inputting combos that is used on various internet forums; however, this notation is intended mostly for advanced players. Combopedia attempts to give less experienced users a more graphical method of sharing and learning these combos, while still allowing advanced players to use the conventional keyboard input.

Scenario tasks:

Task 1

You are new player to Persona 4 Arena, but you have discovered a new combo. You would like to share this combo with the rest of the world, but you don't understand combo keyboard notation yet. To perform the first move, you must hold down B while simultaneously moving the joystick from the bottom position to the right position.

Task 2

You are an advanced Persona 4 Arena player, and you've discovered a new complicated combo. You are used to the conventional keyboard notation, and you would like to share the combo online. The moves for the combo are 123, B+C, 3, D, 236, B+C+D. Later, you realize the combo would be stronger if the last move were omitted and the first two moves were swapped.

Task 3

You are a newer player using the character Rise. You would like to find a combo that has a very high damage value and view information on how to perform the combo.

Initial prototypes:

For the initial prototypes, instead of creating a single, coherent interface for the entire application we sketched multiple possible interfaces for each of the small, specific tasks that would benefit the most from testing. We did this because we believed our most challenging issues were in the lower level interactions of inputting moves, instead of more macro-level navigation issues.

Graphical move input

We created three prototypes for inputting a single move graphically. The user was given a physical description of the intended move and would have to input that move into the interface.

Prototype 1

Prototype 2

Prototype 3






Toggle-able text buttons for each possible
button press or joystick maneuver.

A more graphical layout of toggle-able buttons
corresponding to every possible button press
or joystick maneuver.

Designed with inputting joystick gestures in mind.
Instead of a single button representing a gesture,
the user would click on the buttons corresponding 
to the beginning and end of a joystick sweep.

Manipulating moves in a combo 

We made three prototypes for the larger move-manipulation interface. Assuming that the graphical move input was a black-box, the user was given the keyboard description of the moves in the combo, would input them into the keyboard box, and was then asked to rearrange and delete some of the moves.

Prototype 1

Prototype 2

Prototype 3





The user can input using either the graphical mode with the left box
or the keyboard mode in the right box. The combo viewer on the 
bottom shows the previously inputted moves, either in graphical or 
text mode, selectable through a tab. The moves in the combo viewer
can be rearranged through dragging, and edited or deleted by clicking.

Essentially a rotation of the first prototype

Instead of both the keyboard and graphical views visible, these are
collapsed into tabs, while both the text and graphical views of the
moves are expanded into two columns.

Organizing / searching for combos

The interface for organizing and searching for combos was the spreadsheet like interface described in GR2. The user is able to click on the character tabs on the right side, and sort by clicking on the appropriate column headers.

     

Initial prototype observations:

Users had trouble understanding the first, table and text based move-entering prototype. Multiple testers with no fighting game experience didn't understand the idea of "quarter turns," and a tester with fighting game experience stated that he preferred the familiarity of an interface resembling a real game pad.
With the other two move-entering prototypes and both move rearrangement tasks, the main trouble users had was with the concept of multiple button moves and the use of the add button after each entering each move. Testers 2 and 3 both tried to input moves sequentially without pressing the Add button and had to change their conceptual model when only one, multi-button move resulted. Even after understanding that each of the buttons was a toggle, several users commented that pressing "Add" after each move was time consuming, especially because multi-button moves were not all that common.
Most users commented that the third move-input prototype was the visually most inviting because of its resemblence to a real fighting game controller, with one tester stating that the second move prototype was visually overwhelming because of the many buttons. However, the graphic of the joystick was not helpful. Tester 4, an experienced fighting game player, commented that he would have liked to drag the joystick graphic; users were confused because the graphic seemed to indicate an affordance for dragging, while the intent for the prototype was for users to click on the individual directions. Overall almost all testers found the move inputs to be conceptually confusing or annoyingly inefficient.
Most testers didn't have trouble figuring out the keyboard input task, although Tester 3 wasn't immediately able to find the keyboard input tab in the second move manipulation prototype. Users were annoyed again, however, with the need to press the "Add" button after each move. Because the keyboard input is faster than the button based input, some users suggested making it possible to input multiple moves in one line, maybe seperated by semicolons or commas. Users were able to rearrange and delete moves, although tester 2 stated that he would have preffered if the move icons were clearer about their deletion and rearrangement affordances.
The testers found the third sorting task to be relatively straightforward because of its similarity to conventional spreadsheet applications. While all users were able to arrive at the correct combo, they went about it in different ways. Tester 1, 3, and 5 did not notice the character tabs on the left, and either sorted the entire spreadsheet by character or needed prompting. Several testers never sorted by damage and instead selected the correct combo by inspecting the list.

Second iteration prototype:

For the second iteration, the interface was fleshed out so that the same interface could be used for all three tasks. The searching, sorting, and browsing interface remained essentially the same, except for a slight rearrangement of the character tabs on the side to make the tab-like nature of the widget and the hierarchical organization of combos more obvious.

     

Specific modes for viewing the a combo and entering the meta-data for a combo were sketched.

     

  

The biggest changes were made with the combo and move viewing interface.

  • The buttons are by default not toggles. Every button press is instantly added as a new move on the move display.
  • Therefore no "Add" button is needed, trading increased efficiency at the expense of safety.
  • To offset the loss safety, each move is easily deleted or rearranged through clear icons on the moves. A final "Finish" button still must be pressed to confirm the input.
  • Pushing the "Multi-button" button now activates a toggle mode. In Multi-button mode, every button becomes a toggle for a multi-button move. The move is completed by pressing the multi-button button again.
  • Joystick input is now performed as if the mouse were a thumb on a real joystick. The red hand-icon indicates a dragging affordance; the user moves the icon close to the directions on the outside circle. These directions light up as soon as they are activated.
  • Instead of hiding information behind tabs, keyboard input, graphical input, text output, and graphical output are all shown at once.

     

Feedback from studio:

  • The ability to make move deletions was not completely clear
  • The multi-button, done button sequence was was not completely clear
  • Concerns about whether the ability to edit previous moves was clear enough
  • Suggestion that the multi-button toggle state be replaced with a keyboard button, like holding down shift
  • Suggestion to implement merging moves by dragging one move over another
  • No labels

1 Comment

  1. I appreciate all the hard work you put into this. I think you still have a bit of work left to do to get the most out of the paper prototyping stage, but I think most of it can be handled by just thinking critically about the feedback you got already. 

    Your feedback from grading is below:

    User testing observations: You tested a lot of users, but your writeup doesn't reflect any testing of your second iteration. They look like good changes, but it will be important to run these by more users. I would also like to see you try to find some people who are already frequent forum posters to test on, if possible.

    A few things to note, going forward: keep an eye on the requirements in the assignment. Make sure you really stick with the feedback you've gotten so far. Keep in mind what makes this assignment interesting (the user population), and really focus the implementation on those parts.

    Please let me know if anything is unclear.

    Best,

    kp