Design question: many identical objects

I have a design question about the situation where we have many identical objects that can be individually manipulated by the story player.

For sake of the discussion, let’s assume we have a crate with 500 pebbles. The player may take a pebble from the crate, carry it with him, write on it with a pen, drop it somewhere, etc. We don’t know beforehand how many pebbles he will take, it could be 0, 1, 10, whatever, and what he will do with them. Modeling 500 separate pebble objects seems not like a feasible approach.

Without refering to a particular authoring system, what are in general good ways to model this? Should the authoring system have facilities for dynamic object creation (during playtime). Whenever the player wants to take a pebble from the crate, create a new pebble object? This would require specific functionality in the authoring system.
Or could it be modeled using one ‘500-pebbles’ object with a counter and a list of locations? Or are there yet other ways…

I’m looking for suggestions on how to handle such multiple identical object situations in an authoring system.

Thanks for reading…

Some kind of dynamic object creation would be wanted (the specifics would depend on what the authoring system best allows). Having a single object with a counter would be bound to cause issues if you try leaving it in different locations.

Most authoring systems let you just create a set number of copies of an object and it’ll work relatively well out of the box, although e.g. Inform has a limit of 255 copies.

From game design point of view, it’s extremely rare that you’d actually need that many copies. If the player is required to handle 500 separate units of a thing, it’s very likely that the game isn’t very fun to play. The usual solution is smoke and mirrors: put a large number of pebbles in the crate and describe the amount vaguely (“the crate is full of pebbles”). If the player tries to take more pebbles than there actually are left in the crate, the game refuses (“you already have more than enough”). You can also recycle used or discarded pebbles by moving them back to the crate so that the player doesn’t actually run out.

The other solution is the single-object-with-counter approach, which is usually used to model money, but it doesn’t really work if you have to treat the things as individual objects.

You can do a single-object-with-counter and then spawn new objects to represent subdivisions of that object at the time when the player wants to split the collection. (So “drop pebble” makes a new pebbles-in-location object and decrements the count in the player’s carried pebble. “drop pebble” a second time increments the pebbles-in-location object and decrements the carried pebble object again.) In that case, you know that the maximum number of collective-representation objects you need in your game is the number of containers that are eligible to hold those collectives; this may still be somewhat large, but it’s unlikely to be 500. Some of my liquid simulations do this.

That said, I also agree with the comments that you probably don’t actually want to do this, for the player’s sake. If you’re including the kinds of puzzles that involve manipulating large quantities of a resource, forcing the player to distribute the resource one unit at a time is likely to be reallllly annoying. (In the case of liquid simulation, I may be tracking quantities, but the player is manipulating containers, not individual centiliters of water.) If your puzzle does not involve manipulating large quantities of that resource, and you’re only doing the simulation for the sake of realism, that’s a design decision that’s going to mislead the player about your world model and what it’s actually for. In that case, it’s better to let the player only take a few of the object at a time, depending on how much they’re likely to need.

I fully agree that 500 is way over the top. I merely used this number “to indicate a number of objects large enough to demonstrate the need for another mechanism than coding each individual object in advance”.
As per Joey’s suggestion, I lean towards a dynamic object creation solution as this will also offer the possibility to personalize the objects after creation. E.g. Take some pebbles and use a marker to write numbers on them for mapping a maze - I’m an old school adventurer - or whatever other reason.

I wrote my own authoring system in the 90’s of the previous century, so I’m pretty flexibel in the implementation of the functionality.

I’l keep watching this thread for other suggestions.

Thank you all so far…

Depending on what you need, I had success with modeling 10 pebbles and just not allowing the player to take more, “You don’t think you need any more pebbles…” Then respawn them as they are used.

Alternately, simulate one object “handful of pebbles” and then treat it as infinite just as a gameplay convention…as long as the player has a handful of pebbles she can succeed the DROP PEBBLE IN WELL or THROW PEBBLE AT WINDOW actions indefinitely.

You don’t need to create the objects dynamically to be able to personalize them during the play. There’s no difference in that regard whether they come from a pre-made reserve or if they’re created on spot.

It’s true that the IF conventions for “a handful of objects” evolved to work in systems where creating dozens of identical objects was impractical. But it’s also true that these conventions turn out to be adequate for just about all IF that people want to play.

You can imagine a game that supports dropping five stones in one room, six stones in another room, two stones in another… but any player who did that would be testing the limits of the implementation, not playing the game.

(Anybody get upset when Hadean Lands refused to let you make two identical potions at the same time?)

I agree with zarf. Maybe it’s sort of an academic disussion and certainly not necessary to produce a good playable game.
I am interested in the design of authoring systems and will give it a try. As per the suggestions in this thread I’m thinking about creating a number of identical objects and a master object (invisible to the player) for orchestration purposes.

If you did actually want to implement 500 pebbles at once (for the challenge of it), here’s how I’d actually do it:

I’d have one pebble item that is held by the player when they pick up a pebble. The properties of this pebble would be set in a table. It would have a counter for multiple instances and drawing on pebbles would create new descriptions stored in the table. There would be a table for everywhere you can leave a pebble (each room, and you’re inventory) and moving pebbles would move rows between the tables.

Yes, that’s how I would approach it too, from a programmer’s perspective. But my system is a modeling system, not programming. It “only” has locations and objects that all coexist in the world view. There’s no such thing as “loose” code. The player’s input is presented to all locations and objects and they all decide autonomously whether they act on the input or not. There’s no central point of control in the world. This gives me some nice challenges to model identical objects. E.g. only one pebble object may act on the “take pebble” input. If there are 2 pebbles in the room, the “look” command must print “There are 2 pebbles, here” rather than 2 pebbles replying individually: “There is a pebble, here. There is a pebble, here”. Same with the “inventory” command (each object that concludes it is carried by the player prints a response).
I already got some useful tips from the experts in this thread that will help me model this, which I appreciate a lot.

Thanks for reading…

I would say limit it to carrying a small number of pebbles at a time (eg, 5 or 10 at most) and if the player is likely to need more, let him pick up the box and carry it around. That way he will not need to keep coming back for more and more pebbles.

p.s. In essence this is pretty similar to the “liquid” problem. Liquids are nearly infinitely divisible, which can get way out of hand in a program that treats every object as one thing. Different games have different approaches but the general solution seems to be: don’t let the player divide the liquid, or if he must, don’t let him do it in smaller portions than some arbitrary quantity (eg, 1 oz.)

Well, I gave it a try. I created 5 identical objects (pebbles) and 1 group object for coordination. The happy flow is pretty straightforward but it takes quite some coding to catch and handle the exceptions. I ran the test story, the output is below. I would post the source code, but as it is a proprietary system I don’t believe it will add much.

My conclusion is that it can be done, but for sake of the story experience, the ‘smoke and mirrors’ approach works just as well (handfull of pebbles, you don’t think you need more pebbles, …).

[code]

XVAN interpreter version 2.0

Pebbles version: 1.0

Test story for multiple identical objects

Start room

There is a wooden crate with 3 pebbles here.
There is a cardboard box with 2 pebbles here.

take 2 pebbles
You take 2 pebbles.

look
Start room

There is a wooden crate with a pebble here.
There is a cardboard box with 2 pebbles here.

i
You are carrying:
2 pebbles

get a pebble from the crate
You take the last pebble from the wooden crate.

look
Start room

There is a wooden crate here.
There is a cardboard box with 2 pebbles here.

i
You are carrying:
3 pebbles

take 26 pebbles from the box
There are only 2 pebbles that you can take.

look
Start room

There is a wooden crate here.
There is a cardboard box here.

i
You are carrying:
5 pebbles

drop a pebble
You drop a pebble.

look
Start room

There is a pebble here.
There is a wooden crate here.
There is a cardboard box here.

i
You are carrying:
4 pebbles

put 6 pebbles in the crate
There are only 4 pebbles that you can drop.

look
Start room

There is a pebble here.
There is a wooden crate with 4 pebbles here.
There is a cardboard box here.

i
you are carrying:
Nothing, you are empty-handed

x crate
The crate is just an old wooden crate.
There are 4 pebbles in the wooden crate.

q[/code]

That looks pretty cool! The only proviso I would say, and this is a design choice rather than a flaw in the system, is that when you type “take 26 pebbles” and there are only 2 pebbles, it should refuse to take the 2 pebbles–or at least the message should make clear that you’re actually taking those 2 pebbles.

From an author’s perspective, I would say that I might sometimes want to be able to do something other than the “smoke and mirrors” approach. I sometimes feel straitjacketed when the authoring system makes assumptions about how I want to do things. But, you’re not obliged to cater to me.

What have you implemented your system in?

Hi Matt, changing the tekst is easy, would be something like “You see that there are only 2 pebbles, so you decide to just take 2.”
Not picking up anything when the amount is not there, is a bit more work but I think it can be done. It’s a design choice indeed.

My system is a compiler and an interpreter, written in C. And a modeling language to write the stories in.