Neither have I, and I’ve been using it for years!
2 Likes
In Inform 7, you define a thing, and the inventory is automatic. If your def allows, you can take, drop, or wear the thing, and the inventory is auto updated. >>> I >>> You are carrying a cloak (being worn). Not all languages have what I call “true” objects and things. In other languages, you simulate these items often by using variables, and custom write your own inventory routine. Ones that don’t (please correct me if I am wrong) are Ink, Inklewriter, Squiffy, and ChoiceScript. The shorter list probably will be who has true objects/things with built in inventory.
1 Like
I suspect you’ll find that practically all parser-based engines support picking up and dropping things right out of the box, and practically no choice-based engines do. Parser IF has a long history of being based around object manipulations like this, while choice IF generally hasn’t. (There are plenty of choice games that implement an inventory, but it’s not considered a standard thing.)
5 Likes
That sounds to me like the difference between parser engines and choice-based engines. The former have real objects, and the latter don’t? But I’m no expert!
2 Likes
Every retro adventure system I’ve ever used (including modern takes on retro systems like Adventuron) have had objects that fit that definition then, with the simple built in properties such as “wearable”. Some have more definable properties than others, such as weight, whether they’re containers etc. Still not sure about the whole “truly have objects/things” part of the initial question.
2 Likes
not sure about whole “truly have objects/things” part of the initial question. in choice based and hyper-link type games, one simulates a thing by using variables. There is no built in inventory in Twine for example. You would need to custom write it (or borrow someone else’s). In writing my own engine, I can easily simulate things with variables but having defined objects or things and attaching verbs and inventory to them is not trivial.
.
1 Like
It must be fairly trivial, though, surely? Given how even the most basic of BASIC systems have defined objects in them. But I guess some of the difficulty might be that you’re trying to fuse a Twine style system with a parser-style system?
In many of the old retro text adventure engines, every aspect of the games are defined in tables of data. So objects are just entries in the table and their properties are basically just variables that denote the properties in those tables; the object number, a noun number for the object, an adjective number for the object, a location for the position of the object, the object weight, a true/false as to whether it is wearable.
4 Likes
Right - I guess there’s some metaphysical point between “this isn’t really an object, just a bunch of variables dummied up on an ad him basis to fake one” and “the bunch of variables is now big enough, and their behavior sufficiently consistent, that there’s a real object system” but beyond noting that pretty much all existing parser systems (plus Gruescript and no other choice systems I don’t think?) are on one side of the line it’s hard to suss out where exactly it sits.
3 Likes
the point is the automatic verbs and inventory associations leaves (a lot) less for the author to worry about. This comes into play more when you are designing an engine as I am trying. 
1 Like
So based on answers, parsers are better at “things” and inventory than choice based. Is anyone aware of
a hybrid between the two?
There are also various Inform extensions that can allow it to operate in a choice-based mode- Hybrid Choices by AW Freyr is I think the most popular - and many many Twine games with parser-like world models but I’m not sure whether any have been systematized and made public.
1 Like
Quest 5 and QuestJS both use objects. I do not know about Quest 4, but it has not been supported for well over 10 years.
1 Like
Adventuron (which is parser-based) has a choice system and also an (experimental) gamebook mode. See the “cookbook” for an example of how it is implemented… Adventuron - Cookbook
In terms of what you want to do, I would imagine it would be easier to bake in an inventory/object system (and other parser-related systems) from the start and allow your choice mode to use that, than try and build parser-based systems onto a choice mode framework.
(Just thinking of existing engines…, it is pretty easy to code a choice-based game in a parser-based system… but not easy to code a parser-based game in a choice-based engine; something that your original thread seemed to indicate was the rationale behind wanting to create a new “retro-style” adventure system.)
3 Likes
agreed
Recent systems like Twine were initially designed to create interactive choice based narratives, similar to things like a Choose Your Own Adventure novel, where the end-user selects a choice from a displayed set of them to further progress through the story-line.
In such projects variables are used to track the choices made and the end-user’s progress through the story. They are also used to allow the end-user to supply information like the point-of-view character’s name. The value of the variables can be used to dynamically alter what story content is displayed.
Systems like Twine were later used to also create more RPG like projects that require functionality like: Character Stats; Locations; Usable Items; Inventory; Shops; Quests; Events; etc… all of which can generally be implemented by any system than allows Object based data-types to be stored in its variables.
One common issue with much of the above listed RPG like functionality is that there is no one “right” way to implement it.
eg. An Inventory can be as simple as using Boolean variables to track if an item is being carried, to as complex as an Object based collection system that supports Items having weight & usages counts.
So often each project ends up requiring its own bespoke variation of such functionality, which makes it hard for someone like a Twine Story Format Developer to include a complex enough “one size fits all” implementation of such functionality.
So instead in the case of Twine each Story Format includes the tools needed to build such RPG like functionality. And some members of the Twine community have released guides & third-party addon libraries that can be used either “as-is” or as a starting point for a bespoke implementation of the feature the author wants.
3 Likes
I see that you’re aware of Dialog, but I’m not sure how familiar you are with it so I’ll say this: Dialog not only allows the author to switch between parser mode and choice mode but also allows, if the author desires, the use of parser commands while in choice mode.
Funny! That’s at least part of the reason I love testing your Adventurons.
Q: Why does the game respond like this?
A: Dunno. Adventuron must’ve had a personal “moment” there.
3 Likes
2 Likes
Ah yes, well you see: I tell Adventuron to do one thing but then it wilfully does something completely different!
Needless to say, this is entirely to do with Adventuron’s ‘emergent behaviour’ and nothing at all to do with deficiencies in my coding skills.
4 Likes
I keep wondering how many more games it’ll take you before stumbling upon the future AI Emergent Adventuron Overlord.
Shouldn’t be too long now. I give it two more SpringThings and a ParserComp. If you should compete in IFComp all bets are off.
2 Likes