I’ve been playing around with Inform 7 for a bit and I really enjoy the engine so far, it’s quite neat, I’m asking this more out of curiosity than anything else, so hopefully someone more experienced in Inform can answer.
What are the limitations, at what point do games start to become slow?
This is with the assumption one is using Gluxle, which I know allows for a lot more.
Basically, at what point would a game start to become noticeably slow? What would that actually require?
How many “complex” objects could exist in one game? How many complicated characters with complicated AI? Have any of you encountered a problem like this?
As a bonus question for anyone who has used Tara McGrew’s dynamic object extension, how resource intensive is that?
I’d love for anyone more experienced in this to satiate my curiosity as the answers I’ve found while looking up are from a long time ago now, and I’ve been told Inform 7 has much better optimization now.
Purely anecdotally, I’ve only noticed it getting slow when I’ve had a lot of pathfinding going on. Lots of instead rules will not slow your game down, unlike once upon a time.
There’s only one game I’ve seen be noticeably slow while playing, and that was the legendarily-large Anchorhead. While compiling and testing though, having too many Before rules that affect multiple or excpetional actions (like > 80) will slow the process down to a standstill in the current version.
That makes sense, I figured pathfinding would probably be one of if not the most resource intensive things in IF. How much would you classify as “a lot”?
I’m fairly sure that what I was doing was poorly optimized; that is to say, not at all – doing multiple pathfinding computations where it only needed one. I had a sound propagation model which was propagating far more than it needed to.
In Inform yes, in software development in general, no, where they can be a much lighter weight and expedient alternative to a parser. But since Inform has a parser built in, regular expressions are less useful.
Yeah, the tone of the docs feels like they’re pretty much in Inform because some folks would come to it with the expectation that they’d be able to use their regex abilities in Inform too.
Heavy use of scope-modifying rules (such as deciding the concealed items of), or heavy code in such rules, can slow things down, as these rules are invoked frequently.
This has some helpful things to check while coding to reduce load. I haven’t had noticeably slow code yet, but I still do these just in case.
Also, if you’re coding through the IDE (application), periodically deleting irrelevant parts of the Skein (or all of it if you don’t use it) helps when running the game for testing.
Everyone’s posts above have now pretty much mentioned all the potential points for slowdown now. If this was your first post, and you also hadn’t heard of regex, I think you’re pretty safe to not be worrying about them yet
They tend to be things that can be solved when they occur. i.e. They’re not deeply systemic in terms of code volume, except maybe using heavy relations. Pathfinding, regex, these tend to be small bits of code you write, that get used a lot, and if you find they’re slowing you down, those small bits need to be rewritten to be more efficient, or less trigger-happy.
That second point especially. If we look at two of the biggest Inform games, written over a decade apart, Counterfeit Monkey (2012) and Never Gives Up Her Dead (2023) – both had slowdown where a big part of the fix was just narrowing the circumstances in which heavy pathfinding and relations/regex code (respectively) was run.
No, that’s in all things. But that part from the Inform handbook – I think the repercussions of it are mostly gone due to increased efficiency in Inform itself, and maybe the endless speed up of computers. In other words, it’s true that all Before, Instead and After rules run are checked every single turn, but the checks now go so fast it makes no difference.
@Dannii ran some test on this because I was harping on it for years. I can never find the darn outcome when I need to cite it. But that was the outcome.
I think @mathbrush is typing as I’m typing. You can look at his Never Gives Up Her Dead thread to see some real life work on speeding up his huge game just last year. Debugging game slowdowns
I had a game with 2140 things and 260 rooms, and there was a scope-checking rule and another rule about ‘if there is a tied thing’, where the definition of tied checked if there was something tied to the first object, etc…
and it had 1-2 second delays for each command. That’s the limit that I hit. Rewriting to limit the use of scope and to just iterate over all tied things in a list instead of checking ‘there is’ sped things up.
I don’t know the exact file size, but it’s got a large map and a lot going on and (in the packaged version I got from Steam) was noticeably slow with command processing.
And yeah I’ve had compilation slow down enough that it was taking upwards of ten minutes, and several times where it halted altogether, which required major optimization overhauls.
Yeah absolutely, I’m not expecting to encounter such an issue any time soon, I’m still working on small bite sized projects to learn the engine.
What I’ve gathered and learned from all the replies is that basically, things that happen a lot and things that cover a lot are the big culprits, which makes sense.
I’m certainly going to look at the thread, pretty cool that I can just see some of the live development of such a massive project, IF seems kind of unique as a community in how open it all is.
