Entity consumption by commands

[Karl Ostmo]

This proposal is to have a general mechanism to specify a cost, in the consumption of entities, for executing certain commands.

In the scenario .yaml file, an entity (specifically, a "device") may specify how many entities are consumed by the exercise of any of that device's capabilities (by way of executing a command). Whereas currently capabilities are a list, they now becomes a map with the capability name as a key and an entity (to be consumed) as the value. We may choose to implement .yaml parsing that retains backwards-compatibility of capabilities specified as a list.

Aside: Alternatively, instead of a single entity as the map value, it could be an ingredients list. However, for whatever command cost that consists of multiple ingredients, it would be equivalent to just define a recipe that outputs a single entity to be consumed, with the multiple ingredients as an input to that recipe.

In the game, we first check whether a capability-providing device has the requisite entity inputs before it may invoke the command provided by that capability. An entity shall be consumed regardless of the success/failure of the command itself.

If cost-free alternative devices exist to execute a given command, they are preferred. Two devices that both have a cost are chosen based on their relative order in the scenario file.

Examples

• The ignite command may be enabled by a Zippo device, which consumes [1, lighter fluid].
• The move command may be enabled by a rocket device, which consumes [1, propellant].
• The detect command may be enabled by a blacklight device, which consumes [1, lumninol].

Related

This may supersede/generalize #550, though "side-effects" like spilling water as a result of the move command would have to be specified on a per-effected-entity basis (as a map from command to quantity lost), as opposed to per-device as this proposal describes.

[Brent Yorgey]

I am a big fan of this idea! It definitely feels like a much nicer, more general way to solve #550 .

We may choose to implement .yaml parsing that retains backwards-compatibility of capabilities specified as a list.

I would think that is a requirement. I don't want to have to edit every single entity description in entities.yaml as well as every scenario that defines custom entities just to turn the capability lists into maps with null values.

We will also have to think about requirements analysis. Suppose we are building a robot, and its calls move, but the only device available which provides a move capability is a rocket, which consumes 1 propellant. Should we also require some appropriate amount of propellant to be installed on the robot along with the rocket? I would say no, for two reasons:

1. It is actually impossible in general to statically analyze how much of some consumable resource will be needed. In some simple cases you can (e.g. if the program just consists of move; turn left; move, clearly we will need 2 propellant) but as soon as there are conditional statements, recursion, etc. it quickly becomes literally undecidable how much propellant will be needed.
2. It makes sense to me that in any scenario with devices that consume entities, part of the whole point is that you will have to manually manage those entities. So for example you could write build {require 100 "propellant"; move; move; ...}.

[Karl Ostmo]

2. part of the whole point is that you will have to manually manage those entities

Yes, and they might not all be provided at build time, e.g. you'll provide just enough initial propellant to navigate to a cache for refueling.