Did I Just Design a Problem?

Whew. The graph looked bigger than I thought it would.

Most of the nodes will just be “sensible verb with obvious object” situations, but some of them will be more puzzley. I haven’t decided which will be which yet.

That’s what I was worried about. I guess I’ll find out soon enough.

I should probably work on the flow of the end-game more before I start designing the puzzles.


The majority of time is, I think, usually spent in devising appropriate responses for the wrong interactions, or coming up with plausible reasons why object A intended to solve puzzle B isn’t also an appropriate solution for puzzle C (especially if the player can encounter puzzle C before they solve puzzle B), rather than on implementing the “correct path”. (Or perhaps allowing object A as an alternative solution for puzzle C, but the problem with that is if objects are consumed in the process of solving puzzles, as is typical, it’s possible that the object originally intended to solve puzzle C wouldn’t be a good solution to puzzle B in its place…) So don’t forget to factor that in as well.

(On the other hand, I’ve never released a “real” story, so take this with a grain of salt.)

1 Like

I find it more useful to write down the requirements in a simple way and then make sure the game logic enforces them.

“You can get the qux at any time.” No problem.

“You need the lamp to go underground.” That’s important, write it down. Then keep track of which parts of the game are underground.

“You need the helmet, the sword, and the rope to reach the last room.” This is easy to keep track of. Maybe each of those is at the end of a chain of several puzzles – this means a lot of possible states, because the player could do any chain first or work on them in parallel. But you don’t have to worry about that.

(Just be careful not to embed assumptions in your game text. Don’t write about the sword glittering in the lamplight if the player hasn’t gotten the lamp yet.)

The main thing the graph is good for is telling you when you have a dependency loop. Say you need the lamp to get the helmet, and you need the helmet to get the wand, and you need the wand to light the lamp… that’s a problem. But you could have figured that out without the graph, really.

(There are also dependency problems that don’t show up in the graph. Alternate solutions present a real problem for graphs – there’s no good way to represent them in that format. Consumable resources are another.)


This brought up Hadean Lands trauma I didn’t even know I had.


I think LucasArts games wouldn’t allow that sort of thing. Zak, for instance, would just refuse to eat the sandwich he would need to feed the phone company’s guard dog later. Maybe that’s why Gilbert didn’t mention it.

That’s unfortunate.

Yes, but that still requires thinking of that interaction and writing a plausible refusal. It’s possible that the story system being used does this by default, but often the default message is not the most appropriate.

1 Like

Welcome to the wonderful world of parser game development!

I think you’re doing everything right: Considering the pros and cons of various languages, jotting down notes about the puzzle structure, asking questions on the forum. But you are vastly underestimating the amount of work that goes into these things.

Optimism is great for getting started on a project. Don’t feel bad when the deadline whooshes past—this could turn out to be the IFComp 2021 winner, if you keep at it!


I would agree with Linus’s sentiments. Making big parser games is hard. Adam Cadre claims to have spent 15 hours a day for 6 weeks straight on Photopia. I spent more time on a game (Color the Truth) than I did on my master’s thesis, about 200 hours.

There are other similar stories here: How long does it usually take to write an IF game?

On the other hand, Jon Ingold said about All Roads (an IFComp winner): “I wrote All Roads in 24 hours but to be fair I spent a wh[i]le after bug fixing and stuff. Probably only a few weeks tho” (https://twitter.com/joningold/status/1063055334779052038)

All Roads, though, is fairly linear, and was designed to be written faster than ‘My Angel’, his previous comp game. So I guess it really depends on your complexity you’re going for.


All Roads took 24 hours to rough out? Ye gods.

I will echo the above – I’m just wrapping up an Inform 7 game that will probably wind up being about at the Comp’s two hour limit, and it probably took me ~150 hours, including learning the language, with about a third of that testing and revision? And before that last chunk of polishing time it was pretty rough – building in lots of testing time is pretty necessary to getting a parser game in reasonable shape, I think. But I also started mine right around last year’s Comp and I was fortunate to have it lying around when COVID hit and I suddenly had more time sitting around.

Anyway, just echoing the wishes of luck regardless!


I think I read somewhere that the reason Activision shut-down Infocom was because they were spending 200 hours of development time on 8-hour games, which, I guess, wasn’t profitable.

That works out to 25 hours of man-time for every hour of play-time.

(I think it’s safe to say I won’t meet the deadline in a month.)


To be fair, it is possible to write a good short game in a short time. There’s a whole annual competion for games written in just a few hours. However, somewhat longer games tend to rank higher in IFComp, and IFComp judges are probably also less forgiving of the bugs that can only be eradicated by lengthy and thorough beta testing.


Worktime for my parser games:

  • Tingalan: ~300 hours over 2 years
  • Six Silver Bullets : ~300 hours over 2 years
  • The Dead of Winter: 24 hours over 3 days
  • I Summon Thee!: 16 hours over 2 weeks
  • Be There!: 4 hours in a single afternoon

you can definitely make parsers in any size. Knowing how to apportion the time is also important. Six Silver Bullets has a lot of “time invested” but it still drew a lot of deserved criticism because the parser was very stingy. I should have spent more time on the basics.


What about Skybreak!?

Skybreak! is approaching 800 hours of work now (I’m really hoping to get an update out sometime before IFComp). I don’t usually classify Skybreak! as a parser because there are a lot more menu options than text commands. While I dislike wading into the parser/cyoa wars it seems fair to distinguish here, because a lot of “design time” in parsers should go into the parser itself, whereas with a game like skybreak most of the options are “1, 2, 3,” and so on.

I am also about 40% done with a true CYOA/Parser hybrid which has more than 200 hours of work and which will hopefully be done in time for NEXT year’s IFComp or spring thing


One of the main reasons I switched from Inform 7 to a choice system was it significantly decreased implementation and debugging/testing time required to polish a game.

I’m the doof who back in the day would kill myself to write an entire parser game a few months before the competition. And my early games suffered severe scope and feature-creep due to lack of discipline. One thing I also discovered - even if you get your game done it’s incredibly difficult to find testers willing and able to thoroughly test during the last few weeks before the Comp if the story is of any significant length or complexity at all.

I literally started Transparent a few days before IFComp intents to enter closed, meaning I wrote that game in about a month. It appeared to be a small game as conceived, consisting of a treasure hunt through a mansion with about 16 rooms and a few outdoor locations, but if you’ve ever tried to play it, you understand the systems involved (photography, electricity, random ghosts moving around and doing things, an ill-conceived strict inventory and container system) are stupidly complicated and required tons of updates and corrections during the Comp as they were allowed on a limited basis.

(I suspect I might be the only author in history that has managed to make ClubFloyd ragequit a game because they got trapped in a room and couldn’t exit:cold_sweat:) #iswearthisshouldbefixednow

The Baker of Shireton I did a little better. I had prototyped the baking system earlier in the year, and had scoped it as a base game with optional modular pieces - meaning if I ran out of time there were significant parts of the game I could cut. I started the main game about three months before the Comp. I still had to make several corrections based on stupid mistakes that resulted due to lack of thorough 2nd party testing since parser games allow for so many emergent interactions the author cannot even possibly consider themselves.

Fair was the parser game I did the best job scoping. I intended it to be short and replay-able, and had the entire game from beginning to end planned out in my head in the months after the previous Comp, and I severely reined in any attempt to make it more complicated than about ten locations and characters. Due to this, I planned to begin writing it three months in advance with milestones and based on previous experience it went almost without a hitch…

Of course I had one brilliant random last minute idea “What if I include time travel?!?” (facepalm) which almost wrecked the entire project: that was me at 2 AM the night before the submission deadline (despite having to work the next day) carefully picking through the code line by line and taking out all the freeform time-travel to limit the game to the parts where it worked properly. Then test test test test test like a maniac since no tester was going to have time to get to that part in one day.

  • Highly Recommended habit: if you’re working with a deadline, scope thoroughly and lock down your game beginning to end and don’t add stuff. Avoid entertaining ideas that might not seem difficult like “What if I include time travel?!?” Don’t write a game with a deadline if you don’t yet know exactly where it’s going to end. That is how you get in the death spiral of scope-creep.

At this point I switched to a choice engine (AXMA) and was ambivalent about getting a game done in six months before the competition. I decided to try and get something done and chose a game I only half-heartedly thought I could complete and might not be received well.

This resulted in Cannery Vale which was done -bam- in like two months, and despite being a tremendously huge and intricate game content-wise, it behaved politely with few major problems since choice-narratives afford the author a greater amount of control over what it’s possible for the player to do. Of course I can’t write a simple branching narrative–oh no–there are systems and tons of variables and optional content. The story elements in CV were cobbled together from about four different ideas I had been thinking about for years, so it literally is a Frankenstein’s Monster type project that all managed to work out with 90% less difficulty and testing necessary.

robotsexpartymurder is another enormous Frankenstein project that pulled large elements I had already thought about for a long time, but I started that in December and it was basically structurally complete by the summer and I just had to work filling in all the text placeholders I had put in so that I could make sure the game worked first and then spent the rest of the available time frosting the cake.

My current super-secret WIP for this year was basically done last month and I don’t really know what else to do with myself for now.

  • TL;DR - Scope completely before you code and know exactly where you’re going and what you need to accomplish, especially if you’re working under a deadline. It helps to complete several smaller games in your system of choice to help learn how fast you are capable of working before tackling The Epic. A project that is amorphous in concept will never get done.


This is exceptional real world advice for aspiring authors.

Thank you for sharing!


I’m glad my sad random tales of woe are helpful to someone! Parser errors can prove amazingly difficult to track down and debug. I pushed an update mid-comp to Baker of Shireton that was a minor ease-of-play adjustment, but which caused the endgame to totally fail and I didn’t catch it until Doug Egan privately messaged me because he was in process of reviewing that game for the second time. That error took all day to suss out - the tiny mid-game thing I changed and didn’t give a second thought to affected a rulebook which rendered the finale completely unwinnable.


That’s what I did also. Not that I ever actually finished a parser game, but even my demos required quite a bit more effort than writing a CYOA game. But then I had the brilliant idea of writing my own engine which completely negated any time saved in switching to a CYOA. :sweat_smile: Ten months later and no games released; just a couple demos.

I will say that hypertext fiction games can still be surprisingly complex. You don’t have to compensate for people writing strange commands into the parser, but you do still have to ensure events happen in the correct order, or that phrasing is changed or dialogue is added to reflect past events. I have a habit of adding flavor text to the characters based on transpiring events to make it feel like they know what’s going on in the world around them, which really makes the work balloon quickly (but is worth it).


Right. Coming from the parser world makes it very difficult for me to write a “normal” branching narrative. I’ve got variables and recursion and hubs and grinding…

1 Like

Yeah, exactly. Although I think a standard CYOA may also be quite difficult. I play a lot of Choice games and Hosted games, and whenever I play them I keep thinking that the poor author must have looked like that guy in the conspiracy meme image. I’m sure you know the one.