Designing and building units is a core mechanic of Triverse, so it needs to be streamlined and fun. Among games in general, there are two basic ways to implement player building controls:

• Immediate: This way is akin to direct actions, where the player immediately builds or digs blocks by sending actions directly to the simulation. Games like Captain Forever, Terraria, and Minecraft make this a core mechanic. This approach is simple, but it can be tedious for larger construction projects and requires an actual inventory on hand to build. Often the player carries a zero-weight inventory around for convenience.
• Deferred: This way is similar to orders, where the player draws plans and allows the AI to choose actions that fulfill the plans. Games like Dwarf Fortress and colony/simulation games allow planning like this. This way has more complexity in the form of bookkeeping and systems, but it allows the player to efficiently plan ahead without needing an inventory present. Often the inventory takes the form of resources that must be physically moved around.

Triverse implements the second approach, allowing players to place plans on a global grid associated with their AI agent. The AI then steers units toward plans, and when a core is near enough, it warps in a part if available. Steering generally works well for open areas and convex objects, but terrain and concave interior areas sometimes require more advanced pathfinding.

Similar to the first approach, cores can collect and withdraw parts to and from an omnipresent inventory which occupies no physical space. It might be an unbalancing hack, but for now it’s simple and convenient, so it wins until more playtesting proves otherwise.

Complications

Then there’s the question of what to build on – is the player always additively building on a global grid, or can the player make modifications to a particular grid which is already built? Regarding UI and usability, we want any potential build sites to remain in a constant position relative to the player view. Otherwise, the player has to hit a moving target and may inadvertantly build in the wrong place. In other games, this is less of a concern because building is either always on static terrain or it’s on a player-controlled object. In Triverse, grids can move independently, so we need to consider ways to lock them down or limit building:

• Pause in build mode: As essentially a global lock on movement, pausing is certainly effective but often unnecessary if the player is drawing a predefined blueprint rather than editing existing plans. Requiring pause also limits multiplayer gameplay.
• Park selected units: This way introduces an interlock mechanism to only allow building on existing units if they are in a parked state. When the player switches to build mode with units selected, those units will automatically park, then unpark when the player switches back. This way requires some coupling of selection state with plans and orders, but it solves many of the usability problems.

There’s also the issue of starting to place plans and having units swarm to build them before completing the design, but players can always draw plans away from their existing units and then move the plan closer or direct units to it when ready.