There's a gap in the godot ecosystem - how best to manage addons.

The recommended addon flow dodges the command line, which tells me it's targetting non coders. This makes sense from a whole team perspective - you don't want your tool to be inaccessible to artists and musicians who may not care to learn CLI basics.

But software engineering is all about dependencies and libraries. I want it to be easy to improve an addon that a game depends on (multiple games, probably) without fuss.

I've hacked this with symlinks before, but things broke when trying to get more users (or another of my machines) running the game. Then I added commands to make this 'easy' (just install java, clojure, and babashka, you artist, you!).

This led me to vendorize everything, which basically means don't .gitignore your addons, so your team members can download and run the game without fuss.

Lots of tradeoffs happening here, not sure the best solution yet.

For now, I'm working on all my games in a single project: a godot monorepo called dino. It's full of addons and games, and I can work on all of them in one place. The overhead then shifts to managing independent builds/exports/deploys, and so far that has been fairly smooth. We'll see where it breaks, but I think it's been excellent for my growth - I'm getting alot more done in less time, and getting to easily reuse and improve patterns as we go. That reuse/improve part of the cycle is important - most addons are not worth creating and isolating when you first have the idea, so giving them a chance to be consumed by multiple games shapes the public interface before I got sharing it elsewhere. Love me some monorepos!

Backlinks