“Hallway usability testing” means doing a quick usability test with somebody you found in the hallway, or in this context, my little nephews during a family visit. Let them play and observe how they cope with your software. Can they figure out the game without instructions? Do they get stuck somewhere? Are they struggling to make the user interface do what they want?
I did a whole bunch of informal testing like that with Happy Usagi, and one of the problems I observed most frequently was that players were struggling to place blocks in a 3D environment.
For example, you can place a block on top of another block, or behind one. The block cursor indicates where it is going to be placed after you click. This block cursor is always shown on top. After all, if it was drawn behind, you can’t see it and it’s not much of a cursor, is it? Behind or on top, the cursor looks exactly the same, and this caused a lot of confusion. I did add green guidelines to indicate the position of the block relative to the floor, but these indicators were almost universally misunderstood. So: big usability problem.
Hallway usability testing is a great way to check your assumptions. You may think that the green guidelines are obvious and that people will figure them out soon enough. Well no luck, after observing the same issue over and over again, it was time to stop blaming the user and think of a different solution
Lets take a step back. Why do we have a 3D environment in the first place? Maybe it’s an odd choice for a casual game. Happy Usagi was inspired by Neko Atsume. In that game you have to collect cats, and the user interface is simple and easy. You’ll have no difficulty at all controlling it on a tiny phone screen. But no wonder, the cats never move around and can only appear in certain predefined locations on the screen. The Neko Atsume world is a static image with cats stuck on them in fixed locations, a bit like an advent calendar for cats.
For Happy Usagi, I wanted the bunnies not just to sit there like lazy cats, but to do something; to hop, run, slide, and generally move about. And that means the game world should be an actual three dimensional model. This is a challenge.
I came up with the following solution for the block placement problem. I radically altered the block cursor. Instead of just a block, the cursor now has a bright beam that extends upwards. This way you can still (kind of) see the cursor even when the block itself is occluded. The video above should make the difference clear.
Does this actually help usability? First tests (done on Olivia) are hopeful. But again, you should check your assumptions. I really won’t be sure about this until my nephews have played it.
Nicely done implementing the beams; it definitely makes ascertaining the position of a given block a breeze. I am curious to learn how you achieved the 3D depth. Is the game truly 3D, or 2D “pretending” to be 3D?
The image you see on the screen is a composite of 2D bitmaps, but the game world is simulated in a 3D matrix, and all the bunnies have an x, y and z coordinate. So it’s mostly 2D but there are some 3D aspects. Aren’t all games projected on a 2D screen in the end?