Robot Factory - Devlog 004

Benedictiones motūs perpetui omnibus!

In this recent update, things finally come together when it comes to selecting and moving units. There are no new units, buildings, or enemies this time around, but it is finally possible to select and move every unit in the game — Collectors, turrets, the camera-drone, and even Connectors can now be mobilized and repositioned.

In addition, multiselection (via box-select or shift-clicking) and movement-queueing have also been implemented. This was a bit tricky to pull off, as each unit in the game has different functionality, and some constraints were necessary to keep the logic coherent:

Connectors: Connectors can’t be multi-selected or movement-queued, as their movement is based on redeployment rather than direct navigation. So, they can only be solo-selected and redeployed (using the green grid marker) elsewhere. This adds a new level of control and planning to the power system and grid, as it can now be dynamically changed instead of remaining static.

Collectors: Since collectors are designed to automatically travel and gather resources, manually moving them around is essentially an override of their default behavior. They will follow your movement command, and once they reach their assigned destination, they’ll return to collection duties.

Collectors can also be redirected to collect a different resource-unit than the one they initially targeted — but only if they haven’t picked up a resource yet. If they’ve already picked one up, they will still travel to the new resource location but retain their current load.

To prevent two collectors from targeting the same resource unit, I modified the collectors' “job manager” to handle task reassignments from a macro perspective, considering all active collection duties before assigning or reassigning any tasks. I also added a visual cue to the newly selected resource.

Turrets: Turret-robots can be group-moved and queue-moved like regular units, but deploying them overrides other queued movements. Also, in order to deploy a turret, it must be selected individually.

System Changes: Combining group-movement with movement-queueing required some rewrites of the previous movement system, where inputs were handled inside each unit’s class. Proper group-movement requires offsetting destination coordinates for each unit (to avoid clumping), and with each unit previously handling its own input, coordinating multiple destinations became messy. Centralizing the input system — having a single system register, adjust, and assign inputs — made the whole process more robust and manageable.

Additional Thoughts: Although this on-the-fly workflow of changing systems may not be the most organized, it allows me to work flexibly and intuitively. It’s even quite fun — when it’s not too painful. I’m not sure I’d recommend it to a larger team, but for solo development, it works.

As always, feedback and critique are welcome — especially now that there are quite a few UX questions around selection and control of different unit types.

As a first step toward improving usability, I’ve changed the mouse button layout for building operations:

• Left mouse button: used for all UI interactions and selections
• Right mouse button: used for commands, deploying buildings, and moving units

Visual improvements are probably next on the list — the systems are getting there, and now it's time they look the part too.

— Zach