Is it possible to change the object list to display a plural if there are several of the same type of items present? The scenario is a box of matches. There is a box containing, say, 5 matches. Each match needs to be a predefined separate object, I think (unless there is a way of making duplicate objects at runtime, ie each time you take a match out of the box). I can deal with getting matches out of the box but I don’t want to see ‘you are carrying’ / ’ you can see a match, a match, a match, a match, a match’ when they are outside the box. Instead, I just need to see ‘some matches’. I can switch in an object called ‘some matches’ when there is more than one, but then there are complications tracking how many matches were there in the first place… Am I overlooking some easy way of doing this, or is it as complicated as it seems (in which case, I’ll just give up and allow our hero a lighter instead)?
Can’t you keep track of the number of matches by setting an integer?
I can, but the that’s not really the issue. Say I drop two matches in room 1 and three matches in room 2. I don’t want to see ‘you can see a match, a match, a match’ in room 2 and ‘you can see a match, a match’ in room 1, but ‘you can see some matches’ if there is more than one match in the room (or in my inventory). The only way I can think of doing that in Adventuron is by swapping in an object called ‘some matches’ if there is more than one match in a location. But then when I’ve done that and destroyed my dropped matches and replaced them with ‘some matches’ how do I know how many matches are in ‘some matches’ in a particular room? I need something like 'if is present more than one of a thing belonging to the category of matches, say ‘some matches’, else say ‘a match’. I suppose I could have an integer for every location in the game, just in case some matches are there (diningroom_matchcounter; livingroom_matchcounter etc) but that feels a bit heavy handed.
Ah, I see what you mean. Would it be preferable to say e.g. ‘you see two matches’? Depending on how many matches are in the box, it might be easier to keep swapping multiple objects (‘a match’, ‘two matches’ etc.) than using an integer for each room, which would be tedious as you say.
I don’t think it’s possible to display an integer variable as part of an object name, unfortunately! Unless I’ve missed something in the cookbook again…
There are ways of doing it; for example, as you’ve said swapping “a match” and multiple instances of “some matches” objects… I did a similar thing with multiple “treasure” objects in the past.
But I really have to say that unless it’s a vital aspect of a puzzle, to be able to drop and isolate each match individually, then it seems an incredibly tedious things to simulate; not really the type of thing that Adventuron is designed to do.
You wouldn’t need a “match counter” for every room, anyway. Just for each distinct possible pile. With five matches, there could only ever be two piles of matches.
Well, it’s not really a vital part of a puzzle (or I’ll just make it so it isn’t; I’m just making this stuff up as I go along, you know), so I can work around it rather than spending ages trying to simulate something rather trivial.
As for it being something Adventuron isn’t designed to do - maybe it should. I’d have thought that the box of matches is quite a common object in adventure games. I didn’t have any sources of ignition in Soviet Ladybirds but now I need one and matches are most appropriate for the task. This is one of those things where reality turns out more complex than it seems (it’s a bit like that, reality). I wonder how other systems would handle it?
As it is, you’re right - I can just have a couple of piles and keep count of them. Or have objects called ‘2 matches’, ‘3 matches’ etc. Or constrain it so you can only hold one at time and you’re not allowed to drop an unburnt match, and then have the burnt match disappear when it is dropped. I’ll figure it out if I can’t have some sort of dynamic ‘you see X matches’ object listing thing.
Yes, boxes of matches are quite common in old 8-bit text adventures; what is also common is to either restrict the removal of more than one match (until the first one is removed) or have the box of matches regarded as a single object; removing and using a match where it becomes necessary and having a counter attached to show how many matches/uses are left.
Remember that Adventuron is designed for making old-school style text adventures. It’s not designed to make detailed simulations.
Yes, I know, having wrangled with the thing already (Adventuron, that is). And I enjoy its constraints. But there are instances like this were something needs to be just realistic enough for the player not to notice anything incongruous. Detailed simulation is not required, just enough to align with the player’s automatic presumptions about how such a thing should behave. I could just give the chap a lighter (it’s 1928, it’s not improbable for him to have one) but, damn it, I want that flickering match.
I’ll muck around with it and come up with the most acceptable fudge. Thanks for your input!
This is a universal problem and it’s not unique to Adventuron. If it’s essential to have multiple instances of the same object for a puzzle (such as a Hansel and Gretel breadcrumb puzzle), I’d suggest limiting it to one instance of an object in your inventory and one instance of the same object per room. This is easy enough to check.
If it’s not essential to have multiple instances of the same object, I’d suggest only allowing one instance in play at a time. In this way, you can have a matchbox that keeps a count of how many matches it has, but you can only have one match out of the matchbox at any time.
I did something similar to this recently in ‘Charlie the Chimp’. There was an unlimited supply of bananas, but Charlie was only allowed to have one banana in play at any time. The zookeeper ensured this. When a banana was destroyed by being eaten or put in a container, then you could get another one. Similarly, you were only allowed to have one banana peel in play at any time. The first banana peel was kept and subsequent banana peels were thrown away.
Yep, if you can’t come up with a convincing in-game explanation for a restriction of a game engine then you’re not trying hard enough. 
There’s usually some better way to code things… for example… You could code breadcrumbs with multiple copies of a breadcrumb object but you’d probably be better off doing it with per room off/on booleans/flags.
I wouldn’t personally feel that allowing a player to remove matches from a box one by one and then drop them whenever they liked adds to the realism… Your player character doesn’t have to do stupid things when asked.
If things behave the way they should behave, what’s the point? Better to do something else.
(Just kidding)
Having played ‘Over Here!’, your response doesn’t surprise me!
I guess it just bugs me a bit having an exception here, when you can merrily pick up and drop everything else in the game without restriction. It’s not a big deal, just food for thought - and if it’s a universal thing, then fine. I will manipulate reality as required!
Christopher …
In the beta version ( adventuron.io/beta ) you can collate inventory items using the following (experimental) code.
For something to be collatable, in the English language version of Adventuron, the object description must start with "a " or "an " or "the " and there must be two or more objects present in the set when listing (such as in an inventory) or looking inside an object.
Not demonstrated here but you can also specify experimental_auto_group_singular_objects=“true”" in the look_inside command (which I assume you are using).
I can’t guarantee it will work well (experimental), or as you expect, but give it a try and let me know how it goes.
start_at = lakeside
locations {
lakeside : location "You are by the side of a lake.";
forest : location "You are in a forest." ;
outside_castle : location "You are outside the castle." ;
castle : location "You are inside the castle." ;
}
connections {
from, direction, to = [
lakeside, north, outside_castle,
outside_castle, north, castle,
lakeside, east, forest,
]
}
objects {
coin : object "a coin" at = "lakeside" ;
coin_2 : object "a coin" at = "outside_castle" ;
oats : object "a box of oats" at = "lakeside" ;
oats_2 : object "a box of oats" at = "lakeside" ;
}
themes {
my_theme : theme {
lister_inventory {
list_type = verbose
experimental_auto_group_singular_objects = true
}
}
}
Thanks Chris. I knew if I hung around on this mountain for long enough then the Adventuron Gods would bestow code.
This works to an extent, but for it to work fully I’d need to be able to specify the suffix for the plural (it gives ‘matchs’ instead of ‘matches’) and also GET and DROP [group] eg ‘get matches’ rather than picking them up one by one via the disambiguation menu. And also have the collated object in the object list as well as the inventory.
But I’m OK with a workaround for my matchbox, so this is to consider for future development (unless those tweaks are easy to implement… I haven’t a clue).
The pluralisation code sits atop of the existing auto pluralisation code. The word ending in “ch” appears to be be an edge case in that code, so I’ll bolster it.
I was aware of the disambiguation issue which is a larger problem to solve. The longer term solution is to allow the definition of an object group explicitly and to be able to use that object group in various commands. Such as create destroy carried, etc.
The experimental attribute is a step forward but not the end step.
I will sort out ch and cherry pick some disambiguation fixes but it will remain an experimental setting until groups are a first class concern.
Fine, thanks, I’ll manage. Good to know that the group things is there, amongst the many hidden functions of Adventuron. My epic match-based escape room adventure (you’re naked in a locked box with a huge stack of matches that you can only take in multiples of three, etc) will just have to wait to be written - and then everyone will see why this is such a huge an important issue for me.