Hey everyone… I’m working on an Inform 7 project where, before anything else happens, the player picks a variant (not just A/B but potentially many) and from then on almost every piece of on-screen text could have one of several alternate wordings.
I’m torn between a few lightweight approaches… an inline chooser phrase, a centralized messages table, separate string files per variant, or small named say phrases for reused text… and I haven’t committed to any because I’m not sure which trade-offs matter most.
What’s the idiomatic, low-hassle way people handle this in Inform 7? This isn’t for localization per se (it’s about runtime variants)… my first instinct is always to reach for a quick-and-dirty hack… but I’d really like to know the cleaner, idiomatic patterns you actually use in Inform 7 projects. Thanks in advance!
I think it’s hard to assess this without some reasonably in-depth examples, because all of those approaches are plausible IMO (and honestly you’d probably use some combination in practice). I do suspect tables would make life easier when it comes to debugging, but they’re a bit more awkward to wrangle when writing.
I’ll take the liberty of tagging in @kamineko, since his Portrait With Wolf is basically one gigantic pile of text variations and substitutions!
I haven’t tried this in a while, but I’m afraid there are no really lightweight approaches. There’s going to be a lot of boilerplate no matter how you do it, so just pick one and get going.
I would probably use a lot of named say phrases containing if var is: --X: ...; --Y: ...; switch-case statements.
The docs have an example of how to add a custom ending to [one of] that switches based on a variable in the game, but that means putting all the differences inline, and [one of] can’t be nested.
As others have said, commenting on an appropriate solution for your specific case would require knowing more about your case.
Rulebooks and activities are, in general, some good ways to structure complex and massively customizable behavior in Inform. My impression is that people don’t often employ them for text generation, but it’s not because they wouldn’t be capable. That level of flexibility just isn’t relevant most of the time.
You might also like to pay attention to Scenes, which are a powerful/flexible way to track game state so that (with appropriate setup) you can straightforwardly turn what would otherwise be a messy compound conditional about the states of things into just if <scene> is happening or, in a rule preamble, during <scene>. But this is more helpful in situations that are dynamic. If the variation in text is dominated by just the player’s start-of-game decisions, it might not be of much use.
Thanks for the shout, @DeusIrae ! PWW is 42 “screens” made up entirely of text substitutions, some based on inputs and others based on global variables/counters.
It’s really hard to know what to recommend without more details, but for that case I held all of my variable text in tables. I think the complexity of the situation warranted it. In fact, during development, I split the tables into extensions so that I could read them side-by side in vscode.
Just kind of talking through things, I also used a bunch of table name that varies so that I could shuffle the active table behind the scenes.
This may be overkill for your application! I can say that table rows are often more readable than one of constructions, especially lengthy ones, and additionally lend themselves to being read side-to-side with other tables while editing.
Thanks for all the answers. After thinking it over, I’ve decided to go with a centralized table of message IDs. I don’t mind keeping all the text in one place… in fact, I think that I’m already organizing my research that way. Thanks again!