Non-interactive machines were first discussed in the context of the object placement algorithm of the previous post. But there is plenty more to cover.
We can’t simply pick random machines for any and all maps. The types of machines on a given map should reflect the theme of that map, be it storage, factory, research, etc.
Our goal in developing a selection system is to minimize effort while maximizing both variety and logicality of a map’s content. It would be a lot of work to list every possible machine for every map type. The better solution categorizes machines by their “theme” (e.g. mining, matter, energy, processing…). Then each type of map can designate one or more “machine themes” from which to choose its machines.
Mines, for example, pick from the “mining” and “matter” themes; factories select “matter,” “energy,” and “production” machines. This enables maps with overlapping themes to draw from overlapping pools of machines. The selection pool is weighted, so machines themselves can also specify how common they are (with a separate frequency value for each placement location: room, hall, and junction).
Although dubbed “non-interactive,” these machines actually serve as more than just a way to flesh out the atmosphere.
Their very presence breaks up large spaces with destructible obstacles. However, depending on the size of the machine this may only be a physical barrier rather than a visual one, because machines only partially obscure FOV.
Even more deadly (and fun!), is that some machines may explode.
For all the ASCII debris fans, even non-explosive machines send out flying debris when a piece is destroyed.
Some machines may send out different colors reflecting their nature/use, such as this Matter Pump.
Interactive machines do not explode, but their debris animation can also be a little different, such as sparking from a terminal.
Truly explosive machines will detonate in glorious ASCII-plosions that can engulf nearby machines or robots. As with all particle effects, there are many styles:
(More shots from the sandbox, because I’m not hunting through the game to find these things.)
There are more, but I’ll leave them for you to discover in game, hopefully when an enemy hits one you’re standing next to ;)
To prevent overuse of the boring (and overpowered) strategy of “lure enemies near a machine and blow it up,” the predictability of explosions for some machines will be reduced by introducing a system of “machine instability.” When a machine takes damage it may have a random machine-dependent chance to become unstable, which starts an invisible timer after which it will automatically explode on some later turn.
The only element of this I’m not sure about is whether the player should have cues to indicate that a particular machine has become unstable and may explode at any time. Since the time remaining before explosion is still uncertain, it makes sense to tell the player at least when there are signs of instability. In any case, the implementation will depend on playtesting, as well as the precise number and frequency of machines that explode (these parameters haven’t been added to the data yet).
With powerful enough weapons you can of course cause a machine to explode instantly, but machines prone to deadly explosions are generally more heavily protected against weapons as this is not exactly the safest of environments.
Melee weapons, however, are particularly good at hacking up machines, though for obvious reasons point blank attacks on explosive machines are rarely a good idea. On a related note, recall that knock-backs are possible with impact-type melee weapons, thus as a new extension of that mechanic, you can now smash robots into a machine.
Normal machines will simply shoot debris from the point of impact (and coincidentally make some pretty cool metal crunching sounds). Explosive machines on the other hand will probably roast whatever robot is so unlucky as to be smashed into ground zero, and probably engulf those nearby, too.
Be wary of enemy brawlers that may unwittingly do this to you!