How quickly can you develop parser games?

[kqr]

TL;DR: Scroll down to bold paragraph.

I tried working backwards from the old Infocom games to figure out how much effort parser games take to develop based on their scope. I have gathered those games had maybe on average

• 40 rooms
• 20 significant objects
• 150 scenery objects

This works out to a density of four interactable objects per room, and two rooms per significant object. From what I understand, these games took maybe on average 9 person-months to develop. Assuming some organisational inefficiency, that translates to a development time of 20–30 hours per room. (As a rough average. Of course there were individual variations between games.)

That said, modern tools probably allow us to be more efficient than Infocom implementers; but on the other hand, modern games are significantly denser in their implementation, with more than four interactable objects per room.

Come to think of it, it’s also going to depend on the experience level of the author: my first game took roughly 30 hours per room, but I’m sure I could do the next at 25, and I have seen some of you work so fast that it seems like you can make a game at something like 5 hours of development per room.

I’m trying to work out a more modern rule of thumb of parser game complexity. If you can take a couple of minutes out of your day, please respond to this anonymous form: https://forms.gle/21TwXPTRGBLahK7w8

If you have made multiple games, feel free to submit more than one response. Please do not choose to respond for a game that you made unusually quickly or slowly – if you respond with only one game, make it a typical case!

If I get a sufficient number of responses, I will aggregate them and share them with y’all.

[Piergiorgio_d_errico]

perhaps the question ought to be reversed, that is, How slowly can you develop parser games ?

Coding an IF is basically two distinct creativeness, the artistic and the engineering (or ingenuity), deeply intertwined and outside architecture the two fields don’t mix well. (now should not be a surprise that a standard learning exercise in IF coding is implementing one’s own house, that is, a well-known architectual structure)

so, one should be with both creative mood in the same time when coding an IF, the artistic one for the descriptions, narrative &c, and the engineering/ingenuity for the code which interconnects the narrative.

I disagree with Lord Inform, because the “crossword” is more precisely the coding, because the clash lies in the two sides, the narrative and coding.

And, because is infrequent having both creative moods when coding, is inevitable that a session became devoted to narrative and another became devoted to coding. and I’m particularly prone to long pauses between session, a “stop and go” approach. (extreme case, a toy IF I recently released was written in two sessions, separated by some years, go figure…)

often I do session dedicated to narrative, and other dedicated to coding, and of course the creative mood can even shift during a session.

and one must not forget that IF are near-always an individual’s effort, one must also take account of the attrition stemming from RL issues.

so, there’s many reason which I suggest that the question should be reversed…

Best regards from Italy,
dott. Piergiorgio.

[EJoyce (Emery Joyce)]

@kqr

I have seen some of you work so fast that it seems like you can make a game at something like 5 hours of development per room.

That actually seems on the high side for a lower bound, IMO! Plenty of people have made parser games for old-school ECTOCOMP (3-hour time limit) or modern ECTOCOMP’s Petite Mort division (4-hour time limit), and it’s not uncommon for those to be multi-room. Of course, speed IF is not what you’re asking about, but if I could make a game with ~6 objects per room at 1.5 hours per room, I would believe that someone could do something significantly more fleshed-out at, say, 3 hours per room. (That said, number of rooms and even number of objects aren’t necessarily always a good proxy for complexity; there are less quantifiable things that also go into it, like systems. Something like Suveh Nux, which has one room and I think relatively few interactable objects, probably still took a good amount of time to make.)

Unfortunately, however, I can’t fill out the survey because it’s been long enough since I made my non-speed-IF parser games that I don’t remember how long they took.

[kamineko (Drew Cook)]

I think number of words in the project (code and text) might be a good way to capture effort. Portrait with Wolf has one room and seven things in it, but the project contains 33,912 words (feel free to omit it from your analysis if it skews your data!).

Disclaimer: I have tried and failed to make a petite mort game twice, so maybe I don’t have a good handle on time requirements.

[DavidC]

This is all going to be upended as people use GenAI to write code (while still writing the story text).

I could easily see larger parser games created leveraging Claude Opus 4 and more games that implement complex systems.

[billmaya]

Kay Savetz and Carrington Vanston of the Eaten By A Grue podcast have compiled an Infocom Game Specifications spreadsheet for all of those games.

I’ve only written one Inform 7 text adventure, The Time Machine. There were two versions.

Version	Written For	Developed	Words Written	Words In Game
v1.0	ParserComp 2021	August 2020 to June 2021	59,755	22,888 (38.30%)
v2.0	Spring Thing 2024	July 2021 to March 2024	67,294	45,459 (35.78%)

I spent just over 620 hours working part-time on the game (I wasn’t tracking time spent from August 2020 to April 2021 so this number is not exact).

Months	Year	Time Logged (hh:mm:ss)
January to March	2024	19:10:00
January to December	2023	157:11:05
January to December	2022	206:31:52
April to December	2021	237:39:30

I also tracked how many words I wrote each month.

I’ll fill out your form when I get a chance for each version of the game. ← Done @kqr

[SomeOne2 (Max Fog)]

It also depends on the kind of game. A game like The Weapon is about 45 minutes playtime with only one room in the whole game.

A game like mine is Milliways, which has about 10-ish hours runtime (without hints) but 60-ish rooms. It really depends on the type of and implementation level.

[Warrigal (Garry Francis)]

The original question was “How quickly can you develop parser games?” My gut reaction was about one month. However, as others have already said, this depends on your experience, your library of code snippets, the size of the game, the difficulty of implementation and so on.

I submitted one response to your survey for my most recent game, but I can’t see the stats as being very helpful.

My records show that it was started in December 2024 and finished in June 2025, so that’s roughly 7 months. However, the instigation was followed by a lengthy design period, the coding of the skeleton and refinement of the story and the puzzles, interspersed with the development of a few smaller games, a large game for TALJ 2025 and lots of testing for other people. It was tested a few months ago before I decided to enter it in ParserComp. I made a lot of changes after tester feedback, then sat on it for a while, not realising how many more issues I’d created for myself. It finished up with a very intense week of fine tuning and bug fixing before submitting to the comp. All in all, I’d say it took maybe two months of solid work, but that’s just a gut feel.

The number of rooms is easy to determine, as I number my rooms.

The number of objects is also easy to determine by counting the number of times the keyword ‘Object’ appears and subtracting the number of rooms from that. However, over 40 of the objects are floating objects that can appear in multiple rooms, so is that one object or multiple objects? The latter is harder to work out, so I assumed one object, because I’m lazy. (This is for Inform 6, by the way, so it’s not as easy to determine in other languages.)

In this particular game, there are areas of the game with a high puzzle density and others that are more like a walking simulator with wide open spaces and nothing much to do until you find an important room. A more accurate statistic might be to ignore these ‘empty’ rooms, but they still take time to code (write room descriptions, add connections, add scenery, add responses for certain things and test it all).

I used the term ‘puzzle density’ above. This is another statistic that’s interesting to consider. Puzzle density is the average number of puzzles per room. As a rule of thumb, a game should aim for one puzzle every two rooms, or better. Once again, this will vary. It’s not always easy to work out the number of puzzles. I’d say examining something is not a puzzle (although it might provide an important clue), but finding something that’s hidden might be. If one puzzle has multiple elements, is this one puzzle or several puzzles? Drawing a puzzle dependency chart helps here.

Something like the number of rooms divided by the number of nodes in the puzzle dependency chart might be a good indication of the ‘size’ of the game.

Even so, I don’t think any of this helps to answer the original question. For me, it’s anything between two weeks (Seeker of Magic) and 40 years! The latter is a game that I originally wrote in Atari BASIC, ported to Inform 6 many years later, expanded considerably, ported to PunyInform and return to every couple of years. I’ll finish it one of these days.

[kqr]

@Piergiorgio_d_errico

perhaps the question ought to be reversed, that is, How slowly can you develop parser games ?

I agree, the phrasing of the question is perhaps unfortunate. The context I left out is that I want to use this as a guide for scoping a game. If I want it to be ready a specific date, and I have some numbers of hours per week until that date, how large should I aim for the game to be? Maybe this is a judgment someone more experienced can do instinctively, but I like rules of thumb drawn from real-world data.

@EJoyce

Of course, speed IF is not what you’re asking about, but if I could make a game with ~6 objects per room at 1.5 hours per room, I would believe that someone could do something significantly more fleshed-out at, say, 3 hours per room.

Oh, wow, that’s fast.

@EJoyce

number of rooms and even number of objects aren’t necessarily always a good proxy for complexity; there are less quantifiable things that also go into it, like systems.

I agree. I just can’t think of a way to estimate the complexity of systems (maybe lines of code? but that’s hard to know at the design stage!), so I sort of left those out of the question, possibly at my own peril.

@kamineko

I think number of words in the project (code and text) might be a good way to capture effort.

Yes. Just as programming effort is surprisingly (surprising to many, anyway) correlated with line count, parser game complexity is probably surprisingly correlated with word count. The reason I don’t ask for word count is I don’t think a lot of people would be able to estimate it from memory as well as things like room count and interactable objects per room.

@SomeOne2

It also depends on the kind of game.

Absolutely does. With this question, I’m trying to capture things that are relatively easily quantifiable at the design stage, to help pick the scope for the game to fit into a deadline. As someone said, systems can be arbitrarily complex and take a lot of time, but I don’t know how I’d quantify their complexity in the design stage.

[kqr]

@billmaya

Kay Savetz and Carrington Vanston of the Eaten By A Grue podcast have compiled an Infocom Game Specifications spreadsheet for all of those games.

Thank you. Assuming the guesses I have for developer count each of those years are anywhere near accurate, I estimate they spent nearly 4600 person-weeks making games over a decade, and they released games containing some 2700 rooms during that time. That works out to about 70 person-hours per room – more than twice the 25 hours I had estimated. This production rate is also remarkably consistent over the decade.

If we assume organisational inefficiencies eats half of the time, we’re down to 30ish hours per room, so maybe it’s not too far off still.

[mathbrush (Brian Rushton)]

I’ve noticed (and at least one other coder said this in a blog) that spending more time on a parser project doesn’t always speed it up as much as you’d think. I did my largest project mostly at nights and weekends; during the summer, when the school I teach at had vacation, I thought I’d be faster, but I had roughly the same pace. This other author had a similar experience, taking time off their real job for a kickstarter of making a parser game but finding they wrote just as fast as when they had a full time job.

So it’s possible that the full time parser company that spent twice as much time per week on the games didn’t achieve twice the coding efficiency.

I haven’t found this to be true for choice based games. In writing one right now and my speed has doubled since summer started.

[Draconis (Daniel Stelzer)]

For me, the majority of the work on a parser game lies in the planning. The coding and writing is the part that I have to properly budget and plan for, because it requires time spent actually sitting at my computer and focusing on nothing else, but I’d estimate I spend at least twice as much time just thinking about it in the back of my mind, coming up with puzzle ideas and interesting concepts and structures and dependencies and so on.

Familiar Problems was written and coded in only a bit over four hours, since it was originally meant to be a Petite Mort, but those four hours came after over a month of collaborative planning and designing between the three of us. We had maps, flowcharts, outlines, lists of jokes we wanted to include…actually turning all those plans into a game was fast by comparison.

[J_J_Guest]

I filled in the form for To Sea in a Sieve, my most recent parser game and the one freshest in my memory. I referred to David Welbourne’s walkthrough for some of the answers.

To Sea in a Sieve is a one-room game with deep implementation. It took me just over two years to write. Unusually, it was the only game I was working on at the time.

It’s often difficult to say how long it took to write a game because I normally work on more than one at once. Alias ‘The Magpie’ has thirty-two rooms and famously took me eleven years to write. One year of that was beta-testing. But for much of that eleven years I was also working on Renegade Brainwave and Excalibur - if I get stuck with one project, I shift focus to another.

There are lots of factors that affect development time, such as the depth of implementation and whether the game contains complex things like magic systems, liquids or ropes. One-room games are a special case because when everything is in one room, gating and disambiguation become a major headache. To.Sea in a Sieve is a one-room game with both liquids and powders, and coding it damn near gave me a nervous breakdown, I’ve barely been able to look at Inform 7 since. The chances are that I’ve skewed your data slightly by including it.

I suspect that there’s no mathematical formula to accurately predict how long a game will take to make. But it’s really about the journey, not the destination. Good luck, and bon voyage!

[kamineko (Drew Cook)]

@kqr

The reason I don’t ask for word count is I don’t think a lot of people would be able to estimate it from memory as well as things like room count and interactable objects per room.

That’s interesting! Do you think that a non-trivial number of authors no longer have their source code? My assumption–only based on a feeling–is that almost every author would have access to their old game sources.

[kqr]

I have received 10 responses, and the variation in most numbers is too large to draw any conclusions. I’ll type a brief report here and then leave it at that.

The only thing that’s reasonably constant is the number of hours spent developing the game, which (with three exceptions) hovers rather close to 500. The number of hours spent on each game are 25, 152, 300, 470, 480, 520, 750, 900, 1913, 9375.

Other than a couple of extreme cases, the average number of hours per room is 27, which is close to my earlier estimation. However, once again, there is large variation. Ordered in terms of experience (as in prior games released): 80, 25, 19, 9, 63, 13, 480, 9375, 3, 3.

This looks like some support in favour of the hypothesis that experience makes it go faster, but it’s not really. The average for inexperienced authors, i.e. those with 0 prior games released, is 33 hours/room. For authors having released one game, it’s 38 hours – i.e. longer. The final entries of three hours comes from the same person, but two different games.

The most common number of hours per week to spend on making a game is 15. In most cases, seven out of ten, the time spent was between 10 and 25 hours per week. None spent more than 25 hours per week.

Seven out of ten responses were about games released by first-time or second-time authors.