Modelling Interaction

Red Robot will be rather intensive in interactive elements, especially UI. It is thus rather important to have a good idea of how the interaction with the UI works; that is, not only what kind of UI screens occur, but also how the player interacts with them.

Looking from up high, UI looks just like a set of various panels and screens, which either exist or not, similar to a HTML webpage: Whenever the user interacts with the page, parts of it (or all of it) may change to a different screen. Additionally, a couple of bits provide permanent information.

However, it is not as easy. For example, constructing a new building is a more complex process: The player selects a construction category, and from there a building, which in turn allows her to drag a building template around to a valid location on the screen that, on beeing clicked, will fix the template in place, which now waits for a Robot to arrive and construct the building, during which it continuously displays a construction progress. Next to all these steps, the first part of the process should stop the user from performing some other UI-related actions (like selecting buildings), while some will cancel the progress and reset the UI state (like pressing the cancel button), or just suspend it (like pressing the menu button, or opening a resource status dialogue). To top it all off, some interactions may pose additional limits on passive state changes like notifications or value changes.

I call all these bits and pieces of an interaction the interaction state of the UI, next to the game state shown in the UI (for example, the amount of Strawberries in storage). To the player, this interaction state is very obvious, as not only is it part of her thought process in her mind, but is presented as the interplay of visible UI widgets. Still, care needs to be taken to have the interaction state change comforming to the player’s expectation.

Now, what is the actual state? Let’s return to the building placement example. We already observed the following steps involved in building placement:

  • No building currently happens.
  • When the player selects (possibly through multiple steps, which is taken care of by the menu widgets) a building to be placed, the game switches to building template movement. Now, the player pushes a building template around with her cursor.
  • When the cursor moves from a valid to an invalid location, onscreen information somewhere informs the player of building unsuitability. When the player moves the cursor back to a valid location, the game switches back to regular placement options.
  • Depending on pre-conditions, the game may not even switch into template movement, but flatly deny building construction with an appropriate message, not leaving the default game mode.
  • From building template movement at a valid location, the player can click to finish the building placement, returning the UI into the default state and creating the actual building construction job. Optionally, the screen may provide feedback for a short amount of time that the placement was successful.
    • Optionally, if the player confirms placement in a special way (e.g. by holding shift during clicking), the game returns to building placement mode after confirming and creating the new construction.

Next to the default game state, we have two states for valid an invalid placement options, and a couple of state changes from one state to another, based on player interactions and game state. In addition, each state needs to keep track of which other interactions are allowed:

  • Players may not select units when placing constructions. Additionally, players cannot click on any depth-placed UI, that is, UI elements that are positioned in the 3D world. All keyboard shortcuts related to 3D are disabled.
  • Players can click on any on-screen 2D UI elements, including the cancel building button, the menu button, other building buttons, etc.
  • Players can cancel construction mode at any time without further feedback.
  • Players can switch to other states that temporarily suspend building placement until these states quit: The main menu, Robot states, resource states, etc. All keyboard shortcuts related to these will work.
  • Camera movement is fully possible, including moving the screen with left click and drag. The building operation is confirmed by releasing the button in the same location, and can be canceled (by escape) until the button is lifted.

The root UI thus needs to track:

  • if the player can currently interact with any permanent menus (like the building menu) by clicking or shortcuts, which can be disabled when a larger overlay menu is shown,
  • if the player can move the camera,
  • if the player can currently interact with the game world by selecting elements, or selecting depth-positioned UI, or pressing according shortcuts.

Finally, the game can end up in irregular interaction or ingame states, for example when the in-game time is paused, or when the player has lost or won the game. In both cases, different in-game actions are still possible (camera movement), but maybe no in-game interaction is available anymore.

Leave a Reply

Your e-mail address will not be published. Required fields are marked *