This topic has come up before, but there are a lot of new people now, and I’m interested in what you guys do word-count wise.
My ‘big’ games are Color the Truth and Absence of Law, each of which are 50-60K. They both have big maps, and Color the Truth has 5 sets of descriptions for many of the rooms.
Every other game I’ve made is around 20K or less.
I know Pogoman Go was around 200K (maybe?), and Blue Lacuna has 400,000 words. Slouching Towards Bedlam, a classic IFComp-winning game, has around 40K.
I’m surprised the second one is as high as it is, though it’s got a lot of extra implementation thanks to extremely thorough work by my betatesters
The first one is slimmer in locations, but pretty hefty on conversation responses, with over 7,000 code words just for that, albeit coded in pretty compact table form.
The game I’m pulling together for this year’s comp is about 70k and is slowly trending upwards, though I was halfway through before I realized how the whole “foo/–” thing works and my conversations are coded in whatever the Platonic opposite of “compact table form” would be, so there’s probably at least 10k of unnecessary repetition.
A long way in that the code is rather light on words, indicating that there’s a lot more to do. I tend to have a small map and implement heavily. I’ve yet to add conversation, which can be almost as long as the rest of the game. I have far too many works in progress, and I’m focusing on the Twine one at present.
AlethiCorp is hard to count, being a multi-file Visual Studio project, but the game contains 34568 words of text displayed to the player (http://www.alethicorp.com/Home/DumpAllText).
Ours is just under 2 million words long according to the Inform 7 compiler. But it has been in production since 2012 and well-funded via Patreon since 2016.
only a work has 2M word (and compiles into a quarter-gigabyte .gblorb…) so I get what work is.
If I’m correct about what work is, is a collective work, and the very majority of IF works are from one brain, so I guess is a very limit case.
Actually I use its source as ultimate test of ni (whose in Linux environment gives some issues, often I posted about here, always getting insight into solving said issues)
Which is also a nice demonstration of the Glulx format’s (lack of) limitations. Address space was the biggest problem in every iteration of the Z-machine, and why new versions had to keep being created.
Glulx offers two gigabytes of address space. And the largest Glulx file in existence is at less than a quarter of that—the vast majority of which is image data, which doesn’t take up address space. So that’s a limit I doubt anyone will ever hit.
Unfortunately things aren’t quite that ideal for us. Our code is so complex (and broken into extensions for organisation purposes) that the compiler frequently runs into issues and “halts in abject failure”. Every time this happens we have to consolidate code into smaller numbers of extensions in order to get it to successfully compile again.
(True, but that’s a failure of I7 and its compiler, not of the Glulx virtual machine. In theory I7 is going to be open-sourced at some point, and then these issues should be able to be fixed.)
