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.

Basic Resources

The first set of resources that every robot group will need to think about (next to Strawberries, of course) are Oxygen, Iron, Silicon, Aluminium.

Oxygen is a very reactive element, but luckily readily available in the surrounding air. It can thus be harvested by a specific filtering machine, which converts the surrounding air into oxygen-deprived, surrounding air. As can be guessed, nearby humans don’t take to kindly to this, being so overly prone to suffocating. Due to its highly reactive nature, oxygen improves most chemical operations (e.g. furnaces), and works well an agent for steam-powered engines.

Iron can of course be harvested from old cars: Coneviently collected on long, thin stretches of asphalt, cars can be identified by the characteristic colour of rust. Cut down by Robots, they are processed on to smelting or pressing factories to produce useful iron blocks, from which then all kinds of factories, support structures or the like can be built.

Silicon is the main building block for robot intelligence. It occurs in huge amounts bound with oxygen as common sand, usually made up out of quartz crystals. Diligent robots thus only need to collect sand, carry it to a huge furnace, and melt it down. Bonus: Advanced furnaces can also harvest the separated oxygen!

Aluminium is the simplest luxury material: It is not strictly required, but eases a lot of processes. Due to its light weight, it can substitute iron in many movable parts, for example for hulls and covers. If used in the construction of factories, it increases productivity. If robots are partly made out of aluminium, they move faster and can carry more weight. Furthermore, transportation canisters are made out of aluminium, enabling the construction of refueling stations further apart from the main factories. Aluminium can be harvested from nearly any rock: It is part of many common mineral compounds, although at the relatively low quota of 8%. An aluminium factory thus produces only little amounts of aluminium, along with about 11 times as much waste, which humans consider to be a major fun deterrent.

These basic resources form the basis for all simple robots and factories. When robots establish the supply of Strawberries, oxygen, iron and silicon (and maybe aluminium), anything is possible!