So every December, one of my sons does Advent of Code, where you solve puzzles with small programs. I wanted to do a bit of recreational programming over the end-of-year break, but bounced off Advent of Code, because the puzzles didn’t interest me.

One Monday night during Advent, I played Cyclades, by Ludovic Maublanc and Bruno Cathala, a favorite game I hadn’t played in years and have never won.

Thinking about it that night, I realized—as one does—that it would make a good BASIC computer game. Now there’s been no market for BASIC computer games since the late 1980s, you think. Exactly! This freed me up to make something more thematic and more idiosyncratic.

With free time being precious, I tried to apply lessons from my past as a professional programmer to speed things along. Somes I succeeded, sometimes I didn’t.

  • Specifications – Before writing the code, I wrote up a 1,900-word spec. Since I was the only audience for it, it was informal and at times laughably incomplete—“Computer Turn: Have the computer pick a deity and use it.” That was meant to be a placeholder but I never expanded it. I wrote up a spec because long ago I read in Code Complete that you want to work out issues at the highest level of abstraction possible: the spec, then the comments, then the code. Writing the spec first definitely saved me time.
  • Tool Selection – This I botched. I first mocked up an abstract map in Calormen’s Applesoft BASIC emulator, then realized I didn’t want to use line numbers and two-letter variable names. Next I used Google’s wwwBASIC, before remembering it has some serious bugs. The next day I used Charlie Veniot’s BASIC Anywhere Machine. Finally, I moved to QBJS for its streamlined UI. 
  • Style Guide – I hadn’t programmed in structured BASIC in 18 months (see Eighty Days: A BASIC Travel Game), and I was inconsistent in how I named and structured things. At work when we used Visual BASIC, we had a style guide. I ended up using PascalCase for global identifiers and dromedaryCase for local variables. The final program uses a few different conventions when it comes to string functions (sometimes with the final $, sometimes without) and there are other inconsistencies that I’d like to clean up (especially regarding Booleans).
  • Version Control – I should have done some sort of version control sooner. I ended up just doing daily milestones, which did save me effort a few times when I had to backtrack.
  • Technical Debt – As with a work project, I was inconsistent about refactoring code as issues arose. I’d abstract a common bit of repeated code into a new routine but not replace it everywhere, so there are a mix of approaches when instead I should have retired and replaced the older methods.
  • Test-Driven Development – I didn’t write any automated tests. I should have for at least some of the functions.
  • Bug Prioritization – I didn’t use a case-tracking system, just a list of bugs and feature requests with prioritization levels similar to what we use at work currently. And just like I complain about my dev team at work: there were times I implemented a feature rather than dealing with a bug.

The overall lesson was that approaching even a hobby project with best practices from work saved me time and effort and enabled me to get more done.

I already have an idea for what I want to do instead of the 2026 Advent of Code, working on a game I’d abandoned that I think would be very feasible in this format. 

In the meantime, you can play Cycladic League here.