This is too late for IFComp (this year) but I had some thoughts I hope are helpful.
First, yes, I agree David Welbourn’s walkthroughs are great! If you’ve seen his Trello website, you’ll notice he fills in a lot of details. More than you as an author might want to. But you can pick and choose what works best for you, what parts of his checklist are a good use of time.
I’ve often based my walkthrough, or the first draft, on the test commands I wrote. It’s not hard to do a search-and-replace in Notepad++ or your favorite text editor e.g. replace / with \n\n> or \r\n\r\n>. (It’s also not TOO bad to write a python script tracking that these are synced between your test command and/or walkthrough.) That way, I know I have something that just barely works. The extreme case is when I’ve seen walkthroughs that go
e / n / w / etc.
And I know the programmers 1) used Inform’s TEST command (“test win with e/n/w/etc.”) which is good and 2) didn’t use much else, which is not.
I know I take into account what my testers had trouble seeing when writing a walkthrough. I think there will also be certain checkpoints where it’s useful to say, okay, you should have X, Y and Z at this point. You should have unlocked room W. This is a good place to save.
@StJohnLimbo I totally didn’t know about the details tag! That is pretty awesome. I remember wishing there was one but figuring it didn’t have enough general usefulness.
I prefer text content, largely due to searchability, but I think being able to break videos up helps a lot … someone at least knows where approximately to start. And there’s always watching at double speed. All these small features make me really want to try a video walkthrough.
Also, I appreciate (in addition to annotations) if the author says “OK, this one is one worth putting the walkthrough aside to solve.” Sometimes when I try to plow through a competition, some entries need to be in heavy-walkthrough mode, and I get the gist of them with just a walkthrough and then trying to recall the way through later.
But I’ve found some things work in terms of general process:
First, a walkthrough is worth looking at once a week. Make time for it. That doesn’t sound like much, but it helps me pull back and see the big picture after focusing on one area of coding. Sometimes the others get a bit fuzzy, and that’s good, because if I’ve forgotten an assumption I made when writing a walkthrough, I’ll find a hole in the walkthrough. Proofreading my walkthrough can also help me get back in the flow if I’ve left a game to sit. The better it is early on, the more there is to revisit and picture someone saying “Hey, that doesn’t quite make sense!”
Second, it helps to have a “gunner” tester with a week or two who might not be the game’s target audience, but they’re willing to sit down and maybe even play dumb with the walkthrough. They might not even worry about the story–just verify things work or say “you should write X or Y in.”