Time invested in your games?

I can totally relate. I think that’s why it’s good to sort of aim for a deadline for motivation, and IFComp is good for this. I’ve done the “write an entire game in three months” scramble, but have had the best luck and motivation going “IFComp is in a year, I’m going to program my brain to hopefully work this out before then” for me gets the creative juices flowing. Most of the games I’ve written fast have been in my head for years and it takes me going “Here’s a concrete deadline I’m going to try to hit” for that last bit of proddy-motivation.

What doesn’t work is going “Oh, I’ll think I’ll enter this amorphous concept for IFComp and figure it out as I go…” without knowing the last half of the plot or game. I was on a streak entering IFComp every year for a while, and part of that was knowing I had almost a year to get the next thing out. Once I learned what kind of game and amount of material I could produce in a year’s time helped loads with scope. A huge part of that was transitioning to choice-engines that allow more author control and don’t require months and months of play-testing and debugging.

…And unfortunately, the only way to figure that out is to finish and publish several games. That’s why I always recommend new authors start small because you’ll learn the most seeing both goalposts instead of always just starting on a hat and never finishing a hat.

TL;DR: I’m always writing in my head, and part of the skill is knowing when to pluck one out of the roiling stew pot and go “YOU! YOU SHALL BE MY NEXT MASTERWORK I SHALL CLEAN YOU OFF AND PREPARE YOU. LET US MAKE READY over the next six months…


Oh, I feel seen. Actual notes from the Sting quote-unquote design doc:

Sudden, contextless pain.

establish conflict – cursing/banter throughout – potentially success.

(Fall 97. maybe more focused on liz? Across the quad. Or trying to talk to her – choice of who to talk to, then sting interrupting and necessitating trip to health center. No, fake out, too shy, and also Liz back from France so want to hang out a little. No)

Multiple stings. Main thing is unhappiness.

And one that I still have absolutely no idea what it could possibly mean:

Women named Michael.

On-topic – it’s also really hard for me to come up a total number of hours, but same as many others, when I’ve been really in it, it’s been like two-four months of continual work, probably 2-4 hours most days with more on weekends. Now that I have a small kid, though, I’m having to figure out a different model since that’s not really a viable approach for me right now!


I’d say ~100 hours for the smallest project (GBVB), and ~700 hours for the largest (Skies Above).


Lately, I’d average it at about 45 minutes a day for a given week. But yeah, when the games go into the year+ zone, it can be difficult to really track time.

Very much the same here.

Beyond the obvious parts of this—nobody sits down and immediately starts implementing stuff the second they have an idea, unless they’re doing a game jam game or something—I usually end up spending a certain amount of “deliberate” time “just thinking” about the design.

What I mean here is that there are sometimes problems (either abstract design problems or more technical programming problems) where I’ll identify a problem and decide that some approach, call it solution A, is how to solve it. Then, after a little time spent trying to code it up it turns out that there’s a problem with solution A, and the workaround is solution B. So then work begins on solution B…but after some work it turns out there’s a problem with solution B, and the workaround to that is solution C. And then in time it is revealed that solution C has a problem, and the workaround looks like solution A…

When I get stuck in a “design loop”, or whatever you want to call this kind of thing, I usually just push the keyboard away and either do something else for a while or just “work” on the problem without actually working on it, if that makes sense.

There are some problems where it’s impossible to get a handle on everything without sitting down and actually implementing at least a rough draft of the solution, because that’s the only way you can figure out how all the parts are going to actually fit together. So you can think and theorize and ponder and none of that really matters until you can actually start turning it into a tangible thing because only then do you really learn its size and shape. But on the other hand there are these other problems, ones which seem to defy a “just implement it” approach because at every stage the next “obvious” step always ends up leading you in circles and the only way to figure that out is to take a step back and consider the big picture.

That all aside, I also tend to treat large components of any programming project as separate projects and usually spin them off as their own thing. So for my current TADS3 WIP I’ve already written a half dozen standalone libraries/modules that I only wrote because I wanted to use them in the game I’m writing, but I didn’t write them to only implement the specific game I’m current working on.