Open world IF system – seeking feedback

+1 to everything Hanon said. I tried to pick up Undum once and I never got past “I have to open up the sample HTML files in a text editor and edit them myself?” (Even figuring out how to open the files up so I could edit the raw HTML was non-trivial.)

In fact, I think Undum is a counterexample to what Dan said about people flocking to systems in which great work was made. The Play was the first choice-based work to place high in the IFComp and I think the second-highest ever after Creatures Such As We, but there are still less than a dozen Undum games on IFdB, which I think is because it’s so hard to learn the system.

Dan’s point that CYOA authors don’t like IDEs but would like to be able to write their games in a word processor is well taken. (Dan would definitely know.) I think the system as you describe it would probably have to appeal to a more niche group of authors–authors who see themselves as power users of CYOAs, maybe, who want to take it in ambitious directions at a mechanical level. Maybe people who are looking at what they can do with Inform or the more script-heavy Twine works and thinking of doing stuff like that.

Which means that your appeal to authors is something like “look how much scripting you can do!” Which means that you want to make scripting easy, I think.–And which also means, unfortunately, that you’re probably not going to be reaching a mass audience of authors like ChoiceScript, unless perhaps you do come up with some awesome games in a system that’s more accessible than Undum.

Sorry for getting to reply this late! I was with the family and originally thought I’d have more time for this.

I’ll try to reply in one massive post. Apologies if I misinterpret or simplify your points — feel free to correct me.

Many of you pointed out Undum, which I didn’t know about before and I totally should have. They’re not striving for the same thing, in my opinion, but it’s probably still the closest to what I have in mind. It’s criminal that I didn’t find out about them earlier.

How hard will it be to write IF in egamebook?

Matt has a very good point about niche group of authors. Let me walk you through it, though.

Here’s a valid and complete egamebook with some basic scripting.

It’s not a complete disaster (is it better than Undum?), but if anyone wants to write a gamebook like this they are much better off using Twine or pretty much any other system out there. This is not the main use case for egamebook.

For writers, egamebook starts to make a little bit more sense when using a custom library like ZIL (which I built for Bodega, inspired by the classic ZIL that Zork was running on). Here’s an excerpt from Bodega.

Again, maybe not a complete disaster, but it’s more boilerplate and pain than what you’d probably have elsewhere.

This hides the logic for having Rooms with Actors and Actions and Items and Exits. This logic must be implemented somewhere, of course, but the point here is that you have a library for it and you don’t need to do it (as a writer) with the limited capabilities of a domain-specific language (or in pure JavaScript).

Where egamebook hopes to shine is when you want even more than that.

Egamebook didn’t start as a tool to make interactive fiction more complex. It started as a tool to make narrative-based games prose-based (i.e. “more like IF”) and thus (in many aspects) less complex. This is what I failed to communicate. Think about all the pixelated indie games of today — they often have strong narrative, but despite requiring several person-years to build, they still have to resort to pixel art and relatively simple mechanics. What if some of them used prose instead of 2D or 3D graphics?

Making an NPC believably put on a helmet in pixelated 2D takes a day of work. In 3D, it can take weeks. In prose, all it takes is to write “he puts a helmet on”. You can then direct the engineering resources into more important stuff (world simulation, scripting, etc.).

Or so goes my theory.

To come back to the initial question: it will be hard to impossible for a single writer with little or no programming skills to use egamebook — if they want to use its full potential. They can always use it for simple stuff, in which case it’s quite easy, but again — in most cases there will be better alternatives.

Going back to Matt’s niche group — this is either for programmer-writers, or for teams. (This approach is not new to IF, though, is it? Some of the first IF games, like Zork, were — as far as I know — made by either programmers-writers or by teams of programmers and writers.)

“I need a coder to implement my game for me! I’ll do the writing!” trope

:slight_smile: Versions of this trope are in every human endeavor, apparently. In startups, for example, it’s “I have an idea for an app and I need some programmer to code it for me”. Ugh.

Two things come to mind:

  1. Interactive Fiction systems try to make writing software (IF is software, after all) accessible to non-programmers. This is great, but people have to understand this can only work to a limited degree. No matter how “easy” the programming language will be, once you hit a certain level of complexity, you have a problem. When we have so many writers asking for coders — so much so that it’s a trope — then we’re hitting that level pretty hard.
  2. By trying to make it easy for novices, and by trying to make it easy to start simple projects, many systems make it unbelievably difficult to create anything complex. I’ve seen this outside IF, several times. [rant]PHP started as something that lets you write very simple webs with no boilerplate. It got very popular. Now many complex sites are written in PHP (like this forum, and famously even parts of Facebook) — but many programmers hate it because it trades initial friendliness towards novice programmer for sanity, consistency, robustness and structure. It’s like if Word gave fiction writers pre-filled paragraphs of decent prose but didn’t allow for comments and headlines and sometimes put all your text into Comic Sans. Don’t take me wrong, PHP has its purpose, but many companies learnt the hard way that it’s not the silver bullet and that it pays to use an initially un-friendly, but more professional language.[/rant] This is also why these “I need a coder” cries will probably never get a response — because writing someone else’s ideas in a simplistic programming language is a programmers nightmare. (I think Sequitur’s first post says something to that effect.)

Twist: If there’s a writer who has sci-fi writing experience and wants to help write Bodega, let me know. :slight_smile:

Why Dart?

Huge disclaimer here: Dart is a programming language coming from Google, and I work for Google. Not on the Dart team, but still — I’m very biased. (This project, though, has nothing to do with Google — it’s been my side project for a while. By the way, my first language of choice all these years ago was — JavaScript.)

Now that you know the “prose-based game” focus (instead of “complex IF” focus), these reasons why I chose Dart should make sense:

  • Dart is similar to programming languages used in games programming. ActionScript, C#, Java, C++. Dart is way more similar to these languages than JavaScript.
  • Dart is already being used by game developers. Most famously, @notch (creator of Minecraft) is writing his new games in Dart.
  • Dart compiles to JavaScript that is mostly as fast (and sometimes, nonintuitively, even faster) than handcrafted JavaScript.
  • I agree that you can do a lot with Javascript. Obviously, everything you can do with Dart, you can theoretically do with JavaScript. But the reality is that programming languages and tools do matter. There are good reasons why, if you search for complex algorithms, you’ll find much better libraries in languages like Java or C# even though JavaScript is easily the most popular programming language ever.
  • Dart makes some things that are very hard in JavaScript, quite easy. For example, egamebook is already using threading, which means the game logic can be super complex and still there will be no jerking or freezing of the app. You can run a physics simulation on the background if you want. This is possible through webworkers which are a pain and buggy to implement in JavaScript, but not in Dart.

Bodega: What’s the narrative hook? What are we trying to accomplish? Is the plot more scripted or emergent?

The premise is woefully unoriginal — player is the last man on a stranded spaceship. The other crew members have died from a mysterious illness. The player is slowly dying, too. The initial goal is to survive. There is a twist.

Most of the plot is scripted.

It’s a first episode in a series.

Would it be possible, and if so will it be encouraged, to distribute the stories offline?

Totally. It’s a website, but apart from saving and loading progress “to the cloud”, once it’s downloaded all its assets, it can work offline.

Box2D physics - what would this be for in a choice-based game?

This will not be in the first game, but the idea is to use physics to simulate space combat and then take the results and put them in prose. This allows for completely emergent behavior (fire at one of the maneuver thrusters, disabling it, thus forcing the opponent into a spin until they can recover). It’ll also need a lot of testing before it’s ready for prime time.

Gaah, I didn’t get to answer everything I wanted, and the post is already humongous, and I need to run now.

Thanks everyone for the feedback. Seriously.

PS: @prevtenet: Thank you for you post! It’s amazingly uplifting for me, and your point about “Go to” instead of “Walk to”/“Go to” is a great catch. I’m thinking about ‘congnitive load’ a lot so I feel like an idiot for not having seen this before. Thanks!

1 Like

I’ll be keeping an eye out then! Many thanks!

Philip–Thanks for the response! Some quick points especially on the replies to me:

–that looks much more friendly than Undum. Like, the initial example seems like something I could type in and get a game running relatively quickly. I’d need documentation to know exactly what was going on with the script, but still, I could see myself trying to pick this up.
–writer/coders: The niche group of authors I had in mind are basically writer/coders. That’s what most people who work in Inform wind up doing, I think. Maybe some of us got sucked into coding through Inform’s relatively simple beginning stages, but as I said I don’t think it makes much sense for you to try to appeal to folks who don’t want to code at all, or minimally; smooth integration of code seems like your hook.
–space combat: I just wrote an Inform game which is largely about simulating movement and vision on a bumpy 2D surface so I feel you here. (Putting the results in prose is a hard problem, though. I made the characters robots in part because I realized that the output was going to be robotic.) Which reminds me: How straightforward is it going to be to write adaptive/procedurally generated prose? One of Inform 7’s strengths is that it gives you lots of ways to vary the prose output.

Anyway, looking forward to following your progress!

So: it’s ultimately aimed at coders, because it’s designed to let you do things that require serious coding, but it still tries to keep the simple things reasonably simple. Correct?

This friendliness vs. power tradeoff is kind of a necessary evil. It looks like you’re handling it fairly well, though - egamebook seems friendlier than Undum, anyway. It’s worth some thought, particularly with regards to how to wrap the standard libraries.

This is definitely most attractive to a niche - i.e. the “coders who want to write complicated simulationist CYOA” niche. But as a player, that’s a niche I really want to see supported, so huzzah!

Yes, actually, it is friendlier than Undum! In Undum, you literally write the game in JavaScript, even the basic gamebook stuff. When you said “Dart,” I was imagining something like this, but with type annotations.

github.com/idmillington/undum/b … game.en.js

Pretty cumbersome, if you ask me. (“You know what this needs? GENERICS” :wink: )

I think this theory is much less true than you’d think. You’re certainly right that text has the power to leave certain details ambiguous, reducing cost, but text also has a hidden weakness: players are much more tolerant of seeing an animation repeated than they are of seeing repeated text.

So, if your game is about space combat, you could write a sentence like this: “You hit the enemy cruiser in its starboard warp nacelle.” But if you keep saying that sentence even two or three times, the text quickly becomes boring and lifeless.

You might say, “No problem! Even if I have to write hundreds of variations, that’s still cheaper than getting a 3D art designer and a programmer to spend weeks on phaser animations. Plus, writers work for peanuts.” But how many ways can you possibly say, “You hit the enemy cruiser in its stardboard warp nacelle?” Even given an expert writer and days of dedicated effort, there are at most a few dozen ways to communicate that idea.

The end result would be a space combat game that gets boring after a hundred shots are fired.

Some people then say, “No problem! I’ll auto-generate text!” But how long does that take to code (and debug)? Procedurally generating “he puts on a helmet” from a rich world model is about as expensive as animation, perhaps more expensive, depending on your model.

For a good example of procedural text-based combat, look at inkle’s Sorcery! series; it required a programmer-writer/co-founder working for weeks (plus playtesting, and refinement) to get it right, and it does gets kinda boring after a hundred actions or so; Jon keeps the combats mercifully short.

Working on IF in teams is not new, exactly, but it’s an idea with unproven economics. Infocom, notoriously, couldn’t sell enough units to fund a team of IF developers, and I’d argue that nobody has since.

Instead, most IF is written by individual programmer-writers or teams of programmer-writers. (Maybe one person is more of a coder than a writer, but both are competent.) There are also some programmer-writers on a team with artists and composers, building text-heavy games with beautiful graphics and sound; they’ve been successful, too. (For example, that’s pretty much exactly inkle’s team. You’d also count various visual novels in this category.)

But I can’t think of any teams containing specialized “writers” and “programmers” that have generated either an award-winning free work of IF or a commercially successful IF. (Anybody?)

It’s not quite that bad; writing is hard work, and it’s a very important part of IF development. In your startup analogy, it’s more like, “I need a coder to implement my app; I’ll do the sales and marketing!” That could be a fair division of labor, assuming both parties are equally good at their jobs, unlike the “idea only” co-founder.

So why don’t these matches work out? Partly it’s because coders like to imagine that they’re good at everything, (it’s that kind of optimism that gets you over the hump of debugging,) so they want to write their own game, not somebody else’s. Partly it’s because if you don’t know how to a certain task well enough, (whether it’s writing, coding, sales, or marketing,) it’s hard to tell who’s actually good at it.

The writers I’m thinking of are mostly scared of coding at all. It’s not like they’re saying, “I can code a simple gamebook in Twine, but I need a Twine coder to help me write a more complicated gamebook.” They mostly got scared just reading the documentation!

Are you excited by this premise? You sound kinda bored just delivering the elevator pitch!

Natural Language Generation was something I spent maybe too much time researching (it was too much fun, to be honest). In the end, I confirmed that we only need a very specific subset of natural language, and one that’s quite easy to implement in English. That doesn’t mean it’s easy, but at least it’s not trying to construct sentences from semantic trees or whatever.

It’s something like:

[code]
player = new Player();
arrow = new Arrow(owner: player);
enemy = new Enemy();

arrow.report(“<owner’s> hit ”, positive: true);
arrow.report(“<owner’s> stay stuck in <object’s> knee”, positive: true);
player.report(“ {rejoice|smile}”, positive: true);
enemy.report(“ start moving towards ”, object: player, positive: true);[/code]
This already works and will say:

Note how it tries to use positive/negative sentiment information in relation to teams (not shown) to find out that it’s better to use “but” or “although” instead of “and” etc. Also note the curly-braces notation to automatically vary use of words.

(Of course, the code above is not something you’d write (it would be easier just to write the resulting sentences). In reality, your libraries would define those “ verb ” strings for you and in the book you’d just mostly use them, while spicing them up with custom events once in a while.)

Whether this is good enough to generate varied and fun-to-read prose remains to be seen. I hope to get back to this when replying to Dan’s post (which will take me some time).

Thanks! I’ll definitely continue posting here, because so far it has been an amazingly useful exercise. You can also always sign up for (more major) news at egamebook.com/ (via email or G+ community).

To be fair, historically certain muds were not unpopular which involved staring at large volumes of the same prose over and over and over again.

But of course, people playing those games eventually came up with elaborate client-side scripting systems to them tolerable, often by highlighting things to pick out the nuggets of relevant information, or by outright automation.

Apologies, I can’t resist answering this; on 80 Days our core team was 4: Meg a “writer”, myself a “writer/coder”, Joe a “coder/artist” and Jaume an “artist”. So, I think if your project is big, there’s totally scope for this model, but you probably still need “liminal” people, who cross boundaries to bring stuff together. I’ve seen that same statement proved in much larger teams on non-IF games too.

jon

1 Like

Oops, I was unclear on that point. I should have said that no team consisting entirely of specialized roles (“I’m a programmer; no writing” “I’m a writer; no programming”) has done well.

(Also, I thought Meg had some interactive/scripting background before joining your team?)

Yeah, she had; I suppose I mean that her role was to care about the writing and try not to think about the code-side. So, a separation of ownership if not an actual completion separation of knowledge, if that makes sense.

I’m not sure we’d ever consider working with a “pure writer”, but then, I don’t know what one of those is. All writing is technical and specific to its medium.

Anyway, basically, I agree.

jon

1 Like

[digression]

This is why IF combat is better suited to strategic decision-making, not shooting at something a hundred times until its hitpoint counter is depleted. (Kerkerkruip is probably the gold standard to look at.)

My design philosophy with repeated text is basically “fewer texts, more significance.” You want to encourage players to read everything, so designing your game to show fewer notifications in general is usually superior to using a lot of text-juggling to make those notifications vary more. E.g.:

versus:

Both requires some degree of NLP; filiph seems to be aiming more for the first example.

I agree–but if you want to have any kind of emergent behavior, it’s hard to make that happen on the large scale. Even Kerkerkruip doesn’t have that kind of dramatic output to the individual combat moves (at least, not since I’ve really played–which, hmmm, was the alpha); you get a colorful victory message but the messages for each hit tend to be “scan this for the relevant numbers.”

The combat game that really exemplifies “fewer messages, more significance” for me is Gun Mute–but there’s no emergence in the combat at all. It’s just bespoke puzzles. I have a general idea that emergent behavior requires tolerance for fairly mundane things; if you don’t have a system where (say) the player walks into the shop the same way they walk through the dungeon then you won’t have a system where they can do things you don’t expect in the shop.

Now maybe the moral is “don’t try for emergent combat.” I think maybe an interesting design approach would be to have some parallel track of character interaction going on while the combat is happening, so you can get away with relatively terse combat reports while you’re doing other stuff. So “Your phasers hit the starboard wing of the ship. Chief Officer Sulu says, ‘Are you sure this is the right course of action?’”–and then you have to both choose your combat action and choose some way of talking to Sulu, which will yield a more tailored output to go with the next combat output.

All good points, particularly regarding parallel drama. Combat is more interesting when there’s a lot of important things going on at once (though see The Battle of Walcot Keep, which is just insane).

I think dramatic descriptions like example 1 are possible in emergent combat, if you handle them well. Even with highly emergent gameplay, the engine will still be interested in discrete observable events, like a hit or a spin, which means we can describe them discretely. (I get the impression this is what Filip is trying to do.) We might simulate the results of the shot, collecting various pieces of significant information, and then have a routine that collects the information and formats it into a description with various text-variation rules:

simulation records a hit (event “wing.hit”)
– observes explosion (event “wing.explosion”)
simulation runs the ship physics
– observes downward spiral (event “ship.spin”)

reporter selects one of N randomized reports for wing.hit (“Lightning-green phaser bolts pour into the ship’s starboard wing.”)
reporter selects one of N randomized reports for wing.explosion (“For a moment, nothing seems to be happening. Then, with a shuddering whump, the wing explodes.”)
reporter selects one of N randomized reports for ship.spin (“The ship stalls and begins to spiral slowly downwards.”)

reporter combines the relevant reports and displays them

Or something like that. A fancier reporter routine could keep track of implied information and omit unnecessary reports (e.g. if the report for wing.explosion talked about the hit, the reporter might omit the report for wing.hit); we could also have more detailed logic for word-level variations and how frequently random reports could be repeated.

This would still wear thin over hundreds of shots, but that’s why you’d focus on fewer, more strategic actions, and have some parallel drama going on.

…and suddenly I feel like writing an emergent space-combat sim. :stuck_out_tongue:

Haha, yeah. Thanks for the link, that does seem like a lot of boilerplate for something that basic.

You are absolutely right and it shows that you guys have been thinking deeply about this for at least as long as I have. (Or you’re a genius.)

I have some ideas how to make this work, but of course whether it’ll work is still anyone’s guess. I think the short answer is to avoid repetition in gameplay. (Duh.) And yes, repetition is a huge part of pretty much every game mechanic out there. Fortunately, there is the simplistic “I hit you, you hit me” repetition, and then there is the more complex, but doable “what do we do now” repetition.

What I’m trying to say is that simple combat systems and minigames will definitely not work if they’re just made into prose. In egamebook, they should either be converted to minigames (no prose output, more like little JRPG combat systems), or they must be reworked into something completely different.

I agree it’s not easy at all, but once (if!) it’s done once, then it’s 80% done forever. I answered above to Matt:

I try to strike balance between doable (by me), easy to implement (by author) and giving good output (to player). I can’t have all three 100 %, but I think I’m getting to a viable compromise.

Sorcery is awesome. Big inspiration for me. I need to study the combat system some more.

Great point. I’d wager one reason for this is that the current systems are built for this (more specifically, for a lone programmer-writer). There’s not much space (or tools) for separation of concerns.

That’s another big bet I’m making with egamebook — that this particular system will make it possible to take a traditional indie game studio and (thanks to its separation-of-concerns features) provide it with the “Unity for prose-based games”. Clearly, that’s a stretch goal.

Re-reading my reply, I see what you mean, but I actually really seriously very much am excited! I guess I tried to be self-deprecating there, and it reads like a ‘meh’.

Bodega is something I had always wanted to write (and play) and by working and reworking it for years I think it’s gotten much deeper than I was originally planning to. Not just in game mechanics but also in theme. I really really hope all that work will show, and I hope that I am able to forge my ideas into something that is fun to read and play.

It’s true that “the premise is woefully unoriginal”, but I think I’m taking it into an interesting direction. And I wanted this to be a genre piece. I love genre literature, especially when the author can use the established tropes as tools while creating something original. We’ll have to wait to see if I was able to at least partially pull it off.

Which reminds me: I’m talking to an editor, and he’s great, but he seems to have trouble parsing even Markdown, let alone the occasional $variable in text. Are there editors who are ready for these irregularities? How do I search for them?

OK, yeah, I definitely want to play this.

Your ideas are intriguing to me and I wish to subscribe to your newsletter.

No seriously, I really am interested in this. Hopefully this isn’t outside the bounds of permissible self-promotion of my ParserComp entry, but if you look at my entry (“Terminator”) there’s a lot of previously generated description–but it’s fairly Walcott Keepish, because one thing I did not have time to do was figure out how to take a list of things a robot could no longer see and turn it from “It can still see a pointed ridge. It can no longer see a hauler or a hauler” to “Two haulers have disappeared behind the pointed ridge” or whatever. But that’s the kind of thing I’d really like to do. It seems like the first step in a case like mine is to come up with a nice way of capturing the stuff you’re about to print and combining the stuff that needs to be combined. Non-trivial, though!

The thing I worry about with your emergent model is giving the player control. In a graphic game we could maybe see that if we hit the wing just there then the ship will go into a spiral. If the text is hiding the relevant details of the simulation from you then it might be hard for the player to understand what was going on. (Emily Short has talked about something like this in Versu development; there was something where the butler was hostile to the PC for no apparent reason–it turned out that the PC had been rude to a servant who’d told the butler, which is kind of awesome as an emergent effect, but it wasn’t satisfying to the player because they couldn’t tell what had happened, so they took it out.)

But anyway I want to try your emergent space-combat sim.

This is one of the main reasons I prefer discrete-state-tracking simulations rather than full physics-engine type simulations. (The other reason being that it’s a lot easier to implement.) So the ship might have a “stability” variable with a couple of options - stable, impaired, spinning, free-falling - which is set by querying other attributes of the ship (is at least one aileron on each side of the ship still functional? etc.). There’s a combinatorial explosion of possible scenarios, but a manageable number of discrete states, which can hopefully be described well.

Thanks! My current WIP is completely unrelated (sprawling alternate-history French Revolution thingamajig), but the current design does have a hand-to-hand combat system a bit like this. For now, anyway - the game has gone through a lot of design revisions.

In a combat-heavy game with very low-level combat actions, I think repetitive messages is desirable. Like when I play Cataclysm: Dark Days Ahead and become locked in melee combat with a single opponent, it is just about hitting the attack key and reading the messages. If the messages were varied in clever artistic ways that would be painful because the content would be hidden in all the words. It is very useful to only get “You hit the zombie. Critical hit! The zombie hits your left arm, but the armor protects you. You swing wildly and miss. The zombie hits your head. The bite wound feels deep.”. etc etc (Quoted from memory, not actual text in game, but similar.) There is some variation, but only when the actual effect is different. A different message has a different meaning, so it is immediately obvious what happened. (It is probably the same in all roguelikes (as in games that are actually like Rogue, not just any game referred to as a roguelike today)).

EDIT: Also I should mention that the text in Cataclysm:DDA is shown in green when good things happen, red when bad things happen, so you rarely have to read at all unless a lot of red text starts coming up or you notice that one of your health-bars is running low. Makes combat much faster and less annoying.

If the game has more higher level story-based combat, like the Way of the Tiger gamebooks where you read some prose, pick one of a few actions, go to a new section to get more prose telling you what happened, maybe repeat once or twice more to resolve the battle, without any of the hp grinding, THAT would be very interesting to see automatically generated in an open-world game. If you can make something like Fable Lands but with combats that are more story-driven than just grinding down hp, so you can make interesting decisions instead of just attack, attack attack, that would be fun. Essentially that turns combats into mini-puzzles instead of boring optimizing-damage-calculations.

About the rant on simplicity: I think a lot of people get it wrong. My reasoning is that if a designer can’t figure out a way to make something simple simple, they will make difficult things horrible (like Spring). If hello world is more than one line I’m not particularly interested in guessing what madness of boilerplate is required to do something that does real work. Unless someone to my great surprise can show convincing research that a complex small example somehow magically results in nice big code, I will continue to argue that it is just a big myth of computer science. Of course it happens that someone design some language or framework that has impressive small programs at the cost of more complex big programs, but it is not always the case, so there is no reason imo to accept a sloppy design that results in complex small programs.

And speaking of simplicity, my choice for a general-purpose language would have been Clojurescript. :slight_smile: But I have to agree with others that using a general-purpose language is not ideal for this. It makes things complex for both implementing and using. Better hide it far behind the scenes, only required for very complex customisation, and not getting in the way of normal usage. For my gamebookformat tool you can definitely add your own templates including even javascript (or whatever language you compile to javascript, I guess), but I try to not mention that too much, and since a recent commit you must add a command-line flag to even make that possible (to avoid accidents for new users). Sticking to a known fixed set of mark-up tags makes it possible to do things like automatically check the story for consistency. Having any kind of scripting takes that away. Also it makes it much harder to reason about what happens in the book even for humans (including programmers).

Re: simplicity - mental overhead is definitely important, but it depends on what the draw is. Is the player more concerned with what they’re going to do with information, or with how the information is presented?

In the former case, using short, formulaic, repeating descriptions helps reduce mental overhead so the player can spend more time thinking about what they want to do. If you have a small, formulaic change in state, describe it with small, formulaic text:

It’s like looking at the positions of all the pieces in a board game. You want to know the status of everything as quickly as possible so you can make your decisions. (Kerkerkruip does this well.)

But this doesn’t work in two cases: 1) if the scenario isn’t tactically interesting enough, or 2) if you have a lot happening in a turn. If there’s too much going on, you start longing for proper prose:

The other time it doesn’t work is when presentation is important. If the player is playing the scene for drama and large-scale strategy, where each move carries a lot of weight, a descriptive style works better. They don’t want to read a terse hitpoint notification; they want to read an awe-inspiring description of two starships colliding over the Dakkon Gate.