This article is old — I think I last revised it in 2003 — and it is decreasingly relevant as time goes on, but I have retained it as a historical curiosity. In fact, quite a few of these things can be done with TADS 3 or Inform 7 (or both), using the built-in library, extensions, or sample code. The “Continuity of Space” section is especially wrong: TADS 3 does have a sophisticated system for recording the way rooms are connected to one another, and Inform 7 tracks directional information enough to do pathfinding.
Size, capacity, density, weight, shape.
One of the simplest forms of simulationism would be to add stricter capacity limits. Extending this to provide all objects with volume/weight/density would thus also account for problems such as buoyancy (does something sink or float?). It’s an easy system to design, but it has a couple of drawbacks. One is that to do a good job of it requires better numerical handling than Inform at least provides. The second is that it’s not actually useful for most puzzles, which (generally) tend to turn on less precise properties of things. A third is that it could get intensely fiddly to play, since there would be constant trouble moving things about. And a fourth (did I say a couple? I meant many) is that it would be hard to write as well, because there would be a lot of form-filling to describe objects. Also, any puzzles that turned on exact physical properties would also require very exact physical description.
So I’m not saying it’s a bad idea entirely; the results could certainly be interesting under the right circumstances. But any such system would probably be memory-intensive and time consuming to write (to write the objects for, that is; the base code wouldn’t be particularly difficult in all likelihood, though it would get considerably more complex if one started to take into account things like shape.) Application of such a system would make most sense, though, probably, in a small tight game environment where using and abusing these object properties would be the game’s main goal.
A reduced version of this is simply to mark things with more general sizes and shapes (sizes 1 through 4, for instance, for the range of sizes that can be carried or manipulated by a human, and shapes such as planar, rodlike, etc.) This is how Metamorphoses worked and it seems to have been essentially adequate.
Senses and description.
This sort of thing is mostly a question of prose-generation to make a game more colorful and interesting, though I can also imagine puzzles designed around it, where the trick was to get or create a light source of just the right intensity and coloration for a particular goal. I gather that some sense-passing is handled rather elegantly by the standard library of T3.
Light of different intensity or color. There could be, for instance, light bright enough to see by but not so bright as to allow reading. Or light of different colors. A master routine would search for the strongest light source in the room, which would then affect descriptions of objects. Carrying a flashlight into a room would give you a different description than carrying an arclamp or opening a window during broad daylight. Also interesting would be translucent or colored containers that would reduce but not remove the intensity of the light emitted from within. (See Savoir-Faire.)
Sounds. Objects struck together by shaking or banging should produce appropriate sounds. This requires identifying the materials in question and doing prose generation. (See Savoir-Faire.)
Timing.
One question in simulation is how you want to treat time. A turn can either be a consistent unit of time which is always the same length (eg., one minute), or the length of time that it takes to finish an action.
Timed Burning. >BURN starts the process of burning an object, but it goes on burning for however long is appropriate thereafter. This would depend on the substance of which the object is made, and its size. Several issues come up then. One is that the player should have to drop the object at some point (if he is holding it) because it will become too consumed to hang on to. Another is that flame can spread to other objects; and third is that burning can be interrupted before it’s finished. (See interrupted burning, below.)
From a technical standpoint, the challenge here is that one may soon have numerous timers or demons working at once, especially if the flame spreads or the player is particularly pyromaniacal. Parsing and disambiguation troubles come in if the player talks about “flame” or “fire” (eg, I have twelve different burning objects in a room and the player types >POUR WATER ON FIRE.) If spreading fire is permitted, one again has to be careful determining what gets to burn (objects in physical contact with the burning object, if they are flammable, if they are not the player or the location itself, etc.)
Heating and cooling. Associated with the above, and probably, like the above, requiring either timers or heartbeat demons, to count the elapsed time and the amount of heat or cooling conveyed by placing an object over flame or in a freezer. More complicated would be to track things like the thermal energy of the whole object and get all thermodynamically accurate and whatnot, but again this would require figuring out what was touching what else, and how much, and… wrf. My feeling is that this sort of thing is not likely to be hugely useful, but that it might be fair to treat objects recently in contact with fire as too hot to handle, for instance.
Triggers and explosives. This is really fun but really dangerous, because the more power you put in the hands of the player to wreck the environment the more trouble you have controlling what ultimately happens (and preventing him from blowing up something that he’ll need later.) Cf. the general caveat on Destruction.
Destruction and Partial Remains.
Any kind of destructive action is inherently dangerous to permit, because once your player starts taking apart the game world things get all crazy-like.
Interrupted Burning. Blowing on or pouring water upon something already burning puts it out. This is a pain because then you have the partially-charcoalized thing to deal with: it has to be described that way from then on, its partial state taken account of for simulations of weight; perhaps its carbonization would have to make it into a writing/marking tool (see smells and stains, below.) The whole thing can be ignored if you don’t have timed burning. (Ie, if burning something is an action that takes place and is completed in a single turn, then there’s no point at which the player can usefully intervene, and the mess is avoided.)
Breakables (eg. glass). Fragile objects can be smashed. That’s easy enough to do, though one probably at that point wants to distinguish >DROP (set object down gently) and >THROW (destroy object in the process of getting rid of it.) (cf. Metamorphoses.)
The more complex version of this is to have breakable objects produce fragments, which can then themselves be handled and moved around.
Cutting. Blades can cut through different materials. The Last Sonnet of Marie Antoinette has this feature, and also exemplifies different results from cutting something (the object is destroyed entirely; the object is opened; the object is reduced in size and leaves fragments on the ground; the object is reduced in size and there are also ‘slice’ objects produced.)
Generally speaking, the real trick here, even more than dynamic object creation, is deciding what result cutting produces given the object being cut. For containers that are closed, cutting might make a hole equivalent to rendering them permanently open; for things that aren’t openable, cutting divides the object, making a new piece-object that is of the same material as, but a chip off of, the old block. I can also imagine digging or gounging tools that would create hollowed pits on the surface of an object that would themselves be containers…
Ideally one might want to allow the player to specify exactly how he wants to cut the object, but this gets into a syntactic quagmire. Again, this approaches territory where the simulation becomes untenable in a text-based interaction.
Division and Mixture.
Divisible and miscible liquids. This requires, again, containers with known capacity. It also requires new object creation, or something like it, to simulate the separated parts, and tracking of the different components of a mixture, if you want to do recipes and so on. This gets a bit annoying again if you don’t have access to floating point numbers (Inform…) but you can live with it somehow.
For more about this see my comments on liquid modelling in Savoir-Faire, which give a more-or-less complete list of everything that the liquid modelling system attempts to handle.
Marks, scars, recording.
Now this, I think, has potential in a big way, but it’s underexplored so far.
Smoke. Burning something for too long produces smoke in the vicinity. This isn’t particularly difficult to program (at all. See the tiny amount of code in The Last Sonnet of Marie Antoinette). I’m not sure whatall useful results it would have, though marking one’s way through a maze is one possibility, and irritating an asthmatic NPC is another.
Carbon. Burning something in or over a glass or glasslike surface produces carbon smearing. (Again see The Last Sonnet of Marie Antoinette: try burning the wooden box with the candle, then examining the objects that come out of the process.) The fun thing about this is that it lets the player change the transparency (or in the appropriate circumstances, translucency) of an object; with rubbing/wiping/polishing verbs it’s undoable again, so it doesn’t change the game state in any unreversible way; and it combines neatly with other possibilities.
Smells and stains. Fluids spritzed, poured, or otherwise applied could transfer scents or stains to objects. Savoir-Faire does some things with this as well.
Paper rubbings, writing, drawing; cameras. The possibility of taking rubbings of a surface to get transfers of texture or writing underneath (as modeled in Peacock).
Audio and video cameras. Another thing again is the simulation of audio and video recorders that have to respond accurately to events in the environment. Varicella and The City, among others, take on this problem, but in the form (I imagine) of flagging which of a narrow number of possible events have occurred in the vicinity of the object. A true simulationist approach (where you could, say, place a recorder anywhere you liked and have it accurately record sounds or sights in the environment) would require sense-passing rules of a fairly well-developed order, so that if, for instance, I put my spy-cam on a shelf, it would ‘see’ what I was doing, but if I put it in a box, it would only ‘hear’, and the video recording would only catch darkness. Major headaches here. I haven’t even touched it.
Bulk objects and multiplicity.
Crowds and collections. Wherever you have a large number of objects, you want to allow the player to inspect the group as a whole, but also identify and examine individual members, perhaps searching intently for a specific thing or perhaps merely browsing. The bookshelf in “Pytho’s Mask” is one of my attempts to deal with this problem: you can look at all the books, and doing so will draw your attention semi-randomly to specific ones that you happen to see, which you can then examine in more depth. The idea is that putting some more-interactive items together with some less-interactive ones, the player’s experience simulates the actual experience of looking at a large number of items of which only some are interesting. “City of Secrets” also plays with this technique both for physical objects and for the crowds of NPCs that populate its streets.
This still requires a large commitment to coding (since you have to write up the subobjects), but it’s a bit more realistic, I think, than having a bulk-book item of which you can inspect none of the components individually. Your Mileage May Vary.
Links and Ties.
The Ultimate Rope. This is one of those things that has received so much attention that it almost seems pointless to recount the variety of the challenges associated therewith. First of all, a rope has two ends, so you have to remember the state of each (and disambiguate between the player’s references to them, of course.) Then there’s marking what the rope can be tied to; the possibility of cutting the rope in the middle, making multiple ropes of new lengths; the problem of using the rope as a fuse, of tying it to something in one room and then carrying the other end, of tying the ends together, etc., etc., etc. Ultimately I think the very trickiest part of all this is the disambiguation problem, ie, figuring out exactly what the player means when he says >TIE ROPE TO X (which end? Do we untie something that’s already tied, if both ends are in use?) But it’s all pretty grotesque, frankly.
Sophisticated Handling of Location.
Continuity of Space. Neither Inform nor TADS, of course, really keep tabs on the physical relationships between places. But wouldn’t it be interesting to be able to, say, allow the player to create new connections between places by cutting a chainsaw hole in the wall, or dig through the floor? This would require, naturally, that the game model the relative locations of things, and where one wall touches another even if it is not at any given moment possible to walk through it. This model might also take care of things like sense-passing (if every possible direction indicates a) where the adjacent location is if any and b) whether a wall is in the way, then the game will know whether you ought to be able to see into said adjacent location, or hear things done there.)
I tried to handle this to some degree in Marble Madness, where it is possible to roll from one room to another without issuing a >GO command, but this didn’t involve any very advanced programming.
Throwing and Trajectories. In many IF systems, throwing an item results in a generic refusal, for the simple reason that working out an appropriate response to throwing an item is fairly difficult. The system I used in “Savoir-Faire” takes into account a number of factors: whether the item thrown is too large or too oddly shaped to throw; whether the target is accessible; whether the target is too small to hit; whether either the thrown item or the target item is fragile enough to be broken; whether the thrown item or the target item, if breakable, is a container or supporter of other items that might themselves fall; whether the fallen items themselves break; whether the broken items, if any, are supporters [etc ad nauseam]; whether any of the items are round and thus ought to roll off a supporter when something is thrown at them.
I have the impression that some of these problems are handled by the standard library of TADS 3, so someone interested in using them might want to investigate that system.
Emily Short's Interactive Storytelling 