Today, the topic of my sermon is ‘Immersion and the Interface’. I stray away from the topic of MUDs quite a bit to start with, but bear with me – there’s a point.

For a little background context, I’m an accessibility researcher in real life. I came to my doctoral work relatively late in my career, having taught for ten years before actually deciding that ‘hey, a doctorate may make it easier to get a job in future’. I choose my PhD subject on the basis of the fact it was fully funded, and I was told at the start ‘You can do whatever you want to do, it just has to relate to the brief of the grant’ The brief of the grant was ‘technology to help an aging workforce’, which is a giant area absolutely brimming with interesting technical and social problems to solve. The combination of ‘fully funded’ and ‘within reason, you can do whatever you like’ is incredibly rare, and so I became an accessibility researcher.

My point here is that it wasn’t something I originally had a vested interest in pursuing. Sure, I’d taught courses on user interface design and had done the usual ‘due diligence’ lectures with regards to accessibility, but it was never something I really thought much about. As such, I suffered from the same biases and prejudices that afflict most ‘techy’ people, whereby I just assumed that any problems people had working with technology were, in the main, ‘user errors’. In the rare cases where the interface was to blame, then it was *obviously* to blame – I thought that bad interfaces were the exception, and not the norm. I didn’t think user interfaces were *good*, I just believed they were, on the whole, mostly okay.

Over the past three and a bit years, my attitude has shifted entirely, to the point where I regard mistakes that people make with computers to be, almost entirely, the fault of the people (like me) designing software. That’s a change in philosophy that has come about gradually, but it has been speeded immensely by simply working with novice computer users on a regular basis both in the drop in ‘user centre’ that the university runs, and within the fixed experimental studies that I conducted for my research. It’s only when you sit down with ‘normal’ people that you start to really question the fundamental assumptions that people make when designing user interfaces. On the whole, user interfaces (as far as ‘normal’ people go) are too confusing, too inconsistent, too restrictive, and too complex. When you try to justify why user interfaces are as they are, you start to realise that the justifications you can put forward are pretty unconvincing.

I have come to think of user interfaces as an obstacle that must be traversed in order to get from A to B, where A is ‘what I want to do’, and B is ‘I’ve done what I want to do’. For the majority of users[1], the obstacle has no benefit – it’s just ‘in the way’. An ideal user interface is one in which the user does not need to expend any cognitive energy in moving from A to B. Sadly, until we have computers that can read minds and intentions, that’s an impossibility. What we can do though as developers is to make sure that the obstacles are as small as possible.

This is the basic function of a user interface, and it doesn’t matter whether that interface is GUI or command line – good interfaces get out of the way of people. The time you spend working out how to accomplish an action is time that you’re not invested in achieving your goals. It’s computer time but it’s not productive time. It’s busywork that is stopping you from accomplishing the actual work you have to do.

When talking about the interface to a text game, the commands we type and the output we receive in turn is our user interface. As games designers, it is our job to make that interface as unobtrusive as possible. We should make sure that we slim down all the obstacles we can. As an example of these obstacles in a MUD, imagine the following interaction:

> sew shoes with thread

You must be holding the shoes to sew them.

> hold shoes

You hold the pair of shoes.

> sew shoes with thread

You must be holding a needle to sew the shoes.

> hold needle

You hold the sewing needle.

> sew shoes with thread

You must thread the needle with the thread before you can sew the shoes.

(and so on)

I’ve seen this basic interaction process a thousand times, and each time it frustrates me. I’m not interested in the minutiae of inventory management[2] – I just want to fix my shoes. Every time I get an error message like that, I get a little more frustrated. The intention of messages is, I assume, to increase immersion – the problem is it has the opposite effect. It forcibly removes the sense of immersion because you are all too aware that you are playing a game. Immersion is better served by an unobtrusive interface:

> sew shoes with thread

You put down your sword for a moment and pick up your needle and the shoes. After threading the needle, you deftly weave it in and out of the rip in the garment. After a few moments work, you are done and the shoes are as good as they ever were.

Here, the exact same level of detail is preserved, but the interface is far less intrusive. The obstacle between A and B has been slimmed – perhaps even removed. For gameplay reasons, you may wish to ensure that the obstacles are a little larger (for example, you may require players to move out of combat in order to repair), but that’s okay. The obstacles you place for gameplay reasons achieve larger goals. However, even when you put in obstacles you can be more ‘user friendly’ about it. Even the mechanics of first example could be preserved and made less frustrating if the interface was just a little bit more helpful:

> sew shoes with thread

You cannot sew the shoes because you must be holding the shoes to sew them, you must be holding the needle, and the needle must be threaded.

That allows us as players to at least correct all the obvious problems before we attempt the interaction again. It takes a little bit more discipline in coding, and also requires a step away from the common style of ‘check this, error if false’ of command validation, but the benefits are considerable. Every effort you make in ensuring the interface is as unobtrusive as possible is genuine frustration you are removing from your players – the less frustrated they are, the more they can invest themselves into appreciating the game you have created for them, rather than focuses their attention on the interface that thwarts their efforts.

[1] The difference in attitudes between techy people and normal people is something like the difference between soldiers on an assault course and people just trying to get home after the day’s work. If you are a soldier on an assault course, the obstacles have inherent value because they are part of perfecting your skills. If you’re just a guy trying to get somewhere though, the last thing you want to do is have to do chin-ups and then scale a ten foot wall.

[2] Inventory management can be fun (especially if you like playing dress up), but only when it’s done for entertainment. I can’t imagine many people consider manual and mandatory inventory management in the course of accomplishing an action to be anything other than a chore inflicted in place of real gameplay.