Hi guys,
this might’ve been asked (very likely), but I’d like to know if there are some ballpark numbers floating around? I have a good idea of my writing speed, but in the interest of project management, it would really help me if I knew more precisely what I’m getting into with an interactive text-game. Thanks 
Word count of code or prose? Code is easier: go to ifdb.tads.org/search?searchbar=t … +available and pick a game written in the language you’re interested in. For prose there are tools in the IF Archive that can extract strings at least from Z-machine games. It’s not the full truth because there’s always some procedural text creation involved but usually close enough.
I don’t think word count is a great representation of time or difficulty in programming; it’s really your obsessiveness for detail that matters, and one can be very obsessive with detail, particularly when writing code, without adding a lot of ‘word count’. The difference between how long two programmers will take to do the same thing could be huge, and it depends on the number of scenes and puzzles multiplied by how realistic or smooth the programmer is willing to settle for making their implementation. Word count is only loosely and indirectly correlated with difficulty.
Also, in code there is the concept of ‘elegance’ — in order to achieve it programmers will sometimes spend time specifically to learn how to make the same things happen in a smaller line count. (The same concept exists in ordinary language, as Blaise Pascal famously said, ‘I would have written a shorter letter if I had more time,’ or French words to that effect.)
In answer to your question, though, the full source code (not including extensions) for my Inform 7 work-in-progress currently stands at somewhere over 66,000 words and it’s a medium-sized game that depicts traversing an area of about 9 city blocks (adding up to the descriptive equivalent of about 40 rooms), while solving 4 major puzzles — two easy, two hard, but they are all fairly elaborate geography-spanning affairs. When I have finished rewriting all the printable text (most of which was originally written as just a placeholder in order to test out the game mechanics), my word count will probably end up breaking 100,000 with little added functionality.
(Note: It’s probably even more inadvisable to compare i7 word counts with those of other IF languages, since they look so radically different.)
Well, for now I intend to write with Twine, so code wouldn’t be much of a factor in terms of length. Juhana, couldn’t find the tools you spoke about. Rather, I found some tools, but none of them seemed to be fo text-extraction.
Twine is even easier. Open any Twine game, right-click and select “view source”. All story text is at the end of the file.
It’s generally better to specify the system you’re using, especially if it’s CYOA. Otherwise people are going to assume you’re talking about parser-based games.
I was actually asking for general guidelines as to what constitutes a short/middle-length/long game, but I suppose it’s not the same across different platforms then, is it?
People don’t usually talk about it in these terms (at least, around here) so there are no general guidelines on word counts. Time-to-play is more often cited. (With two hours being the usual upper limit on ‘short’.) If you were to develop a general guideline it would probably have to be different for different types of IF, even if you did specify that the count applies to text printed for the player only and not the source code.
Hard to compare choice-based to parser-based, anyhow. In an Inform game, a lot of the game text (even ignoring code) is going to be custom responses for commands a player might not try. But then a choice-based game is more likely to have large branches that the player doesn’t select.
Also, the pace of playing the games is different, right? A frustrated IF player slows down or gets stuck; a frustrated CYOA player starts skimming and hitting links quickly. That’s a generalization but I think it’s a real factor in how the game experience varies.
Word count (and node count) are actually a pretty good way to evaluate choice-based IF IMO.
Here’s a concrete answer: for our “Choice of Games” label games, we require that the game be 50K words or more; 50K is on the small side. Choice of the Dragon is 50K words. Broadsides is 60K. Heroes Rise is 100K. Our forthcoming professional wrestling game, “SLAMMED!” will clock in at over 250K.
I find the size of the game a more accurate guesstimate of the size, or complexity, of the game. Of course that varies wildly if you look at different systems, but basically Blue Lacuna’s 5mb (Glulx) and Heist’s 350Kb (ZMachine) speak to me or large games indeed. Shade’s 106Kb speaks of a relatively medium-big game or a relatively complex one (I’ll leave you to discover which), and Conan Kill Everything’s 89kb are a nice guideline as well.
But this is nothing resembling something you can quantify. There are many reasons why a game may be the size that it is, sloppy/tight programming included. But I do find it to be a nice guideline. I generally expect bites from =<100kb, and complexity/size from =>250. But again, that’s just on the ZCode front…
Thank you for the answers, all
Zarf, very good points indeed. The skimming part is a constant consideration/concern of mine. It’s horrible to realize you’ve been stupid enough to turn people off from actually reading your text game, for whatever reason (poor design, poor writing, etc.) Many gamebooks had that problem for me; at some point I didn’t want the text to get in my way, simply because it was either poor, or non-functional, or both. The gaming part suffered terribly as well because of that, which made me think they’re simply too closely connected to allow either one to go to shit.
Dan, you’ve kinda staggered me with those numbers, tbh 
But all right, I guess it’s something to aim for, though maybe not in my first project…
Peter, I’ve no idea how file size relates to game length in Twine. I’ve seen that howling dogs is 173 passages and approximately 10 000 words long and maybe I’m up for that sort of workload, at least for now. It’s a meager 111 KB, so I guess it’s cool
Again, thanks for the answers, guys
People skim a lot in parser games too… a LOT. But they do it before they get stuck which is even worse. Whenever I try to play with someone I am often struck at how much slower I play than most people because I actually try to read everything patiently, getting involved in the atmosphere. But what most players faced with a parsered IF game seem to do is more akin to ransacking the text, exploiting it – and they try to do so as fast as possible. I think this is actually the more common style of play, so I assume any text longer than a paragraph or two will not be read for comprehension by most players unless it’s at the end of the game. If it’s a win/lose condition they’ll pick over it much more carefully.
Most games I see including CYOA would be better off with more choices and less text, considering the way people tend to actually play.
Sadly, you’re basically right. (As far as my experience with people playing interactive text-games goes, pretty similar to yours I suppose.)
It’s not the kind of experience I want to have playing a text game, also not the one I want to encourage when writing it. Will stick to my sort of thing anyway. Though I will see how I can cram some nice literary stuff in 2-3-paragraph snippets. That was a good pointer, thanks (I was getting carried away with the length of individual passages )
Well don’t let me cramp your style or anything if you really feel the need to express yourself with a lot of text that seems necessary. It’s not like I have done a scientific survey. Anyway, I don’t really blame the players for playing ‘let’s ransack all the text for clues’, when most games are designed to specifically reward unthinking rummaging, by hiding clues as if they are Easter Eggs so they can be uncovered by repetitious behaviour… it’s monotonous and it teaches people not so much to comprehend the text but rather merely to scan it for ‘key nouns’.
So it’s really more about how the rewards in a game are administered, I think, that encourages or discourages this kind of play. If all the puzzles or secret rewards in a game were keyed to require comprehension to uncover, rather than simple pattern-recognition, then it would be more fair to expect a player to always engage directly with the meaning of the text. It may be a bit difficult to relate reward-mechanism concepts to CYOA which tends to be less puzzle-heavy, but I believe it can also apply there, when cheating is possible, or for those systems that allow a complex world model.
Twine has a neat little word count feature, and as far as file size goes, I’ve heard that the non-game part (i.e. what you haven’t written yourself) is about 30Kb, and the rest of the file size is your text. Disclaimer: This could be wrong.
Well, I do intend to model some stuff in a more complex way; it probably won’t turn out on the puzzly side, 'cause I simply haven’t got a shred of experience with that sort of game-design, but still, I think I’ll switch to shorter paragraphs and a shorter story as a whole, for now at least. I’d fail at all of it if I tried anything more complicated right now Useless (or do you prefer Mostly? I dunno…), I’ll experiment with it, but for now I’m pretty happy with the opportunities Twine gives
Mr. Useless was my father, call me Mostly
Or Geoff, that’s fine too.
Twine is awesome because it just lets you write. It’s your choice when to make it more complicated (i.e. tracking variables, using CSS to change the look of a story), whereas with a parser language you have to look at the story in a completely abstract way just to make everything actually work for the reader.
Wouldn’t the simple algorithm be1. start a new twine project
I would think the “size” of a game, in terms of small, medium, or large, could also be measured in the minimum number of moves that can be used to finish the game. Are the actual numbers available for games like ‘ZorkII’ or ‘So Far’ to see what’s the fastest they can be done?
Not necessarily. A game might only require a small number of moves to be completed, but those moves could generate screen after screen of text and so take a long time to actually read/play through. Or you might have a game that requires many moves to complete it, but those moves only generate a few words each time so you could progress to the end very quickly.
Interesting subject anyway, and inevitably has got me thinking about what might be the biggest IF game (in words) ever written. Cut out all the coding and just leave the pure text, and what might that game be?