I’ve heard about some inform games performing slow on mobile devices, and as a programmer it does bother me when I type something fairly general, knowing I’ll never need it outside of that room, and wondering; will Inform will be processing this condition with every single thing the user types? Also that may open up opportunity for bugs when this condition is applied to something I didn’t expect it to be.
Is there ways to type things that tie them programatically to certain locations, or maybe section off bits of code to only be processed per room, something like that?
Or is this generally never a problem?
I’ve searched around the forums and the web and haven’t found anything specific yet…
Generally this isn’t a problem. Look at Hadean Lands and Counterfeit Monkey, two of the largest IF games ever made, both in Inform 7, and both run well enough on mobile devices (with certain optimizations that most games never need to worry about).
What sort of code in particular are you worried about?
The tricky part about performance in I7 games is that you can write slow code without realizing it.
Obvious conditions are obvious: an “every turn” rule is evaluated every turn, but “if/when in Room X” is a fast test so you can condition off chunks of code. A lot of fast “if” conditions every turn aren’t a big problem. But one relation test might be expensive – or not, depending on the test. Optimizing I7 is really a pain in the ass and requires some deep knowledge of the code at the I6 level.
The flip side is it probably won’t be a serious problem unless you write a very large game and release it as a mobile app.
In most cases, text is efficient and with the glulx standard, most people rarely run into performance or lag-causing problems unless you’re doing something bizarre. If you’re wanting to do something like 10,000 procedurally generated rooms that rearrange themselves every turn or a large number of relations that apply to every object in the game…that’s when you need to be concerned with performance. Most authors won’t run into that. Occasionally in large games with lots of dict_entries or many new verbs, you’ll need to bump a few limitations that are set for memory economy, but Inform will let you know when that happens and it’s easily done.
If performance is a serious concern for you then it might be best not to rely on “high tier languages”. Of course that would also mean that you’d need to put in a lot more effort because then you’d have to set up many things manually for yourselves.
Still, another thing which I can’t help wonder about: the amount of influence the player / interpretor will have. I can’t back this up with facts because I’m only familiar with Frotz (which is good enough for me, so I really don’t feel like trying) but I could well imagine that other players (if those exist) might handle these source files in another, maybe more efficient, way.
That said, there’s a really weird mechanism in Glulx where interpreters are allowed to optimize certain parts of the Inform standard library. An interpreter which has these optimizations versus one without would probably show rather different runtimes for a big Glulx game.
Note that this is not accelerating anything in the Inform 6/X library - it accelerates the most commonly used routines in the Inform 6 veneer layer, which is built into the Inform 6 compiler, and provides a number of core functions in terms of Glulx or Z-Machine opcodes.