I did a search, but a lot of my terms are commonly used. I’m wondering about a reasonable ceiling for items in an Inform 10 project. I found this thread from 2016, but is 500 still the number? I know that Basic Inform limits the number of declared things in a room, and there are limits to what can be taken or dropped at once, but what about the project overall?
I have a bunch of different duplicates in a project, and there might be a bit of flux based on what people are carrying, have used, or have mixed together with other things. Do I need to be rigorous about my numbers, or is there a higher ceiling these days? Not that I would be careless; I’m just wondering if I need a spreadsheet for tracking things.
The previous thread (and my previous answer) was on the “becomes too slow” topic. That’s the practical question, because it happens long before any hard compiler error.
I have not tried to push the system since Hadean Lands came out. Counterfeit Monkey experience will be more current and useful.
So far compiler vs performance, my answer is “whichever comes first” which appears to be a performance question.
This probably doesn’t come up too often! I have other “duplicates” in game that I can just handle with variables, but will need actual things for 14 kinds (or more).
I’ll do an audit after every test release and get the actual counts just to keep myself out of trouble.
Never Gives Up Her Dead has a bunch of things in it, but perhaps not over 500 since that’s in 9.3 (if I recall correctly)
In that case, it’s worth noting that “slow” by 2016 standards is quite different from “slow” by 2026 standards!
The main issue on that front is the locale description machinery—the stuff underlying the LOOK action. It uses a table called the Table of Locale Priorities which has a row for every thing in the game; when an object needs to be mentioned in the LOOK output, it gets inserted into that table in O(n) time; and before printing anything, the whole table is sorted in O(n log n) time where n is the total number of things in the game.
Which is really not that bad of scaling! If your computer is two times faster than it was a decade ago, then you can use a bit less than two times as many objects without seeing a noticeable slowdown. Even on older hardware, interpreters have improved over the last decade so you’ll see improvement on that front too.
If it becomes a problem, though, zarf has an extension (linked in the linked thread) that optimizes this mechanism further. It would need to be updated for Inform 10, but it changes that O(n) and O(n log n) to scale with the number of things in the locale description, not the total number of things in the game.
Re original question, do you just mean things, period? Not duplicate things? I expect my WIP is over 1000 and continuing (on phone now, can give actual number later) but it has never blinked. This is 6m62 but I’m guessing this is a legit test unless I10 has new processing overheads.
Edit PS I’m not using zarfs large game speed up code and will try it now I know of it. However I am using his improved epistemology. And that made a noticeable speed difference. This is in a situation where I make epistemology do its scan every turn, which is not the default behaviour. Normally it runs less often. So if you’re using epistemology, I definitely recommend the zarf improved version to avoid or negate many objects + epistemology slowdown.
for me it’s mostly dupes. 30 frobs, 20 widgets, etc. But I could definitely come in under 1k without having to manage things too rigorously. Which, for better or for worse, suits my style
I would say build your game however you see fit, and if any problems come up as a result, ask here about adapting zarf’s extension to Inform 10 (or whichever version you’re using).