Advice after a long hiatus from game writing?

Hi all!
It’s near the end of May, and I haven’t written anything of my interactive murder mystery since January.
I’ve got tonnes of notes, and I don’t know which of them I’ve already encorporated into the game and which I haven’t.
I’ve finally got enough time on my hands to get back to being creative.
I’m re-reading how to write in Ink (and learning bits I didn’t already know)…

… but I still haven’t actually RE-OPENED the GAME and STARTED WRITING.

Any advice? Are there build up steps / tips you’ve used in the past to get yourself back into writing after a hiatus?

Because I only really have experience at restarting by… starting a NEW PROJECT. And I don’t want to do that this time!

Thank you!


I know you don’t want to start a new project but I think a bite-sized game jam like Neo-Twiny, Neo-Twiny Jam '24 - Submit for Charity!, might be useful. Design constraints with a tight turnaround means that you’re forced to move on fairly quickly.

Or… I find myself in a similar situation. I went back to a game I haven’t touched in almost two years and it was already very, very big. So, I’ve been editing it-- going back and reading it for style and typos. That’s been a useful way for refamiliarizing myself with variables and other logic, as well as the narrative itself. Plus, it’s a productive use of my time as that’s something I needed to do on the project anyway.


This is a mood.

Unfortunately, the only advice I have is to go through the game code you have so far, and check off the stuff in your notes when you’ve noticed something was implemented.

The feeling of being overwhelmed when returning to a project and wanting to start over can also be exacerbated by not leaving enough notes to your future (and now your current) self.

Leaving notes for yourself and always leaving behind breadcrumb trails for yourself is not an extra step; it’s part of the work. Writing notes-to-self and workflow references is work.

If you have done this already, but feel like it’s not enough, then you might want to add more breadcrumbs, now that you have a fresh perspective. It’s also good to remember that re-immersing yourself in a project is never easy, but these breadcrumbs can prevent it from being seemingly-impossible, by comparison.

Also, forgive yourself for any burnout. You’re feeling creative now, and you might be tempted to detonate like a new star and get as much done now as you can. You need to pace yourself, and be methodical, especially if you and I both suffer from the same challenges of maintaining projects.

It is important to first figure out what has been done so far, sprinkle more breadcrumbs around the project, and then return to adding features/writing to it. If you accidentally burn out again, you need to provide an easier way for your future self to return to this project again, and then you need to be patient and forgive yourself, should you need to recover again.

Breadcrumbs are both a utility and an understanding that you will not punish yourself for burnout.

It’s not easy, though.


Oh I am feeling that with this WIP I’m trying to finish. Haven’t touched it in years and been dreading opening the files for months, even though I kept telling myself to get down to it.

What helped me was:

  • opening the coded file and wince of embarrassment because it is so badly written and coded. (I don’t want more people to read that version…) ← the best motivator :joy:
  • writing with a group of people. I’m in a writer’s group on Discord, and we have a Voice-Chat (where we only talk to each other through chat :joy:) every weekend to help peer pressure each other into writing a tiny bit.
  • give myself a goal of writing 100 words/editing one page a day. It isn’t much, but it quickly adds up.
  • take breaks when needed. There’s no need to force it when nothing is coming (it takes the fun out of making stuff).

(and it’s just 500 words! Any program you want to use, we also accept entries that are part of a bigger future project)

Good luck!!


I just did this!

If you haven’t been commenting your code, this is a good chance to start doing so, since you’ll be revisiting it anyway. Commenting is a great way to explain your work to yourself!

I started by playing my game and editing the text. This got me reconnected with the project as an experience. While doing so, I looked for code that could be improved (more efficient or whatever) and took on little nibbles here and there. This got me thinking about how things work in the project.

I got a list of every thing in the game and its description, then revisited the text and the function of each (I use Inform 7).

By that point, I had a list of things I wanted to mess with or improve. I used this chance to tinker with everything as a way to look at everything without having to… just read the code like a book. The end result was that I was pretty excited about things I had improved and, better, was looking forward to continuing.

e: in general, I think returning to a project can be an opportunity to look at it differently, or to see it anew


Consider time-based rather than progress-based goals, too? You have to open the game and sit there with it for 10 minutes. You don’t have to do anything scary like actually write but you’re not allowed to do anything else during that time, and then you get to check it off your list for the day.


I feel you. I haven’t written much of anything for a couple years following RL issues, a death in the family, and work schedule changes where I’m working late, which is my normal creative period. I had to basically shut off the creative process due to intruding real life, and it’s hard to get it started again.

I did write a quick speed IF a bit ago for the Really Bad IF Jam and that felt good. Maybe a small new project might prime the pump for you to get back to your WIP.

I’d recommend definitely don’t say no to a creative impulse just because it’s not the project you’re supposed to be working on. Creativity is creativity - and I’ve learned it’s best not to c-block your Muse.


This is what I do! My writing progress is very tied to momentum, so restarting a project can be dread-inducing, but if all I have to do is look at what I’ve already got, it takes the pressure off. Even if I do no actual writing for days or weeks, it’s still way better than nothing. And then sometimes I find something cool I wrote that I forgot about, and maybe this part would be better with a few edits, and I should probably start a list of things to put in this section…and suddenly there’s that momentum again.


I agree with advice to open the game and play it. The most motivating thing for me is to start playing, and within a few minutes I’ll always hit something and be like, ‘oh, that’s an obvious bug/missing response/empty area, I can fix that,’ and that gets me back in the groove. Just playing and fixing the number one most obvious problem; in fact that’s almost my entire writing process, and it often works better when you’ve taken a long break, since you have a fresh perspective.


As everyone knows, for me stop-and-go is the norm in my coding.

personally, what matter with breadcrumbs isn’t the quantity or the sprinkling, but how and where are placed around. That is, in the source. Some working examples from a known long-term project can, I hope, explain in a practical matter the concept:

// imp SMELLing them (the most prudent approach to the unknown...)
beverages: Thing 'beverages; beverage; beverages; them' @mcabinet
"These are unknown beverages, of this world."
tasteDesc = "You don't know if these beverages are poisonous [...]
in all, at the appropriate moment, here are three means for igniting our 
daemon ;) at the appropriate moment: first, and rather improbable, [SPOILER], second, [SPOILER] and third, and fallback, [SPOILER]*/

// TODO: format the adprose.
// major TODO: edit the lists, giving a better continuity.
/* Azuj WILL fire a little (?) comment about relatives, with her usual pride 
when her family and heritage is involved.. */

the last “beadcrumb” is, for who read my dev diary, for the next major phase of coding; of course, there are also not few notes like // tb improved, //add appropriate adprosing, // decide what about are, then imp the books. and so on…

HTH and
Best regards from Italy,
dott. Piergiorgio.


Always, always leave a project in a playable state. That way, you can come back much later and play it like a fresh beta tester would. Occasionally, that’s when I say, “This is crap” and throw it away. More often, I see how I can cannibalize parts of it into new project because the whole reason I quit it was because I liked the puzzles but not the story, or vice versa. Maybe now I have a new story idea that I like a lot better that those puzzles will work great with.

After I play through it, it’s easy to look at the code again and be able to read it, even though I’m not great at annotating. The fresh direction gets me motivated and I like performing surgery on a failed game, lifting out the elements I like and plugging them into something new.

I’ve never put down something I really liked and not finished it, though. If I’m really digging what I’m doing, I’ll finish it. But I have about 10 abandoned games in the file of shame, because there’s something good in there that just needs to get a fresh perspective on how to use it.

I guess all this is to say-- don’t exactly start a brand new project. Look critically at your old project and see if giving the story or the puzzles or the tone or the theme a facelift will get you jazzed to reimagine the old project into something newer.


Also known as the Id Software method. :grin:


I like to spend time with the story/game spark–the part I was most excited about or what really got the ball rolling for the project. Keeping that locus front of mind helps motivate me and serves as a guide for what I can cut and what I should keep from my original efforts.

Good luck with getting back into it! May the muse find you easily and bring you a nice cup of tea


Do you consider amnestying them ? :wink: as you noted, code reuse helps, and can help others…

On leaving the source in a playable (and by implication, compilable) state, I note that serious bugs can always be commented out, and with a comment note explaining how and why is bugged, and this can led to unexpected bug-solving later (sending bugs & issues in the backburner works wonders, trust me)

Best regards from Italy,
dott. Piergiorgio


No. My code wouldn’t help anyone. It would, however, provide a lot of amusement. It would be like those videos of dogs falling down stairs which I laugh at even though I shouldn’t. I keep them because I think there’s something in them I can use.


I actually create a word document, broken up into sections, where I keep notes. I have a section for locations, NPCs, Stats, Game Settings, Enhancements, etc. Under each section, I make notes of things I’d like to incorporate into my story or document how processes will work.

As I code, I find it useful to highlight the entries I’ve completed, or coded, in green. Entries I’ve decided not to use, I highlight in red (I keep them in the doc in case I change my mind and decide to use them later). Anything I’m currently coding, I highlight in orange.

Before incorporating this system, I was typically “all over the place” and found it frustrating, confusing, and very inefficient. This method of documenting the items in a single document and using the colors to track progress has been a game changer for me.

As others have mentioned, it’s wise as well to document your code.

Good luck with your project!


Out of curiosity, what language(s) and editor(s) you use ?

On entries I decide not to use, I comment out first, then move into a “scrapbook”, together with comments and notes on the whys of being not used plus on how it works, because reusing code is always the “Right thing to do”.

a friendly warning: NEVER EVER declare an entry/code “completed”. that everything is always to be improved (and debugged…) is a golden rule in coding and world/story building, trust me.

Best regards from Italy,
dott. Piergiorgio

1 Like