Immersion in roguelikes

Immersion in roguelikes

Note: this is a proposition for one possible game design process, not implying that all games should be like this!

I’m not a fan of elaborate menu-based interfaces for roguelike games, especially ones operated using the cursor keys or mouse, and I’ve said on various occasions on this newsgroup. In search of better solutions I’ve analyzed what it is exactly that makes the menus so awkward, at least for me? Apart from obvious mechanical flaws that make it harder to habituate and memorize the menus, there seems to be something “artificial” in them that feels jarring during the game.

And then I realized: The Cursor!

There is something magical in the way we can project and channel our attention and focus it on an abstract object on our screens, basically becoming it for the duration of performed task. Even when editing text or selecting something from the menu – we are the cursor, the cursor marks out location in the artifical environment, allows us to explore it, and also acts as a proxy to channel our god-like user powers and execute commands. We can ride it pretty much we would ride a bicycle – awkward and slowly at first, but as we learn, we stop to even notice it – it just feels natural.

There are, however, several prerequisites that need to be met before the cursor can become an extension of our bodies. Anyone who ever worked over a low-bandwidth telnet/ssh session, or just a very slow computer, knows it – the cursor has to listen to you. Always. No matter what. If it skips your key presses, if it does something else than you ordered it to do (for example, as a result of misplacing your hand on the keyboard and pressing wrong keys) – then it’s like falling off the bike. It’s an unpleasant sensation, like hitting a wall where there should be door. Extremely annoying. Even when for some reason the cursor cannot execute our command, it must at least say it – by blinking, by beeping, anything.

Another prerequisite is that we should always be able to anticipate the result of a command, or – when the command fails – why it did so. This is visible in some smart system that have do the most obvious thing button, when there is a disagreement between the user and th system about what’s the most obvious. This is also visible when there are modes and you make a mode error – this again feels like falling off the bike, or being thrown out of the application. How can something become an extension of your body, when it has a life of its own?

Finally, the last prerequisite: there can be only one. There can be only one active cursor at a moment. This is sometimes tricky and not immediately obvious – as the cursor can change its shape and function, our channeled soul can jump between several incarnations of the cursor – but ultimately, we can posses only one of them, and we have to do it directly. Using mouse to press buttons to move cursor is totally uncomfortable and resembles carrying a bicycle on your back more than riding it.

Now, do you see why the menus (the modern, cursor-based ones) are so evil? They rip you from the game’s world, and teleport your soul from the avatar you was controlling to some abstract cursor living in a dead world of clean-cut menus and dialogues, shaped into an antiseptic tree structure. As you play and the game becomes more complicated, you spend more and more time in this nightmare world of interface, returning to the beautiful and interesting world of game practically only to move your avatar a few squares, where you can fall in coma again and explore the menus.

Of course, the abc menus are not so great either. They have an advantage of not displaying any cursor explicitly – so that there is a chance that your mind won’t make the jump. Alas, your mind is not that easily fooled! If there is anything suggesting position in the menu – for example, if the menu itself is scrolled or multilevel (you can enter its items) – this will trigger the cursor perception, even when the cursor is only imagined and not displayed on the screen.

So what can be done? Obviously, avoid menus and other uses of cursors (for targeting, for example), have at most one-level menus displayed on the same screen where the main view is (switching screens is also perceived as moving around). Try to make most actions use direct manipulation of the in-game objects. Easy to say, eh?

I will give an example – a dip command present in some roguelike games. It’s pretty complicated, as it requires selecting at least two items – hard to do without a second menu. Now, how do we make a dip command that uses direct object manipulation instead? One possibility is a spill command, that will make the avatar spill the potion on the ground. Now, drop the items you want to dip, and spill the potion on them. Simple. You can make it even simpler – many roguelikes have a throw item command, and many of them have a rule that a thrown potion will spill on whatever it hits and affect it. Why not just throw the potion on an item on the ground then? And if the game doesn’t allow you to target specific floor squares – put the items under a wall and throw the potion against that wall. Isn’t it a lot much fun than wading through the menus?

You have probably noticed this by now – throwing requires targeting, modern roguelikes often use cursor for targeting. Rogue was nicer – it just prompted you for a direction. Of course, this greatly limited your choices, as you had to line up with the target – not such a bad meta-game, but you might not want it in your roguelike. What can be done? Maybe just a menu (one-level, abc-style) listing all the potential targets?

I’m sure you can come up with even better ideas!

Why don’t you try and make your game’s interface a little more immersive?