Solids: Collections
Some objects are sets or collections of other objects. You might have a bunch of flowers, a pack of cards, or a wad of notes. Using a principle of no-disassembly, these should be unitary items. They all have problems with this, though.
A bunch of flowers is fine as long as you have no individual flowers anywhere. Put in a single rose, and suddenly you’re accepting the concept of unbunched flowers. Players will therefore want to take flowers out of the bunch.
A pack of cards only exists when no one is playing a game with it. Because cards are meant to be played with, you can hardly blame people for wanting to deal out the pack. When that happens, suddenly there are 52 individual cards (plus jokers) and no pack. You only get a pack again when someone collects all the cards.
A wad of notes has critical value. Although you might want to allow players to pick up pebbles from a beach arbitrarily, you can’t let them peel notes from a wad in that way or they’ll be rich in no time. However, if you make each note in the wad an individual object, how do you refer to the wad? Can you split it in two and get two wads?
These problems arise because although players will think of objects at a particular level a lot of the time, for similar objects (in particular) they like to stack them together and treat them as an abstract whole. Designers must decide whether to allow non-functional assemblies like this, and, if so, how to handle them.
There are two ways, alluded to in the preceding paragraphs. The first is to enumerate all the objects that make up a collection, but report them as a collection based on the number held. If you have three playing cards in your inventory, they’re shown separately; if you hold seven, they’re shown as a “hand;” if you hold 52 (plus jokers) they’re shown as a “pack.” Similarly, if you have a rose and a tulip, you have a rose and a tulip; if you have a rose, a tulip, and a daffodil, you have a “bunch of flowers.” The designer lays down the criteria for when individuals become (or cease to become) a collection.
The second way is to use a generator. There are so many flowers in the garden or nuts on the tree or locusts in the swarm that it’s pointless enumerating them. If a player wants one, they can have one. There is effectively an infinite number. For these collections, a dispenser function creates a new instance each time the collection is taken from; when an instance returns (or collections merge) the incoming items are deleted and the collection remains as it was 1. If a graphical world has a beach texture-mapped with pebbles, characters can pick them up this way. The texture map doesn’t change, but the characters get an object they didn’t have before.
Collections are used as shorthand for quantities of objects. It’s possible (but not essential) to give them properties beyond what the individual objects have—for example, giving a set of collectible bubble gum cards a greater value than sum of the values of each individual card. Oh, and yes, every other designer in the world has thought of making collections of too many uranium chips invoke an atomic explosion.
Note that one false move by the programmers here and you get the duping bugs that are the bane of so many virtual worlds. ↩︎