CS459 project “Cubes” Iteration #3 Report

Per the requirements outlined at the course site. This report incorporates the previous reports.

Problem Space

The overall system is a block-building game. This is not a new idea; in fact, the inspiration comes directly from the wildly popular Minecraft. I am looking to produce, not a game that is better or different in a particular way, but a foundation that can be used to make a game that is better in a way the player (user) wants.

The core functionality of the game is largely fixed based on the original concept: the player has a first-person view of a block world, and can add and delete blocks in that world. The available blocks to use for this purpose, the "block set", can themselves be edited by considering them as sub-worlds and editing the smaller blocks making them up (thus defining their shape, color, and behavior).

for this HCI project, I consider only the problem of the user interface for interactions with the world: choosing a block type and placing it in the world, deleting blocks, moving around the world, and editing the block types and block sets.

Goals

Usability Goals

• Familiarity/“intuitiveness”: The interface should be readily understandable by a user familiar with Minecraft, and to a lesser degree first-person games in general (WASD/mouselook interface).

  (Minecraft is particularly relevant because its users are the largest population of people who know they like games like I’m building.)

• Visibility: The elements of the conceptual model should be presented to the user in a way which makes it clear what the relationships among them are and how to edit them.

• Efficiency: The player should not find that a long time investment is required to play.

  (This means such things as avoiding needing to perform tedious manual actions such as replacing many blocks by hand, and making sure the game itself has a short load time.)

• TODO: Need more goals

The first of these goals is the most important; if it is lacking, then no one will get around to caring about the nifty world-editing part.

User Experience Goals

• Fun, at least to the sort of person who enjoys Redstone design in Minecraft and building large-scale active/reactive constructions.

• Immersiveness: The means of defining blocks and their behaviors should feel similar to the building of structures out of those blocks. Interactions should take place almost entirely within the 3D space.

• Unlimited customizability of the appearance of the world, within the pixelated-blocks constraint/aesthetic.

Conceptual Model

The conceptual model consists of the following elements:

World

A world is a three-dimensional space (in the current prototype, of finite volume) in which blocks are placed aligned to a cubical grid.

Block

Each grid cell of a world may be empty air or contain a block. Blocks are generally solid, obstructing the player's movement (and forming the floor they stand on). The appearance, properties, and behavior of a block are determined by its type, which is one of the elements of the block set. For the most part, all blocks of a given type are completely identical.

Block type

A block type is a particular design of block. Each block type has a world whose constituent blocks are a large-scale model (currently 16×) of the shape and color of the block. The block type may have additional information specifying behavior of the block, and metadata such as a name for the block.

Block set

A block set is a collection of block types. Each world contains blocks from a given block set; therefore the block set determines the theme and capabilities of the world.

There are two basic activities that the user may engage in: building structures in a world (using its block set), and editing the block set (which consists mainly of editing the block types' worlds and viewing the results in a world which uses that block set).

Type of interaction: My plan is for the interaction to be direct manipulation as far as possible.

User Data Collection; User Needs & Expectations

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 the analysis. A 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.

TODO: Add more material on user needs as derived from the survey.

Persona

TODO.

Initial Design Alternatives

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.

Design Selection

I received feedback from the other students on my designs. I should have had input from potential users evaluating the designs, but did not get around to publishing a survey.

The feedback consisted of comments about each of the designs. In order to summarize the feedback, I assigned numerical values to the feedback. In cases where they simply stated that they preferred a particular design, I used a value of 1 for that design; preference rankings and caveats resulted in smaller values for the other designs. I did not choose to normalize the values such that every respondent had the same weight.

In two cases, it was specifically mentioned that Design #3 plus a toggle control to switch to normal mouselook would be best, or would be better than Design #3. (I suspect I may have mentioned the idea during the presentation of the designs, but I do not recall either way.) To accommodate this, I added a “fourth design” and assigned it points in the same way; those respondents which did not mention it have the same score listed for it as they do for regular Design #3.

While the technique I have used is not especially well-founded and non-arbitrary, I do think it has produced useful results.

Data

Analysis

It is clearly the case that Designs #1 and #3 are preferred over Design #2. I have decided to discard Design #2 from further consideration. Design #3 won by votes, but it also had many more strongly negative opinions (that it is clunky, that it “will alienate Minecraft players”, etc.).

Note, however, that “Design #3 + toggling” is not only the most liked, but it is somewhat like using both Design #1 and Design #3.

Therefore, I have made the plan to develop a single system with the toggle, with consideration for returning to a purely #1 or purely #3 design if it becomes clear that one is to be preferred over both.

Prototype after design selection

I have built a prototype of the selected design. It is largely identical to the previous running prototypes for the three designs depicted above; it merely needed to take the #3 variant and add the toggle.

Implementation choices

The toggle has been assigned to the Q key, adjacent to the movement controls. (I plan to support user-selectable key bindings in the future.) When in the mouselook mode, the block menu is hidden to give more view area and avoid accidental clicks, except for the currently selected block; this serves both to remind the user which block they have ready and to give feedback for the keyboard-based menu selection.

It is possible to place and remove blocks in either mode; therefore, one can choose to operate only in mouselook mode (as in Minecraft) and only toggle so as to get access to the block menu. I plan to investigate adding a recently-used-blocks list or user-configurable subset of all available blocks, so that the game can be played using only the keyboard to access commonly used blocks.

The prototype

In addition to the work for this project, I have made many other improvements to the game engine, including in performance and graphical appearance. In the user interface, the block menu now has numbers indicating the keyboard shortcuts. There are now user preferences.

Here are two screenshots of the current state of the prototype, in the two modes.

Implementation issues

In the first image above, you can see the current menu selection floating near the middle of the screen. This is because it is in the same position as when it is in the menu; I plan to fix this by having it slide down to the bottom (as if only the first row of the menu exists). Also, these screenshots are of an unusually small window so as to show the UI elements clearly; the menu will take up much less of the display area in actual games, and it should probably be changed to adjust its size for the display size.

The technical inability to capture the mouse pointer from the web browser environment still means that the mouselook does not function ideally (in that turning left/right is acceleration-controlled rather than direct) but because there is now an independent fixed mode for block placement, it is now possible to adjust the mouselook behavior to be optimal for movement and looking around rather than for pointing at blocks (though my experimenting so far has led to improvements for both purposes).

Appendix: Survey form

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