The gameplay/interface divide

 In Research, Uncategorized

Jespel Juul and Marleigh Norton presented a paper at the recent Foundations of Digital Games conference in which they questioned the popular wisdom that games should have “easy to use interfaces, but … provide difficult gameplay challenges”. To quote from the abstract:

this paper argues that it is rare to find a clear-cut border between interface and gameplay and that the fluidity of this border characterizes games in general. While this border is unclear, we also analyze a number of games where the challenge is unambiguously located in the interface, thereby demonstrating that “easy interface and challenging gameplay” is neither universal nor a requirement for game quality. Finally, the paper argues, the lack of a clear distinction between easy interface and challenging gameplay is due to the fact that games are fundamentally designed not to accomplish something through an activity, but to provide an activity that is pleasurable in itself.

I argue that they are wrong and the reason for their error is that they are regarding games from the point of view of the player, not of the designer. I will be so bold as to claim that it is of critical importance that the designer makes a very clear distinction between the gameplay and the interface and tries to always abide be the “easy to use, challenging to play” maxim.

An important thing when designing a game is to decide what is the experience you want to provide. Often this is some kind of challenge, physical, mental or social. A good design is coherent, fixing on a particular kind of challenge — say physical dexterity — and applying it consistently throughout the game. This way the player knows what kind of play to expect and can quickly establish whether or not to commit time to the game.

A poorly designed game is careless about the kinds of challenges it provides and so is disloyal to its players. It begins as a fast-paced game of physical dexterity and then later throws up a riddle-solving section that blocks all further progress. Players who committed their time to a reflex-based game are now confronted with a challenge they never expected and may not enjoy. This kind of unreflective mismatching is a great way to lose your players.

Having decided on a particular challenge, then the gameplay/interface divide is clear. The gameplay is that which provides your desired experience, the interface is the realisation of that experience on a particular set of input and output hardware. The interface is designed, along standard UI principles, to get as little in the way of the desired experience as possible.


To claim that in some games, such as Toribash, the “challenge is in the interface” is to be unneccessarily fuzzy-minded. If it is part of the intended challenge, it is not the interface it is the game. As a player it may not be clear which parts of the game were intended or accidental, but the designer should know better.

The gameplay of Toribash, as I read it, is in the strategic planning of joint movements in the anticipation of how the physics will play out and the opponent will react. The interface to this experience is the process of clicking on joints to select how they are going to move. Ans this interface is actually relatively poor. The targets are often hard to access on the 3D model (especially using the clunky zoom/pan/rotate controls) and selecting an action by multi-clicking to cycle through a list of options is tedious and error-prone. While I did not design the game, I doubt that this frustration is the experience the designer was trying to convey.

A better UI to the same game might be to have sidebar showing 2D front and back images of a standing fighter. Muscles could be clear, easy-to-select targets, colour-coded to indicate what they are doing with a drop-down menu or a set of key-codes to select a particular mode for each. Macro keys for selecting certain muscle/action combinations would take the drudgery out of constructing common manoevres through dozens of clicks and camera rotations.

Now maybe I have missed the point and the rapid, precise clicking is where the fun of Toribash lies, but my argument remains the same. Just because the gameplay involves what are traditionally considered UI elements does not mean that the two are the same.

Confusing interface and gameplay only leads to carelessness about whether your interface is providing or hampering the experience you desire. This carelessness can only result in sloppy interfaces that interfere with and frustrate play. Only a poor designer writes this off as “part of the challenge”. A good designer fixes it.

Recent Posts
Showing 11 comments
  • OfUnknown

    No wonder Toribash has a lot of members, yet very active and a very great community.

  • PID

    While I am sorry to hear that you have had difficulties with the interface system of Toribash, this is not entirely a design flaw. Within a day of beginning the game, I became able to rapidly and efficiently design rather complex maneuvers in seconds, a process which is doable with even the most limited mental capacity. Furthermore, Toribash is of course a game in current and constant development, and the observant eye would pick up multiple user-created “scripts” which implemented exactly the 2D interface you described quite some time ago. To criticize an issue that is not properly understood is to be unneccessarily fuzzy-minded. [sic]

    • Malcolm

      I was only referring to the standard Toribash interface as described by the paper I cite. I can see that this is a sensitive issue for you and I did not mean to insult your game.

  • hampa

    I am glad that my game design can be used as some sort of lessons for future game developers 🙂

    Thanks for the post


    • Malcolm

      You’re welcome. It’s a really fun game and a wonderful example for my game design class in many ways. I hope you don’t mind my criticisms, I wouldn’t bother if the game wasn’t worth it.

  • Jesper Juul

    Part of our point really was that the designer has to make a conscious choice what aspects of the game should be easy and what aspects should be challenging. So it seems we completely agree on that issue.

    What we disagree about is the definition of interface vs. gameplay. As I read your post, you are saying that anything intended challenging by definition will not be part of the interface? (“If it is part of the intended challenge, it is not the interface it is the game.”) That is a valid way to look at it, but doesn’t it lead to some strange intentional-fallacy situations where we have to divine the intention of the designer rather than to look at the actual experience of playing a given game?

    • Malcolm

      I guess this is an example of the difference between the designer focus and player focus. There is no “intentional fallacy” if I am talking to designers. They definitely have intentions for their games and they are better achieved when they are made explicit.

      I think this comes down to the fact that I am writing for designers while you are writing for critics. And that’s fair enough.

      • Simon Ferrari

        The only game I can think of with a purposefully (designed) challenging interface is Farcry 2, where pulling up the map while driving obscures the entire windshield in order to emulate reality. I have no idea which of the two of you I agree with, because I can’t read the article 😛

  • Simon Ferrari

    Blargh, I don’t have access to the ACM portal. How does the article treat the difficulty arising from limiting the size of one’s inventory? The reason I ask is that I feel like the limiting of the inventory in RE5 to 18 slots is the only thing that makes the game remotely challenging. I don’t mind inventory limitation in a game that places an emphasis on harsh “realism” (Lost in Blue, say), but in a game rife with implausibilities I can’t stand such limitations.

Leave a Comment

Start typing and press Enter to search