A "collective group" object. This is an abstract object: the player doesn't think of this as a physically separate object, but rather as a collection of a bunch of individual objects. For example, if you had a group of floor-number buttons in an elevator, you might create a CollectiveGroup to represent the buttons as a collection - from the player's perspective, there's not a separate physical object called "the buttons," but it might nonetheless be handy to refer to "the buttons" collectively as a single entity in commands. CollectiveGroup is designed for such situations.

There are two ways to use CollectiveGroup: as a non-physical, non-simulation object whose only purpose is to field a few specific commands; or as a physical simulation object that shows up separately as an object in its own right.

First: you can use a CollectiveGroup as a non-physical object, which essentially means it has a nil 'location'. The group object doesn't actually appear in any location. Instead, it'll be brought into the sensory system automatically by its individuals, and it'll have the same effective sensory status as the most visible/audible/etc of its individuals. This choice is appropriate when the individuals are mobile, so they might be scattered around the game map, hence the group object might need to be invoked anywhere. With this option, you normally won't want to make the CollectiveGroup handle very many commands, because you'll have to completely customize each command you want it to handle, in order to properly account for the possible scattering of the individuals. For example, if you want the group object to handle the TAKE command, you'll have to figure out which individuals are in reach, and specially program the procedure for taking each of the available individuals.

Second: you can use CollectiveGroup as a simulation object, and actually set its 'location' to the location of its individuals. The group object in this case shows up in the simulation alongside its individuals. This is a good choice if the individuals are fixed in place, all in one place, because you can simply put the group object in the same location as the individuals without worrying that the individuals will move around the game later on. This is much easier to handle than the first case above, mostly because commands that physically manipulate the individuals (such as TAKE) aren't a factor. In this set-up, you can easily let the group object handle many actions, since it won't have to do much apart from showing the default failure messages that a Fixed would generate in any other situation. Note that if you use this approach, the CollectiveGroup should *also* inherit from Fixture or the like, so that the group object is fixed in place just like its corresponding individuals.

The parser will substitute a CollectiveGroup object for its individuals when (1) any of the individuals are in scope, (2) the CollectiveGroup has vocabulary that matches a noun phrase in the player's input, and (3) the conditions for substitution, defined by isCollectiveQuant and isCollectiveAction, are met.

(The substitution itself is handled in two steps. First, an individual will add the group object to the sense connection list whenever the individual is in the connection list, which will bring the object into scope, so the parser will be able to match the vocabulary from the group object any time an individual is in scope. Once the group object is matched, its filterResolveList method will throw out either the group object or all of the individuals, depending on whether or not the isCollectiveQuant and isCollectiveAction tests are met.)

For example, we might have a bunch of coins and paper bills in a game, and give them all a plural word 'money'. We then also create a collective group object with plural word 'money'. We set the collectiveGroup property of each coin and bill object to refer to the collective group object. Whenever the player uses 'money' in a command, the individual coins and bills will initially match, and the group object will also match. The group object will then either throw itself out, keeping only the individuals, or will throw out the individuals. If the group object decides to field the command, it will be the only matching object, so a command like "examine money" will be directed to the single collective group object, rather than directed to the matching individuals one at a time. This allows the game to present simpler, more elegant responses to commands on the individuals as a group.

By default, the only action we handle is Examine. Each instance must provide a suitable description so that when the collective is examined, we describe the group of individuals appropriately.

class CollectiveGroup :   Thing