CS459 project “Cubes” Final Report

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 subjectively 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 (“pick-up-and-play”).)

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.

Persona

Missing.

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 chose 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 built a prototype of the selected design, largely identical to the previous running prototype for the #3 variant except for the addition of 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 added keyboard-based block 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. Furthermore, the block menu now reorders itself to place recently used blocks in the ten keyboard-accessible slots.

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.

Here are two screenshots of an early state of the post-design-selection prototype. At this time, the recently-used-blocks feature had not been implemented; with it, the ten numbered slots are not placed at the bottom of the screen, so that the currently selected block does not appear to be floating in the middle of the screen. Note that this is an unusually small window so as to show the surrounding 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.

Implementation issues

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).

When using the options menu and other controls, the keyboard focus may leave the game viewport, causing the movement controls to become nonfunctional. I have mitigated this by a adding visual cue for focus (desaturating the view on loss).

Additional work

I also made the following changes seeking to improve the usability and user experience, but not based on the research in this project:

• I added lines to mark the boundaries of the world (the point past which no blocks can be placed).
• I added sound effects, synthesized from the block designs, currently only for block placement and removal. The sounds are synthesized so that every block has a unique sound, of a consistent style, without requiring the user to design those sounds as well as the appearance.

Evaluation

I have failed to make any progress towards systematically evaluating the design choice or the usability of Cubes in general.

One possible way to evaluate the system's usability for new users would be this: design a scene in Cubes (a block set and a scene built using those blocks), take a screenshot, then give them the task of reproducing it. This would test whether the controls and model are discoverable, and reactions and a survey afterward would indicate whether it had been fun.

Giving a specific scene to recreate would reduce variation across users and avoid the users “blanking” on what to create, but might discourage those not interested in the specific artistic style.

Conclusion

While this HCI work has been useful to the project, I have not managed to do it well, on schedule, or completely, within the semester.

I intend to continue working on Cubes, as it is something-I-want-to-exist independently of this course project. I will use the results from the project, most notably the user survey comments, to guide my future development.

Future Work

These are additional planned features or refinements which may be of interest.

• Reuse of block sets. Currently, the user is presented with a single world which they may edit, and a block set for that world. It should be possible for the user to design a block set and then use it for multiple worlds, or to share it with others. It should also be possible for the user to replace the block set of a world with another existing one (analogous to upgrading the game).

• Make circuits usable. “Circuits” form the programmability of Cubes. Currently, circuits are assembled by placing blocks with cryptic symbols adjacent to each other in specific arrangements. The circuit system needs documentation, more intuitive visual presentation, and a more understandable and useful set of components.

• “Painting”, or editing many blocks at once. A single full-cube block has 1352 exterior sub-blocks; changing the visual appearance of a block can require that many individual operations! In order to make experimentation practical, there must be tools which make it possible to perform paint-program style operations (e.g. rectangles, fill, color find-and-replace) rather than having to aim at and click on each block individually.

Appendix: Survey form

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