My question is, how would you all deal with this situation? Or, as a player, how would you like the situation to be handled?
The situation: you have a collection of similar objects, from which the player can be expected to select an individual. The key is that we’re trying to code this as a single object, not a class of dispensable equivalents. If they try to take a second one right away, it seems very plausible to say “You’ve got enough generic object for your needs.” But what if the player took the object to the other side of the map, and dropped it? And then came back later, and suddenly thought of a reason why they’d like to snag another object from the collection to try out on something? Do you force them to go all the way back to where they left the other specimen, because it’s still in play in the game world? Do you let them select an additional specimen like normal, but move the code object from its other-side-of-the-map location into the player’s inventory? (Depending on where the object was left, its disappearance could be very conspicuous on the next visit.) Do you have any other good solutions?
The idea is that there many situations where I’d like for the player to be able to reacquire an object if necessary, but want there to be only one code object to represent it, as it would be very undesirable both on the playing end and the coding end to make a class of dispensable equivalents that each need to track their own properties and state changes (and there is no need for more than one to be in play at a time).
I have certain objects behaving one way, and certain another, but I’m not sure I’m happy with my current setup. Thanks for any input!
As a player, this is a big pet peeve about interactive fiction tools as opposed to MUDs, which generally handle identical objects just fine. I think the tools should just make it easy for there to be multiple pennies or soda cans or whatever.
(I know that’s not helpful for your situation, sorry…)
There are plenty of situations where dispensing potentially unlimited equivalents is no problem, but there are subtler scenarios where that’s not a desirable option…
Do you force them to go all the way back to where they left the other specimen, because it’s still in play in the game world?
Yes. Least bad alternative.
(If you can say “You left it in the Narrow Crawl”, that’s a nice amenity. Depends on having a fairly static game, though. If the Thief can move things around, the player may well be screwed.)
Mostly my attitude is “avoid this situation in your parser-based game”. Make the vending machine visibly broken, so it only dispenses one thing. Or don’t let the player carry the dispensed material all over the map. Have it evaporate when taken out of the room. Something.
I think the tools should just make it easy for there to be multiple pennies or soda cans or whatever.
Saying that you want it to be easy does not make it easy. :)
Even if your IF tool theoretically allowed an unlimited number of dispensed objects, you have to think about how the game should respond if the player just sits there and says “PUSH BUTTON” over and over. Does the game eventually break? Run out of memory? Does the room-description routine get laggy?
If your answer is “Okay, I’ll cut the player off at ten copies” (or twenty, or whatever number) then you do not have an unlimited number of dispensed objects. You have ten. You’ve still decided to have a limit and a failure message for trying to pass the limit.
Then you have to ask whether ten is a better limit than two, or one.
Well, no, I do understand that it’s one of those things that tends to be a major pain to implement in an existing system, even though it’s not too bad if you design for it initially. And as you say, authors can often just avoid the situation. But as a player, having played games that support identical items and games that don’t, I much prefer the ones that do support it when the situation calls for it. And I do generally think that ten is a much better limit than one, yeah (again, as a player).
My two cents, YMMV, etc. But for me it has always been a significant pet peeve about IF.
I think you’re writing in TADS, so creating lots of objects isn’t the problem. It’s disambiguation issues that come with several or tens of identical items in scope, that’s the design & coding problem you’re signing up for. Now you have to start thinking about how the player will manage and refer to multiple items in the same location; how to refer to items in a location while carrying identical items in inventory; inventory depth (items carried by the player vs. items in a container carried by the player); whether more than one (or, say, five) of these items on the ground suddenly become a pile; etc.
Some players might like that kind of game. I don’t think managing inventory or answering lots of disambiguation questions is enjoyable. That’s my take.
I agree with @zarf I think: better to prevent the problems arising in the first place by contriving a reason why the player can only have one of the things. Maybe prevent it being taken out of particular region so there’s not too much frustrating hunting for it if it’s dropped and then needed later on. A similar kind of design philosophy to taking objects out of play or closing off areas when they’re not needed any more. Degrades realism but often avoids a load of other problems.
Adding my voice to the chorus here. There’s probably no ideal way to handle this, and the traditional one-at-a-time way has the advantage of being relatively easy to implement, as well as being relatively common so many players will know how the system behaves when they encounter it. That familiarity will reduce friction, and also mean that players will probably spend less time kicking the tires on the implementation to figure out what will and won’t work – and inevitably finding bugs.
(I might just have PTSD from the climactic puzzle from my first game, which involved multiple identical objects being moved about and altered in a single room – after a ton of time testing and refining it it still doesn’t work 100%!)
For my game, it was dry grass gathered from a field. I took the path of removing the object when dropped anywhere (something like ‘the grass blows away in the wind’). So if you can reasonably dispense with the item when the player drops it (or it otherwise leaves the player’s inventory), that can also work.
Thanks folks, for the input. It kind of sounds like I’ve already visited the possibilities.
@jnelson , yes, disambiguation is a big reason why I don’t want more than one object in play at a time when there’s no conceivable need for two or more.
@zarf and @ChristopherMerriner , for certain situations in my game, I can’t seem to realistically get around the “no sense in taking another one when you’ve left one lying around already” approach. Some things it doesn’t make any sense (or help all that much) to restrict where the player takes them; and the situation is not so much of an actual dispenser or a vending machine, but simply a plausible way to get a second one of something if the player loses or destroys the first one. I don’t even have to make my objects in question come from a renewable source, but I’d rather let the player have more freedom to play around with their inventory objects (and not be permanently stuck), instead of saying “You can’t win the game without that, so we’re not going to let you do anything with it except solve its respective puzzle.” (And I do have the “you last saw it [at the x]” amenity. )
@DeusIrae , I know what you mean, exactly the kind of situation I want to avoid when there is no game-purposeful reason to have multiples of a certain object in play at the same time. I guess this is one situation where you have to be content to invoke the old “It’s a game, not a simulation”. Realistically, of course, it’s idiotic to think that your player character should have to travel a hundred miles to where they last left their piece of birthday cake instead of taking another piece from the dish. But alas.
To anyone interested, or finding themselves in a similar situation, I have dealt with object pluralities in no less than five ways in the same game:
- I have some objects of which (annoying as it is) you cannot take a second instance while the first one is still reachable in the game world (but you’re allowed to take another one if the first one gets destroyed or lost forever). Coded as a single object.
- Also coded as a single object, some objects of which you can take a second instance, provided the first one is neither in sight nor in any neighboring map location. In this class the code object simply disappears from its present location and moves into your inventory (although of course the takeMsg doesn’t indicate that). The rationale is that these are typically objects that you might suppose to blow away, get thrown away by someone after you’ve left the area, etc. (My map is mostly travel-based as opposed to room-to-room, so that helps.)
- Coded as a class of equivalent objects: the typical Dispensable class, where you can pick fruit from a tree or whatever. If they have, say, ten in their inventory they get a “you don’t need to spend the rest of your life picking fruit” message. (And if they go to another location, drop all of the fruit, and go back to pick more, there’s also a cutoff for how many instances can be in the game world at any one time.)
- Coded as a class: a kind of “mass” object (vs. a distinct count of individuals, e.g. sand, dead leaves…), where you can take more all day long, but the game isn’t specific about how much you have. Let’s say you have a quantity of dead leaves in your possession: you can take more from the source, but it will simply say “You take more leaves” without adding a new object to your code inventory list. If you put your leaves on the table, your Leaves object moves to the table. If you take more leaves from the source, a new Leaves object moves into the player. Then, if you put this second wad onto the table, it simply tells you that you add them to the other leaves, and zaps one of the code objects, so that there is never more than one Leaves object in any code location, whether it be player inventory, room contents, or a surface or container.
- In one instance (probably still buggier than I realize) I attempted to use single code objects to represent a group of identical objects in a specific spot. The difference here is that these groups have a number of individuals that they represent, which can be added to and taken from. That involved some weird parser gymnastics and I have yet to see that area well-tested.
- I don’t know if it would be considered a sixth way or not, but I have also made use of the following method: an item, once initially discovered, is listed in the room description. If you take it, the room will no longer betray that there’s anything else similar to take. But if you go your ways and lose the thing, when you return, you discover that there’s a similar thing there “that you didn’t notice before”, or perhaps that had a natural way of recurring since your last visit (single code object again).
The way I did it (I was building from scratch in JavaScript) is to have a single object, but set it up so it appears to be multiple items that can be in various places.
Disambiguation is avoided - it is just one object. Clearly an infinite number of the things is not allowed, but as it just counts the number in each location the highest number it can safely deal with is 9007199254740991, and even after that it just gets unreliable, rather than breaking.
The player can use commands like GET TEN ARROWS, etc. so can move them around quite naturally.
Cool. I’m intrigued as to how that works as one code object, requiring no disambiguation. Let’s say the single code object has a location list of room1, and table within the room. What happens when the player walks in the room and says ‘take arrow’? Does the parser ask for clarification? Or what if they pour water or tar, or tear the fletchings off of one group of arrows but not another? Genuinely curious, since I’ve had to ask myself all these questions…
I have it just take the arrow from the room, not the table. If you want the arrows on the table do TAKE BRICKS FROM TABLE (or if only arrows on the table, TAKE ARROWS will work). This gives the player full control of where to take arrows from.
Here is a transcript to illustrate.
> i
You are carrying seven bricks and a knife.
> put 3 bricks on table
Done.
> drop 2 bricks
You drop two bricks.
> l
The kitchen
...
You can see a big kitchen table (with three bricks and a jug on it) and two bricks here.
> get bricks
You take two bricks.
> get bricks
You take three bricks.
> drop 4 bricks
You drop four bricks.
> put one brick on table
Done.
> take brick from table
Done.
With regards to making them have state, I have not addressed that because I have not needed to. I guess I would maintain two lists of locations in the object, one of full pots and one of empty pots. For the parser I might set up a new command that includes an adjective.
And now I’m going to have to try to implement it…
This is the route I’m taking in my current project; my pile of dispensable objects is actually just one object which gets teleported to the player’s inventory when they grab another one. I handle the disappearance of the “old” object by printing a message saying that a janitor has come and swept away that object you left in the other room.
A message like that is out-of-world (i.e. it’s not something the player character would actually know), but I think it’s worth it to avoid the confusion of the player wondering where they left the old version of the object. I also have some leeway with this, since I’m making a comedy game that lets me get away with a little surrealism; if I was making a more atmospheric game, I’d have to think much harder about how to phrase a message like that.
I don’t know if you read my succeeding post, but I did in fact code a few objects like that in my game. The particular objects are pretty generic and they only disappear if you have to travel distance to reach another location so I don’t think I’m going to even use a “here’s why the thing disappeared” message…
Is that what we’re calling those now?