Walking Into It postmortem

All my IFComp entries before had been in Inform. It was comfortable enough to perform a lot of neat tricks. But I always wanted to do something non-Inform. I actually originally thought Walking Into It (WII) would be an EctoComp Petite Mort game back in 2019, which was absurdly ambitious. You would run into your former self and play tic-tac-toe with it, and the conversation would make more sense the second time around. Quitting would cause a huge paradox or maybe make you dumber or less curious about the world around you, or not as persistent in solving things.

I ran over the four hour limit quickly. Getting the code to recognize similar positions to work sunk me. The usual trick of working stuff out in my head to fit in the four hour limit had no chance, though I did manage to input a lot of the kid's moves and have a functional, if buggy, prototype. So I put WII aside. Also, it wasn't called WII then but Tic-Tac-Toe. Creative, I know. I'm glad I took the time to let it develop, but I'm also glad I made that initial push, because I got a good deal done, and I thought up some good ideas. Some won't get implemented until post-comp, but that's life.

I did, however, put it aside for 18 months before seriously reconsidering entering it in IFComp. Sandcastle Master gave me the idea: an adult humoring a kid by giving them a quest. It reminded me of WII's "let the kid win if they think well enough and make it plausible." Maybe the kid realizes it later. But it still, well, counts and makes them happy. I couldn't do anything as colorful as Sandcastle Master. But it convinced me the idea had worth. Also, the game I really wanted to write had slowed down.

Not having to do anything in a compressed time period helped. I added actual options. I learned about classes--I used one to replicate a board, with moves and solutions you found. I used Python LINT until I got a perfect 10.0 score for my code, which also taught me some coding practices to use elsewhere. I'd used auxiliary text files a lot for my own projects, but here I used it heavily and for progressive text chunks. For instance, in the credits I'd have tab-separated text

txtary    credits    Thanks to stackoverflow for helping me with so much cool coding stuff, enough so I would be confident writing a Python text adventure.
txtary    credits    And thanks to everyone who's been even moderately successful with a homebrew IFComp or Spring Thing entry. It all gave me the confidence to try a project in something other than Inform or Twine.

This would allow me to say print_text_dump("credits") in the code and thus separate actual coding changes from game text in my commits.

I had a few other firsts: changing a GitHub repository name (I did so on July 14th, and once I did, I felt less embarrassed about asking for testers. "Test my Tic Tac Toe game please" sounded like all sorts of terrible begging. I guess I knew the text felt generic. I think labeling it WII also helped me flesh out more of the story. Titles work that way.

Testers turned up the usual typos as well as suggestions like "Hey, use inform's randomization if you can!" This seemed like an excellent post-comp suggestion and one I very much want to do. A later one was "it gets annoying calling the kid 'the kid.'" And I realized I was sort of annoyed by it too but I couldn't think of a good name -- I was still attached to the original EctoComp "the kid is you" story -- so it required a couple pushes before I said "hey, wait, why don't I just randomize unisex names?" And it was a really fun break from more technical stuff.

I had a scare or two, too. I realized it was possible to achieve the same winning position whether you started from a corner or edge. This created a problem, because if starting at the corner and edge led to win A, and the edge could also lead to win B, starting at the edge and finding win A would lock you out. Fortunately I found a way around that with an opportunity to learn more. It's always a good feeling when you can overcome those huge roadblocks, whether technical or creative.

Big mistakes? Well, I forgot to annotate one seemingly redundant piece of code as necessary for Python 2. Then I didn't really look into Python 2 testing. I also missed something for Python 3.6--it's a pain to go through all the versions--and I should've been more explicit about the versions tested or, at least, found a way to download them all. This sounds boring, but sometimes the fear of something boring is more draining than the boring stuff, and by now I should trust my ability to find new testing wrinkles to stop things getting boring.

I also think I got too hung up on trying to keep WII below 1000 lines, because I wanted it to be short and tidy, and I wanted to code economically. But the problem was, with each new feature I added, I felt a bit obliged to trim the code elsewhere, which got tougher and tougher ... until bug hunting became both about "uh oh there's a bug" and "well I want to chop the code elsewhere." I saw through this silliness before it was too late, but it still cost me time.

And I think I hampered myself from doing fun cool stuff at the expense of "boy, I hope this is technically right!" One example was not implementing quitting until very late--I'd thought off and on about different messages depending on how much you'd lost properly, but it just seemed so whimsical compared to Getting Things Done.

I also didn't do enough in the big picture, obviously--that Python 2 regression crept through, and I had chances to fix it. And even if people don't use Python 2 much, it's still a good idea to back-port.

In fact, I think dealing with the technical aspects too seriously put a dent in my efforts to make cover art. I didn't find it until 6 weeks after the initial release, near IFComp's end. It wasn't until I recycled a topic in the authors' forum from previous years ("sanding the bottom of drawers"--thanks, Mark Marino!) that I finally had an idea. Chalk on a sidewalk with grass was obvious. But I didn't know what game to choose and put on the cover., who took what squares. It became obvious once I said, wait, put an O in the corner ...

Here having two EctoComp games I wrote cover art for helped. I'd grown to feel a bit more comfortable using freeware textures. So I had everything but what the tic-tac-toe game should be. I still can't verbalize how that balance of pushing yourself and then relaxing and taking a step back works. But it does, eventually. I had a goal of actually being able to draw something, but what I have is the next-best thing.

I left a lot on the table for a post-comp release. But once IFComp is over, it should be easier to pick off. I have to confess I was so glad the game got some decent reviews that once I did I relaxed and said, hmm, you know what else would be neat to add? And it was a pretty neat brainstorm. The current list is here. Some of these, I should've tried to sneak in, and I had time. As-is, I wrote up the more technical options and features, because even though I wanted to write a game in Python, I didn't see it as a gaming language. (Writing FreeCell to learn it originally doesn't count. FreeCell is not original.) I had a hard time pulling my technical lessons and goals with python away from my creative ones, until it was too late. Well, for IFComp.

But for all these misses I'm proud of writing a compact game that seemed to help breathe new life into something I'd guess people don't think has many possibilities. It brought up a memory I couldn't quite fit in: being at a hospital when I was 5, and a 7-year-old playing game after game of Tic Tac Toe with me, and he never lost, but I drew most of the time, which I counted as a victory. Then later seeing the classic trap (X plays corners, O plays center then a corner) I wondered if there were others. I didn't create a full AI, but I enjoyed constructing the branching bits and the text/data file to tell what the kid should do, as well as the code to detect rotations. I just wish I'd gotten to the fun bits sooner.