In the earliest text adventures, the player input text is connected to the rest of the game way more intricately than it’s connected in the modern text-loving games. When the player types “light a fire”, that corresponds to a toyworld: a model of what a “fire” is, what “to light” is, & how it all works as a system.
Dream goal for the future: you write any code inside the game & the game makes a rad interactive visualization of it.
There are scads of old-school text adventures released every year. The modern parser scene is robust. Most modern games are friendlier to the player, eschewing zombification and providing more implicit actions, etc. But the conventions of early text games are largely still intact, and modern players expect a richly implemented game world, more so even than they used to.
So I don’t think you are right!
My experience is more that you type ten things you think of and none of them work. You sound like you want to play AI dungeon where you can type anything, which is also a problem. Making good games is hard.
Technically, this exists. You can submit whatever command you want, anything, and the parser always has an apt response. You do need the most sophisticated hardware on Earth to run the parser though; another human brain.
I think it’s true to say that authors don’t value simulation as much as they used to, but one reason for that is this: while authors may enjoy simulating things (it can be fun!), it doesn’t necessarily translate to a rich experience for the user.
Many modern authors aren’t interested in simulating doors or elevators because the player will seldom if ever know the difference. The same might be true of your fire example.
This isn’t to say simulation is bad or a waste of time. I will shout my affection for Deadline to the rafters!
TADS 3 has support for the senses (like smell, look, etc) noticing things in other rooms and from a distance, varying light conditions (as opposed to just light/dark), room subsections, and so on. People can add, and have added, to its libraries to simulate further objects too, that the original library didn’t create!
Complex simulation is absolutely still possible and sometimes still done. But Drew brings up a good point that the “I’m going to perfectly simulate this toaster” thing is not really fun for the player and a rabbit hole for authors that is kind of cliche and discouraged nowadays (mostly because it’s kind of a waste of time to do that instead of work on like…plot or something).
I also think that the player input text being more intricately simulated in the past is overstated here. From what I remember of old school text adventures I’ve played, it’s mostly been equivalents of “i don’t know that command” or “you don’t see that here” until you happen to essentially pixel hunt with your VERB NOUN commands successfully. That’s definitely something that can happen in current sparsely-implemented games, but there’s plenty of advice and encouragement to avoid it now.
NOP, Most text adventures don’t have a sistemic approach, so FIRE OBJECT only worked for the puzzles that were tailored to the verb.
Not quite.
There are definitely a lot of IF pieces that are focused on simulation and emergent gameplay—Emily Short’s Metamorphoses is a famous example, and her Counterfeit Monkey might be the largest simulation-focused IF in the world—but especially in the early days, that wasn’t necessarily the norm. The original Adventure didn’t have any real simulation of containers, or of liquids, for example; there’s no general model of how one thing can be “in” another thing, just special cases coded in for the bird in the cage, and the water/oil in the bottle. All of Scott Adams’s games are the same way.
But this isn’t necessarily a deficit either! If you look at Jason Dyer’s writeups of the various early Adventure offshoots, you’ll see that the ones that tried to accurately model containment generally made the experience worse for the player, because the general system makes it annoying and tedious to handle things that were previously special-cased to work exactly as you’d expect!
(Nor is this sort of world modelling reliant on a parser. A lot of Emily Short’s works are masterpieces of this “simulate a system and let the player interact with it” style, and her famous Galatea could work just the same with a choice interface. More recently, Choice of Games has gotten a reputation for choice-based games that track lots and lots of different stats to make every character’s story unique.)
Now, that’s not to say simulationism is bad. Far from it! I personally love building general systems rather than hardcoding special cases—Scroll Thief arose out of a desire to generalize all the special cases of Enchanter’s magic system and see if I could make puzzles out of it. But I don’t think it was as ubiquitous in early games as you make it sound, or that it’s disappeared in the modern scene.
This Deadline or some other Deadline? Deadline (1982 video game) - Wikipedia
Definitely that deadline.
Even if the goal is to make a world that feels alive, with the player taking an active role in it, there are several strategies. Story centric twine games solve it by trying to use descriptive writing. Simulation games try to stimulate everything, though that may actually have the opposite effect by breaking the illusion.
.png
Thank you so much for your reply! Real ardency!
Do you know text adventures that simulate some kind of living systems? For example, ecosystems of animals in their natural habitat.
Baking with Lizzie 
Not off the top of my head, but I’m sure someone’s tried! This seems like something Choice of Games would have experimented with.
Oh, you’re fine. I make typos left and right and usually ignore them. I just found that one particularly and accidentally amusing, that’s all. 
(What are you baking?? Iz good??? 
)
Just searched their catalog for the word “animals”, the result is 1 furry game, sweet: Welcome to Moreytown
Nice catch. I didn’t even catch it in your first comment. No typo in Baking with Lizzie though - copied right from ifdb.
Oh my gosh… very funny. I thought you were saying it was a typo due to your being preoccupied because you were baking with Lizzie. I just realized you were replying to someone else with a coincidentally appropriate IF game title. Slight bummer you aren’t actually baking though. No noms.
I remember seeing a dev diary for a visual game where this guy was trying to make every single component drive the function of the large object.
The example I remember was a handgun where technically you press mouse1 to fire, but there was not a fire() function being called on the gun object. What was actually happening was the trigger was a physically-simulated object in the game, and if it was rotated slightly back, the gun object’s code detected this and would call the fire() function on its own. So when the player pressed mouse1, what was happening was the player character’s finger animation would physically squeeze the trigger, because the fingers had their own collision mesh, and that’s how the gun fired in this game.
And then he showed off “how much better” this kind of development was by showing the extremely rare case where the player could pick up a stick from the floor, walk up to a handgun (also on the floor) and jam the stick into the trigger until game physics registered enough of a collision with the trigger to make it move.
I remember watching this and thinking “Wow, that’s a neat approach, but I would never use this approach, and most players wouldn’t notice it, and many who do might assume they’ve found a bug” especially because game physics don’t work accurately enough to not cause these to misfire seemingly at random. This breaks player expectations.
Now, do I plan to lean heavily on simulation in my future projects? Absolutely. But only when it is mechanically interesting for gameplay. I’m not going to try to simulate real life; just give the player enough options for creative thinking and reward for effort.