Have you written an IF game in a language like Inform or TADS?
Any object can potentially interact with any other object in the same scene (or in your inventory). These languages support standard language abstractions (classes, types, whatever) - but that will end up with very boring responses when you try to make two things interact with each other, and players don't enjoy the game if it has too much of this - it kills the suspension of disbelief. As such, game designers put in a lot of effort to put in custom responses and behavior just so that the player remains immersed in the game.
It's an O(N^2) problem.
They usually invent game dynamics to prevent this from happening (e.g. making sure you lose/consume objects to get from one part of the game to the next - so that N is drastically reduced).
I hate to say it, but your comment comes off a bit condescending. While Ink and Inform hide away some abstractions to make it easy for newcomers, plenty of games are written in TADS (easily the 2nd most popular language for IF), and you very much have to have a programmer mindset to write games in it. Telling a TADS programmer they need to think in terms of variables and functions is like telling a physicist he needs to understand calculus to model the world.
> I hate to say it, but your comment comes off a bit condescending.
Upon re-reading, I think it may come off this way. I'm sorry - I didn't mean it.
My comment was mostly colored by experience with various IF examples I browsed over the years, including most recently poking around some RenPy-powered visual novels. In all those cases, the stories were vastly under-utilizing its markup language. By that I mean, you could cut the source down to 1/10th or less of its original size by introducing some loops and variable grouping; further still with procedures. Reading them felt like reading assembly output of heavily inlined code.
What I failed to communicate is that my complaint comes from a good place in my heart! The stories I just criticized were all good stories, packaged into great experiences. But then I see the mess inside and realize just how hard it was for the author to evolve it, how much time and pain and effort they've burned maintaining an script whose complexity grows like O(2^N), not O(N^2)! How much easier it would be for them, how much richer story they could deliver, if they used higher-level tools for the job.
> It's an O(N^2) problem.
In raw form, it's 2^N problem - it's all the little "visited-church_1?", "visited-church_2_night?", "ate-biscuit?" flags that are exploding. This is the part I see frequently mismanaged, where higher-level tooling would be helpful. You can build neat interactive stories with just some flags and conditionals, but what you write is limited by how much of the resulting state space you can keep in your head over time (the problems really start when you want to change something you written a while earlier).
> They usually invent game dynamics to prevent this from happening
That's a good, time-honed, high-level strategy :).
> that will end up with very boring responses when you try to make two things interact with each other, and players don't enjoy the game if it has too much of this - it kills the suspension of disbelief
That's true, and the same is also a problem with videogames with procedurally generated content (this and IF being essentially facets of the same thing). But there are ways around it, if the tooling helps you with this, and you know how to use it. That's why I'm wishing for some wider knowledge sharing of tools and techniques from the programming world, because we deal with structurally isomorphic problems every day, and have plenty of tricks up our sleeve, that could be useful for IF writers, or even managers and legislators (bureaucracy is a computing environment too - where rules are code, forms are messages, humans are the runtime).
> While Ink and Inform hide away some abstractions to make it easy for newcomers, plenty of games are written in TADS (easily the 2nd most popular language for IF), and you very much have to have a programmer mindset to write games in it. Telling a TADS programmer they need to think in terms of variables and functions is like telling a physicist he needs to understand calculus to model the world.
You're right, and I apologize here. I haven't seen TADS before. Skimming some sources downloaded from the project page, it definitely exposes you to some software development experience (including the less nice, and perhaps less relevant, parts too).
Any object can potentially interact with any other object in the same scene (or in your inventory). These languages support standard language abstractions (classes, types, whatever) - but that will end up with very boring responses when you try to make two things interact with each other, and players don't enjoy the game if it has too much of this - it kills the suspension of disbelief. As such, game designers put in a lot of effort to put in custom responses and behavior just so that the player remains immersed in the game.
It's an O(N^2) problem.
They usually invent game dynamics to prevent this from happening (e.g. making sure you lose/consume objects to get from one part of the game to the next - so that N is drastically reduced).
I hate to say it, but your comment comes off a bit condescending. While Ink and Inform hide away some abstractions to make it easy for newcomers, plenty of games are written in TADS (easily the 2nd most popular language for IF), and you very much have to have a programmer mindset to write games in it. Telling a TADS programmer they need to think in terms of variables and functions is like telling a physicist he needs to understand calculus to model the world.