I note that some IF engines do not have true objects. Some have work-arounds, but what languages truly have objects/things? Inform & Dialog are two, to start with.
1 Like
TADS3 is object-oriented…
1 Like
Can you explain what counts as a true object for your purposes?
Are you asking about object-oriented programming practices, or objects in a world model?
4 Likes
If we’re talking about which IF systems are object-oriented ones, I believe that Inform 6, Inform 7, TADS 2, TADS 3, Hugo, and Dialog all qualify, while ALAN, ADRIFT, and Quest do not, although I haven’t seen any Quest 5 code to verify my opinion on that one, but Quest 4 was, shall we say, rustic. I have no idea what Adventuron does… yet.
2 Likes
When you say “true objects” do you mean the difference between a JavaScript Generic Object which is Prototype inheritance based and a Java Object which is Class inheritance based?
(…or between a language like SmallTalk where everything is an Object including “Primitive” values like integers & booleans, and a language like Java where “Primitive” values like integers & booleans aren’t objects (a). )
Exacting what Object Oriented Programming features are you using to distinguish a “true object” from an object that isn’t “true”.
eg. Interfaces; Method overloading; etc?
(a) Yes, I know Java includes Object based variants of the int & boolean data types, but those aren’t the “Primitive” data types are they!
3 Likes
not talking about language objects but rather IF objects (or things). A small brass hook is an object/thing.
2 Likes
In that case, don’t all parser engines have objects? Which ones don’t?
2 Likes
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