Scenery items? Are these a hack to put things in multiple places, like “the sky” ?
1 Like
In Inform, “scenery” indicates something that is fixed in place (can’t be picked up/moved) and undescribed (not in the “You can see ___” description, which in most cases means the author describes it in the room description).
The sky would be a “backdrop”.
2 Likes
It is funny to imagine purposely over implementing to the point of absurdity.
> Look
The shed was small and made of wood that had gone gray with the salt wind. The door had stuck in the frame and you had to set your shoulder to it to make it open. Inside it was dim and smelled of oil and rust. The floorboards were rough and on them was sand, carried in on boots and never swept out, ground fine and dry between the cracks.
> Look at sand
The sand glittered on the floorboards like a scatter of forgotten stars, sifted down from some careless cosmos. Each grain seemed alive, whispering of deserts and seas and all the places it had traveled before coming to rest in this quiet wooden box.
> Examine sand grains
The sand grains are primarily composed of quartz (SiO₂), which makes up the bulk of most naturally occurring sands due to its high resistance to weathering, with minor inclusions of feldspar, lithic fragments, and heavy minerals (zircon, magnetite, garnet) depending on provenance. The average grain size is between 0.2–0.5 mm (fine to medium grained sand), with grains showing a generally sub-rounded to rounded morphology.
> Examine sand grain morphology
The morphology is indicative of extended transport and abrasion. Surface textures are smooth with occasional frosted pitting, suggesting a history of aeolian transport, though some angular fragments may point to partial fluvial contribution before reworking. The overall mineralogical and textural evidence suggests a mature sand, eroded from continental crustal rocks, transported by rivers, and subsequently resorted and rounded by wind action.
9 Likes
More silliness.
> Examine atomic structure of Quartz
The quartz grain’s crystalline structure is composed of a continuous framework of SiO₄ silicon–oxygen tetrahedra, with each oxygen atom shared between two tetrahedra, giving the overall formula SiO₂. The lattice belongs to the trigonal crystal system, specifically α-quartz at room temperature.
> Examine silicon–oxygen bond
The Si–O bond has a bond length of approximately 161 picometers and a bond energy of about 799 kJ/mol. This confers quartz its remarkable chemical durability against weathering agents.
> Examine electrons in bond
The outer electrons of silicon hybridize into sp³ orbitals, sharing electron density with oxygen atoms. The valence band is fully occupied and a wide band gap (~8.9 eV) renders quartz transparent to visible light.
> Examine band gap
You notice that even within the apparent stability of the empty band gap, quantum electrodynamics predicts momentary fluctuations of virtual electron-positron pairs. They blink into existence, unobserved, like shy actors unwilling to step into the narrative spotlight.
> Examine fluctuations
You are now lost. You have zoomed in too far. You have been eaten by a grue.
12 Likes
It’s certainly possible. That level of zoom is achieved by Orteil’s Nested, which lets you go into atomic and subatomic detail on any object as a key part of the game. Though it’s not a parser game and doesn’t feature much detailed description, which is unfortunate.
2 Likes
What would scare me is not the endless verbosity, but the potential to get a sand grain. Then start propagating these grains around the game. Putting them in different locations and into containers. Then trying to put different numbers of grains everywhere. When does “a grain” and “two grains” become “some grains” or even just “sand” again?
If the game hasn’t crashed or messed up horribly. The player would probably go on to try to make an egg timer and expect it to work!
1 Like
OK thanks. I see. Can you separately control how an object is mentioned? So “scenery” is just a short cut?
1 Like
On the subject of implementation detail or resolution of the world model, i want to mention two different approaches to IF system design. In this thread, this problem could also be viewed as “parser detail”, since most people like to lump the world modelling in with the parser.
Most people here are used to systems that predominantly send the verb to the object. But you can make a system that mostly sends the object to the verb.
So what’s the difference?
Let’s suppose you did want to build a system that has a very detailed world simulator with physics and all sort of physical properties of objects. A world where the author didn’t have to code all this but only to add a small “icing sugar” level of behaviour to objects in order to make the story.
And also you had a rich property model for all game objects. All sorts of facts and figures as standard (weight, size, shape, sharpness, capacity, liquid, etc).
Having a rich property model is important to object->verb models as opposed to verb->object models.
Ok so;
Now the world model is approached largely as a simulator that models object behaviour in terms of the many and detailed physical properties.
- If you hit something, is it brittle or fragile?
- If you cut X with Y, is Y sharp? How sharp?
- If you put X in Y, does Y have capacity for the sizeof(X) ?
- Can you wear X? X would know what kind of body part is covered.
is it a hat or pants?
It gets complicated, but it’s possible to make a half-decent approach like this. Of course, each of these activities needs a “before” and “after” for the author to intercept to, either add story or to change the implementation as they wish.
Then messing with individual “sand grains” becomes a system problem and not an author problem.
3 Likes
I feel compelled to point out it was definitely a joke and I was not trying to nerd snipe anyone.
4 Likes
And it was a GOOD joke!
3 Likes
Yes, with undescribed.
3 Likes
This is sort of how I’m handling it in my system in development. The dictionary has base verbs, and objects subscribe to them, so that every object has the potential to respond distinctly to any verb applied to it. Of course objects have class inheritance and all the verb subscriptions are predefined for common object classes, so authors don’t need to think about subscriptions if they don’t want to, but subscriptions offer a number of different hooks for authors to customize responses or inject custom code.
Yup, indeed. My verb subscriptions have the concept of phase hooks, where every verb operation passes through phases: doBeforeTry, doTry, doAfterTry, doBeforeSuccess, doSuccess, and doAfterSuccess. doTry and doSuccess contain all the default logic (which can be overridden) and the others are pure hooks. And this is only one type of hook - there are many others that depend on the exact sentence structure used (doVerbToThisWithThat), or the end result of the action (doMoveThisToThat) - to allow for broad or granular control.
Yup, my system has many of those properties, where many of them are ranges, and there’s some amount of default handling for min/max values. For instance, you can set a sink with a hot and cold water knobs, with each knob a graduated controller that has an arbitrary number of positions, and the output temp of the faucet is an average determined by the base temp of each knob and the throughput determined by each knob’s position. It is, frankly, perhaps a little bit insane, and not something that most users would need or care about.
Honestly, I find the hardest part of designing such a complex system is presenting it in a way that doesn’t immediately befuddle or terrify new users. The whole point of the engine is that new users should be able to jump in without any care for the depth of its details, while advanced users should be able to find all the features they need to customize everything, which makes for a delicate balancing act. With all of that said, I think the most important part of such a system is good, clear documentation. I’ve spent at least half of my total development time writing documentation and trying to organize it in ways that invite new users in gently.
4 Likes
Your system sounds interesting. It’s not wrong to have it simulate stuff in high detail, because these things are a system problem and not an author problem. If the system can make it easier for authors, that’s good.
The concept of detailed simulation can, in fact, make it easier for beginners. Let’s say you have a rich hierarchy of object types and verb operations. A beginner can already build, what i call, “a dry game”;
The concept of a “dry game” is one where an author makes all the locations and objects, together with their “standard data” (supported system properties) and plugs these in to a game. In other words, builds the “database” and not the program logic.
What you should then get is a “game” where you can walk about and manipulate objects insofar as the system simulation of your standard data. So in practice, this means you can put things on and in other things, mess with containers, liquids, doors, locks, darkness/lamps etc. And these should all work out of the box without any programming whatsoever.
And it’s that last bit, the “no programming”, that appeals to beginners and people learning the system.
I call this game “dry” because, as yet, there is no story and no special logic to implement it. But nevertheless, this “prototype” is enough to do some testing. You can see if things “kind of work” and whether you need some extra locations or objects. Or perhaps there are too many things and you need to cut them back.
So much can be done without the actual story being implemented.
2 Likes
Yeah, that is the goal that I’m working towards. It’s a simulationist world with extensive pre-designed verb logic, and in theory an author should be able to write a game with just a data file. The engine is written in Javascript and the data format is Javascript objects – basically JSON – so if you can write a JSON doc, you can write a game.
2 Likes
Regarding the “lean rake against fence” example, I’d agree “I don’t understand” is a uselessly vague reply from the parser, especially if there are other situations where lean is a valid verb or where you have to use one object to interact with another.
As for the silly example of examining sand down to the atomic scale, I find myself imagining the combinatoric explosion of a game where you move about a 4D space while also having sci-fi tech to time travel at will, hop between parallel universes, and shrink to atomic scale and grow to cosmic scale and everything in-between…
Though, I suppose a question to ask if one is going to try to describe as much of the world as possible and implement as many actions as possible, is howto create puzzles with many solutions, including potentially ones the author didn’t think of. Because I’m not sure the issue is extraneous information per se, but rather that that richness feels irrelevant when you still need very specific solutions to progress. Granted, this is arguably another area where mainstream video games have the advantage since tey can just assign a model and weight to an object and let the physics engine handle most of the interactions between objects whereas IF authoring systems rely on the developer to describe an object and its behavior and major development systems don’t really have a way to automate beyond the most common behaviors.
4 Likes
I think by the time you’ve implemented that much detail, you’ve built a simulation rather than an adventure game. The thing that keeps coming to my mind is Dwarf Fortress. Those guys have implemented an insanely deep world. I remember an anecdote the lead dev shared in an interview: they spent ages trying to understand why cats were dying in taverns… and they finally tracked it down to an incorrectly placed decimal in the value that determined how much alcohol a cat consumed when it licked its paws after walking through alcohol spilled on a tavern floor. In short, the cats were dying of alcohol poisoning.
A bit further up the thread (I think it was this thread) someone drew a comparison between text adventure vs GUI adventure games, and my observation there was that GUI games draw a clear box around what’s possible, whereas text games offer the illusion of total freedom and then invite (force?) users to find the limitations.
I think this comparison applies equally well to modern 3D games. Though they’re generally more technically sophisticated than the old 2D GUI games and the physics models are impressive and the worlds can be quite large, those games still present fairly clear limitations, even if the limits are often cleverly masked by geography (shorelines, mountains, etc) or limited inventory or what have you.
To your point about creating puzzles with many solutions – is the text game infinite? Or is it only pretending to be? In a very limited simulation, probably the better UX pattern is to more clearly communicate the limits on the player’s freedoms in the same way a 2D GUI or 3D world does, preferably in a friendly diegetic way (which in itself might require a bunch of additional logic and unique error responses).
3 Likes
Jumping back in here again… I was reading the parser chapters of the Inform DM 4.0 and… yeah, it’s a work of art, but I would argue the vast majority of users are not really going to notice
pick up the other sword
works correctly. It’s also 4,000 lines of code to achieve that.
It also supports many non-English languages, which is also rather cool, but again, not one of my personal objectives. For me, achieving an Infocom-quality parser that could run on an old 8-bit is the goal, although it way well be that the expectations of users have moved way beyond that, even though I myself have not.
-Dave
2 Likes
I’ve also been convinced over time that language-specific parsers will work better than language-agnostic ones.
4 Likes
Language agnostic parsers makes me think of translingual homophones… For example, english taco(a texmex dish usually consisting of a hard or soft tortilla folded in half and filled with ingredients such as seasoned meat, grated or shredded cheese, sour cream, and various raw, diced veggies) and Japanese tako(octopus or kite*)
*Which reminds me of a joke from Dr. Slump in which one of the characters, I believe Arale, flies an octopus as if it were a kite… no clue if I would have gotten the joke without the translator’s note in the Viz translation of that page, though I already knew Tako was the Japanese word for both octopus and kite was tako thinks to how often takoyaki(fried octopus dumplings) are mentioned in the Japanese version of Ojamajo Doremi, including a joke where Aiko tries to conjure takoyaki but instead conjures yakitako(a fried octopus) and knowing tako is Japanese for kite from building a kite in the style of traditional Japanese kites as my cultural crafts project for my Japanese class in highschool(teen me was obcessed with Japanese pop culture and didn’t want to take spanish for my foreign language like everyone else, so I jumped at the opportunity to take Japanese… took me three years to complete the 2-year requirement, and even on a retake I barely finished Japanese 2 with a C)… and now I want to build another kite…
1 Like
I totally understand that it’s impossible and undesirable to fully implement every possible state of an object and its relationship to every other object. I don’t expect authors to do that.
That doesn’t change the fact that the incompleteness of the simulation can feel like a parser bug to the player. Especially when they run into the incomplete corners again and again chasing what they thought were clues in the text. We have to remember players of puzzle-y games may be scrutinizing every word of output for clues.
The point of my leaning rake example was not to argue that the game should implement a leaning-against concept. It was just an example of how descriptions can (and, in my case, frequently) lead the player into the unimplemented corners. The more often that happens, the greater the risk to the sense of immersion and the suspension of disbelief.
Many games offer an initial description of an object that’s used only until the object is manipulated or moved. I was one of those people raised to “leave it as I found it (or better).” Remember those posters that listed rules like, “If you open it, close it. If you borrow it, return it. If you break it, replace it.”? If you imprinted on those, initial descriptions that imply a state that’s impossible to restore are particularly frustrating.
In specific cases, I might argue that it’s better to remove a detail from the initial description. As dull as “There is a rake here” is, it’s unlikely to encourage the player to try anything the author didn’t anticipate.
3 Likes