LIAM JOHN DAVISON

The Future of Bascule and Cantilevers

Liam Davison
link software development

I have two CMS projects, Bascule and Cantilevers. One is old, simple, stable, and functional, which builds this very website. The other is modern, serverless, accessible from anywhere, and can just about publish its own website. The code for one is hard to test, and the other is brittle and hard to debug. It saddens me, but I think it is time to move on and retire one of the projects.

I have decided to keep Bascule. It does what I need it to do, I like writing simple Markdown files, and I like the simplicity of its project model and interface. It's always frustrated me that I need a copy of the bascule jar and a command line to generate and publish web content. However, I think with some GitHub Actions scripting, I will be able to create content from any device and have it published automatically.

Bascule needs work – in particular, the code is hard to test. I'm going to experiment with using AI agents like Claude Code to help me refactor it. There are also a few features I'd like to add, such as a microblogging, Twitter-esque short messages mechanism.

So what to do with Cantilevers, and why am I thinking of retiring it? Well, the ambition was to replace Bascule entirely with a web interface and an online runtime. The serverless, event-driven content generation loop was interesting and generally effective. But building page navigation was a challenge, leading to me introducing a database backend that I had always hoped to avoid. The queue-based event bus has been challenging to debug (and surprisingly expensive; apparently, I use about 800,000 messages a month even when I do nothing at all with Cantilevers). Building the front end (or front ends, with Android and Desktop app experiments) has never been fun for me.

Cantilevers will join the long list of 'failed projects' in my GitHub repository.

No, that is not fair. Cantilevers was an interesting, creative approach, and I learned a lot from developing it. It didn't quite work out, but I now know so much more about building on AWS, about event-based architecture, about infrastructure-as-code, about DynamoDB. A useful learning experience. Soon I will probably run cdk destroy prod, and archive the repositories. I'll revitalise Bascule. And if anyone is interested in the cantilevers.org domain name, I am open to offers!

AI Driven Game Development

Liam Davison
link software development kuiper ai games

I promised myself, and my friends, that I would no longer attempt to write a computer game. It always ends in frustration and tears. But a few weeks ago, while idly chatting to an LLM, I suddenly realised that I don't need to write a computer game any more. I can have an AI agent do it for me.

So I fired up and subscribed to Claude Code, and for the past few weeks I've been prompting my way into an implementation of Project Kuiper. First, I - or rather, Claude and I - wrote a Game Design Document. I decided to build the game for the web using SvelteKit and Phaser.JS. No weird tech choices like Kotlin & Godot this time. I then directed Claude Code to plan the development, and off it went.

Very, very quickly I had something working. Over a weekend, Claude Code had achieved all I had ever managed with Kotlin/Godot, and more. Each day, I've prompted a change, a fix, or sometimes just a discussion about gameplay. The development has been split into phases, which implement a particular feature. I've let AI write 99% of the content – the technology tree, the flavour text, the action cards that can be played each turn. Not everything has matched my initial vision for Kuiper, but I've largely been content to let Claude take the lead.

I've been especially impressed with the ability to do large refactors – the sort of thing that a human developer would shake their head at, tut, and try to avoid, not because it's impossible, but because it's a lot of manual work.

For each Phase, I state the problem or direction and have Claude write out a plan which I then review. Sometimes these are broken into sub-phases, ticked off as each is completed. Quite a few of these sub-phases are then deferred as I realise that I haven't scoped out the game elements sufficiently.

The game play is split into three Eras, each with its own game map. Era 1 is on Earth, represented as a hex grid. Era 2 heads into space, near Earth orbit, the moon and the Lagrange points, as a directed graph. I'm not quite sure how Era 3 will be represented. The first Era is now functional, though there are two core features which still need to be fleshed out. I'm keen to see where Claude and I will go with Era 2.

The game is 'winnable' by opening up a wormhole, and it's losable if climate change destroys too much of the map. Both of these scenarios are placeholders for future content.

The source code for the game is available in the Signal repository on GitHub.