Heya everyone, I got thinking that I’d like to hear from more experienced developers on this topic. IF as a medium has some upsides to developing for it compared to some other game types, due to the text format some things are much faster to develop in theory.
But, IF games still take time like anything worthwhile, and I’m curious as to what you’d say the biggest time sinks actually are! Is it the polishing stage, bugfixing, or just getting the prose right? I’d love to hear it. Is there anything that actually caught you off guard in terms of difficulty, good or bad?
I’ve never written anything but IF, so I have no frame of reference for comparing it to other types of games. But EVERYTHING takes a lot of time. Planning, implementing everything in the game fully, figuring out how to code things, predicting what players will try, getting the prose right, designing puzzles, testing… it is all incredibly time-consuming. Everything is always more difficult than I think it’s going to be. I’ve written four long games and numerous shorter games and each one is an absolute beast of difficulty. I keep waiting for it to get easier but it doesn’t.
The upside to all this is that IF is better than any other form of game if it’s done well, so trying to do it well is worth the pain.
Personally the overwhelming majority of my dev time has been spent of engine-like instead of game-specific coding. Things like needing a crafting system, procgen map generation, or a way of handling NPC actions such that they’re subject to precisely the same constraints as the player’s actions. Implementing the game-specific stuff that uses those things also takes time, but it’s a fraction of getting the basic mechanics working in the first place.
While the topic is “IF Development,” I can only speak about my very specific experiences writing with Inform.
One joke answer is that whatever part I like least will feel the most time consuming. Of course, like any good joke (let’s hope), there’s truth to it. The parts I don’t like are mud to get stuck in. They sap a project of vitality. They require commitment. There’s a temptation to ignore or skimp. A heavy one, sometimes.
A more serious answer is that freedom takes up a lot of time. People expect–reasonably–customized messages for common rule responses and errors. But how far do I take that? What if a player wants to lick everything? Is it one lick response, or a few? The only stopping point is wherever the author says “enough.” Otherwise, it’s lickable nouns all the way down.
I’ve made a few games that some people have liked. I guess some of that comes down to the writing, or to my ideas, but I would say that any success I’ve had has a lot to do with being willing to commit to an iterative testing process. I mean going beyond bug fixing to listen to what people are saying about story, tone, themes, puzzle design, everything. Adding suggested features when possible. All three games that I’ve released could have been released six months earlier, but I spent that time listening to people and taking their advice when it made sense for me.
So far as writing goes, that can take up a lot of time. In Portrait with Wolf, I wrote every line of text at least twice, just trying to get it right. Some parts more than that. But I had to do that, as the game demanded that. Some games are going to require more time on the coding side of things. I think one right answer is that the parts of a game will require whatever its design requires. If somebody wants to make a game full of liquids and ropes, that’s going to take a ton of time.
It would be interesting to know how long it takes people to make their games! I’m not sure I’ve seen many people post about that.
Hm. I feel like each of my IFComp games took four to six months (Leadlight and Six). And the first of those was made without any knowledge of this community, or IFComp, or how long other people took to do such things.
My WIP (5.5 years and counting, but with faster development rate after I Kickstarted and committed more to it) has 9 chapters so far. I feel like the average of each chapter is another IFComp’s game’s worth of material, some being smaller and some being larger. But with it being a single narrative with multiple PCs, I’m dealing with technical and writing issues that didn’t exist in my previous work. Progress doesn’t feel speedy, but I expect I’m being quite efficient if I think of it has having done at least the work for 9 IFComp entries in 5.5 years.
Milliways took what seems to be 9 months, but I was working on it basically every day for at least an hour or two. I had a lot of free time!
My WIP I’ve been working on now for what seems to be a year and a half, and if I’m correct, I’ll be working on it for about another year. I had lots of periods of not working on it for weeks at a time, though, and even though I have been working on it for what I’d say is so far an equivalent amount of time to Milliways, it’s a much more difficult project.
For me, always always polishing and bugfixing. My games tend to be fairly complicated when it comes to code and mechanics and then barely ekes by (if at all) when it comes to writing. I don’t make game with particularly good writing, and so that takes very little time at all. To be fair, I don’t really make games that NEED as good writing. (Or, with Milliways, I thought it was good writing … )
My point is, for me, bugfixing and polishing is - no exaggeration - about 95% of the time.
due to the text format some things are much faster to develop in theory.
IMO it’s more due to the fact that some IF engines give you a lot of purpose-specific tools to work with out of the box, especially Inform 7 and Twine’s Sugarcube.
Not to speak for the creators’ intentions, but the closer that you use these engines to how they were intended, the less time you’ll spend on every step of development.
This is true outside of IF, too, of course. I’m not much of a coder, but making eg. a platformer by modifying an engine’s built-in template is faster than making the same game from scratch. And it’s also less time-consuming than trying to turn said platformer template into something it was never meant for.
Then again, there is some fun in dumping time into pushing limits, I guess.
Let’s look at my current WIP. It looks like I started notes in January 2024, with the idea bubbling around for months before that. In April this year I had a chapter mostly done (out of 10), some tech prototyped in the previous year and had got my accountability buddy on board. We had suggested a week per chapter, plus some tech time, plus some design time, plus some slack time, to take us up to an August deadline.
This was… optimistic. Life is cray. Writing is hard.
I’m currently at 20% written with a current sprint underway (doing about 5% a day). It’s maybe achievable.
My previous project, Hand Me Down (post-mortem here), took about a year of regular work, with a week-long and month (?) long sprint in the final 6 months. That required a lot more coding as it contained a TADS 3 game, a straightforward Twine game, and a storylet-based Twine game. I wrote the straightforward bit in a week, then rewrote it in a week. The storylet structure took a few weeks, but was tough, complicated writing.
Compare to One True Love, a game I wrote for SmoochieComp in about a week or so. That was just Twine with a storylet structure, but it was simpler.
There are a lot of variables in these numbers. Sometimes a game needs to simmer. Sometimes you can just bang it out. Sometimes the gameplay is a lot more complex than you expected. Sometimes you rewrite something multiple times.
Although my own experience is now a bit dated, I’d emphatically say it depends on the format. The most time consuming thing for Twine games I feel is styling and layout. I think the programming part is easy compared to the effort I have to put into websites written in, say React or Angular - even if they are mostly static and the JS is really just for making them look pretty.
In contrast, Inform in my experience is all about actions you anticipate the player will do which you don’t think they need to do. It’s an unwinnable situation for the author, really, because the possibility space for these is endless. I always end up spending way too much time on stuff no one will ever notice and at the same time go through rounds and rounds of testing for the edge cases that arise from creative use of the game elements, playing whack-a-mole with bugs I introduce by trying to cater to every approach imaginable.
@AvB: That’s one advantage video game devs have over parser IF devs, unless you’re going for a super advanced sandbox where everything is a physics object, a video game dev can just code the actions they intend the player to use and most players will be happy to figure out how to make the best use of the limited toolkit provided… meanwhile, parsers are just open ended enough to give players an expectation that their out of the box thinking should work… probably doesn’t help how often out of the box thinking is the intended solution to a parser puzzle, so parser players are already primed to think in a way as likely to land on something the dev never considered as the actual solution.
I do confess, JS and look pretty in the same sentence made me cringe… then again, I’m strongly of the opinion that JavaScript is abused to hell and back on the modern internet and should be reserved for programmatic aspects of a webpage that actually require it and that layout and appearance of a webpage should be kept to HTML and CSS as much as possible… and I also hate the trend towards making everything an overly complicated web app.
I think it probably really depends what your strengths are—while I can be particular about prose and tend to rewrite sentences/self-edit a lot in a way that sometimes slows my progress, I do have a lot more experience with writing than with the more technical end of things overall, so I would say on the whole the writing/editing tends not to take as long for me as implementing any kind of moderately complicated mechanic, especially taking into account how much time I tend to spend debugging such things.
Coming to interactive fiction from more of a “fiction” than an “interactive” background also means that I have an irrational aversion to explaining game mechanics too explicitly because I’m like “oh, I don’t want to break immersion by making it feel too obviously game-y!” and then that inevitably ends up being something I have to spend a lot of time on in revisions once I get feedback from beta testers (and even then the finished product usually errs on the side of being too opaque, but “what things do you always fail at as an IF dev” wasn’t the question, so, uh, moving on!).
Regarding how long my games have taken to make, I don’t think I’ve ever spent more than maybe 3-4 months of active dev time on something, but I’ve also never made anything that took more than 3 hours to play and all of my longest games were coauthored, so in terms of person-hours you can double that time probably. I do have an ambitious project in mind that I’m probably going to do solo, so it will be interesting to see how that goes.
The shortest time I’ve spent on a game was 3-4 hours for my three ECTOCOMP(/Petite Mort) entries. Two of those had a little extra time for planning and brainstorming that didn’t count towards the timer, while one (Die Another Day) was pretty much done in one sitting on the day of the deadline without any advance planning, so I think it really wasn’t much more than 4 hours that went into it total. My speed IF games are always really mechanically simple (since, as mentioned, I can write a lot faster than I can code) but I’m always right down to the wire anyway because I’m too wordy.
Edit: Although I mostly work in Twine these days, I don’t find styling particularly time-consuming at all. It’s actually kind of hard for me to imagine that being the most time-consuming aspect of development unless the game is very short and/or the CSS is very fancy. Although I can imagine it might feel that way if you were previously used to working in a system where you didn’t need to do it at all and/or if you really dislike doing it.
IMO it really depends on the game, especially where it’s submitted. A 500-word entry for the Neo-Twiny Jam has taken me anything between 3h to 1-2 days (and that’s mainly because I mess around with the Interface or I’m testing a new engine). The expectation is different for… let’s say the IFComp or the SpringThing (and even then, lol).
I’ve had a now-dormant WIP I started back in 2021. The Trials and Tribulations of Edward Harcourt took me and MelS about 4 years, working on and off. I’ve made DOL-OS for the French Comp in like a month, and Jeangille in two weeks or so.
One of the strengths that I haven’t heard talked about yet is the tight-knit community that IF has. Most video game development systems have extensive documentation and pages upon pages of forum threads you can use. Because IF is so niche, it’s common for there not to be an answer to your question online, but it’s perfectly acceptable to ask the forums and get 3-5 responses tailored to your specific needs, as well as a couple of sources to look at for more information.
You can also get detailed feedback even as an “indie dev” (which we all are) through the thoughtful reviews left behind during comps and jams. The overlap between authors and players is fairly significant, so finding testers, asking reviewers for suggestions, etc. are also doable without awkwardly yelling into the digital void.
This community is so welcoming to both authors and players and I’m forever grateful!
I think what I’ve said in the past is that Repeat the Ending took eighteen months and approximately one thousand hours to make. That’s not a completely accurate number of hours, of course. It doesn’t count sitting in parks. Or staring into space instead of watching a movie. These things tend to take over my thought life.
Marbles, D, and the Sinister Spotlight was an on and off effort. I started soon after Spring Thing 2023, but I had distractions and then a bout of major depression. Honestly, the thing I spend the most time on while making IF is mental illness. It’s a tremendous drain of my resources. I did get my fire back late last year, and was able to release it for Spring Thing 2025. That’s nearly two years chronologically, but in terms of hours I’d say I spent ~600. The scope changed late in the project; the cat actions and scoring were very late additions.
The shortest amount of time I’ve spent on something was the ~450 hours required for Portrait with Wolf. I think I started that in August 2024, and I had it ready in time for Spring Thing 2025. That was a highly iterative work; I had something “finished” after a month but I didn’t like it at all. Things were changing up until the end. I had to learn some very rudimentary regular expressions along the way, and that certainly ate up some time! I think I made the same game maybe four times, each version better than the last (I hope).
All of my released games were aimed at IFComp or a limited speed-IF, so none of them technically took longer than 8 months, but I’m that stupid person who has made a snap-decision to enter right as the deadline for intents was closing, so some were made in maybe 3 months, often to their detriment if it was a parser game that should have been tested a lot longer.
For me, choice games take a lot less time and testing which is why I switched. With a choice-engine the extra works happens when you want to make it more complicated than a TimeCave/non-linear game.
The biggest time-sink for parser games other than testing for me personally is developing custom systems that interact with each other in often bewildering and surprising and must be tested thoroughly by the author and hopefully lots of testers. The baking activities in Baker of Shireton took a lot of time, as did photography/electricity/light switches in Transparent - plus a traveling goal-oriented ghost NPC who could interact with objects and light sources.
I have found if you scope very well before coding it takes less time. I thought about Fair for an entire year and the main game took 3-4 weeks to code since it was short and time-limited. The most intensive sessions on that was when I deviated from scope and tried to add another system on at the last minute that broke the entire game and I had to overhaul it quite close to the deadline.
The most time-crunchy productive period I had was doing one room in Cragne Manor and then building Cannery Vale in two months for IFComp. The only thing that made that work was Cragne was a group build and we were supported by Jenni and Ryan overseeing the code and its parameters and there was no shortage of testers since there were 80+ people all working and engaged with it at the same time. Cannery was my first choice-game entry and the fact I didn’t have to stress-test it for unexpected parser commands really cut down the production time.
I tried to write Psychomanteum in three hours for EctoComp but hit a wall. A year later I opened the code and instantly saw exactly how to fix it so after like 2-3 more hours the game was finished and entered in the next EctoComp, so technically this tiny game took me a year and six hours to complete.
TL;DR: A lot of your best work can often be accomplished in your brain while not working directly on the game.
My one real datapoint is at Code frequency · rileypb/GalaxyJones · GitHub, which shows me working on Galaxy Jones for 5 weeks. My other games I worked on longer - Crash because I basically rewrote it after my first round of testing; and BOSH, which I wrote over the course of 2.5 years on and off, and which evolved significantly as I worked on it. I wish I had better records of BOSH development. I have old versions, but they weren’t in GitHub.
What takes the longest? Bug fixing for the most part, but also as people have said, any very technical systems. The two-room extension cord in BOSH was a huge pain and had to be completely rewritten at one point. One of my testers, if I recall correctly, suggested I take it out.
For me, it was a lesson learned rather late which is with interactive fiction I can make things textual instead of systematic. I can describe things happening and create interactions through words, but don’t always have to program those interactions.
I would go further and say that that’s almost an implicit assumption in the tools. I’m nowhere near as familiar with I7, but in TADS3 it’s absolutely the case that the engine assumes that player actions and NPC actions are categorically different, for example. If you want to have an NPC smell a flower, for example, you’re obliged to either insert this as flavor text without touching any of the builtin mechanics involving the >SMELL action, or to rewrite large portions of the library to accommodate the possibility that the action may be taken by an actor other than the player.
The implicit assumption that the player will be the only thing in the game required to “play by the rules” (and so have to deal with restrictions on movement and in-game knowledge and so on) is the single thing I’ve probably spent the most development time wrestling with.
)