CS459 project “Cubes” Iteration #2 Report

Per the requirements outlined at the course site.

Data Collection

Using my blog and Google+ (links to posts), I publicized a survey. I requested it be taken by people who play block games or who were interested in the Cubes project (which I had previously announced).

The survey form may be found at the end of this document. The data itself will be provided separately and not made public.

I received 24 responses before I began analysis; as of the date of this report I have received 2 more which I have not incorporated. I have not yet performed any systematic analysis of the data, but casual examination revealed the following trends:

• There is a relatively even mix of single-player and multiplayer game interest, but of those who want multiplayer, they mostly want “small” multiplayer, i.e. with a group of friends, as opposed to a “large” environment where players are more independent.
• Of the options I offered for in-game programmability, the most popular was that of “something higher-level than logic circuits”. This supports my intent to do just that as part of the original game concept.
• Of the respondents who were Minecraft players, many complained about the tedium of mining (repeatedly breaking blocks) and inventory management (moving stacks of items between character inventory and in-world stores). This was not something I asked about in the survey; I have not even decided whether the final game should include any resource management component.
• Several people told me that I should study the game Dwarf Fortress, which I know something of but have not actually played. However, I do not think my time on this project is best spent learning DF's infamously arcane user interface to find insights from it.

I still have yet to construct personas.

Designs

In order to have a sufficiently small and concrete problem for this HCI project, I chose a particular scope for the design alternatives: block picking and editing using mouse and keyboard input. I am therefore not looking at other user interface design problems which Cubes has or may have:

• Interfaces for input devices other than mouse+keyboard (e.g. touchscreens).
• Circuit design (programmability).
• Customization of game aspects other than blocks.
• Saving and sharing of worlds.

Design Process

The existant prototype constituted a base design. I considered my experience with the prototype and how it failed to be comfortable to use (to myself), and chose to vary those aspects to construct two alternative designs.

Design #1: Current / "Physical Manipulation"

This design places an emphasis on the 3D view of the world pseudo-physical manipulation; explicit user interface controls are kept to a minimum. In the current prototype, the only such game control is the menu for picking blocks to place.

All interactions with blocks other than picking for placement are done by aiming at a block in the world and pressing a key or mouse button. Even operations which logically operate only on the blockset require that at least one sample of the relevant block is present in the world.

The specific controls in the prototype are standard FPS controls (keys WASD for moving; mouse for changing view direction; keys EC for flight) plus the R and F keys which enter the world of the block aimed at, and exits to the previous world, respectively. One mouse button places or removes a block and the other brings up the menu of blocks.

Critique

The advantage of this design is that (for the experienced gamer who doesn't mind learning a key mapping), the controls feel direct and physical; all interaction with a block is done by first aiming at the block.

This design has proven uncomfortable to use. In particular, the right-click pop-up menu requires mouse motion which interferes with movement/aiming, and the choice to use a single button for placement and removal of blocks means that undoing a mistake is tedious. However, these problems could be resolved by using a keyboard-controlled toolbar (as in Minecraft) for selecting blocks — but this creates the problem of handling more than 10 or so block types.

More theoretically, I am doubtful that this design will feel natural for the full range of blockset operations (in particular, deleting or adding block types).

Design #2: "Modal" / "Reified Blockset"

This design takes a sort of opposite approach of design #1; the block-set itself is emphasized as an element which can be interacted with. The block menu from design #1 is made into a full-screen element with additional controls for editing the block set; conceptually, where design 1 allows navigation from a world to a world defining a block in the previous world, this design has the user navigating first from the current world to the blockset of the world, to any of the block-worlds “inside” it.

Since the block menu is less tightly associated with the mouse cursor, we allow it to be brought up by the keyboard instead; the "enter world" (R) key from design #1 could instead bring up the menu, allowing the use of separate mouse buttons for placement and removal of blocks. Additionally, the layered UI suggests that the Escape key could serve as a natural gesture for leaving the block menu as well as sub-worlds.

This design as presented and prototyped so far still has the problem of mouse movement around the menu being tiresome; I plan to augment the full block menu with a shorter constantly-on-screen menu of recently used block types, which can be accessed using numeric keys. This is essentially similar to the interface of the modern Minecraft creative modes (in Pocket Edition and Beta 1.8, though the latter has an explicitly managed toolbar rather than a recently-used list).

The following prototype screenshot differs from my concept in the following ways:

• Not having a recently-used toolbar.
• Not having the controls laid out well (centered).
• The “Edit” buttons per block are perhaps too emphasized; alternatives could include a contextual (right-click) menu for the blocks.

Critique

The principal advantage of this design is that by having the full block set be a separate non-mouselook screen, conventional user interface widgets and principles can be applied to blockset editing operations. This should make the system more discoverable.

The disadvantage is that the game now has two UIs which are very different; making the controls be coherent between the two of them is hard, as I have found while working on the prototype.

Design #3: "No Mouselook" / "Paint Program"

In this design, we place controls directly on the main game screen. This implies that mouse movement is not dedicated to aiming in the world, as if it were, you would look down and spin around whenever you picked a block.

Instead, left/right rotation happens not continuously but only if the mouse is near the left or right edge of the screen, and up/down rotation is eliminated entirely in the current prototype (a limited amount might turn out to be acceptable). Thus the block menu, which is now permanently visible, occupies a "dead zone" which does not cause view rotation. Adding view rotation by keyboard might work.

Thus, block placement consists of clicking on the block in the menu and clicking in the world. (In this prototype, block removal has been assigned to a separate mouse button, as in Minecraft. This change will probably be done to the other prototypes as well.) Block editing is done by right-clicking on the block in the menu.

Critique

This design certainly reduces the ease of movement in the world, at least to the experienced FPS gamer. The reduction or elimination of looking up and down will make it much more difficult to build vertical structures.

However, this design has fewer “hidden elements” than any other; provided that the player knows that (a) the movement keys are WASD, and (b) both mouse buttons are used, all other aspects of the UI are or could likely be designed to be readily discoverable.

Appendix: Survey form

This is a non-functional copy of the survey form which was used for data collection.