I had a kernel of an idea for July's game while looking at my board game collection, looking for inspiration - finding a mechanic which might be interesting to adopt. In my collection is Waldschattenspiel - a game which gets players to hide in the shadows cast by a tealight, in order to navigate a forest:

Source: Wikipedia

The game is one of those fantastic rare board games which does something with the physical world, rather than just relying on tokens and cards. It's also a somewhat novel idea in abstract, and I thought it could be interesting to iterate on for a web based game. I also wanted to try to stretch my abilities and work on multiplayer, and this felt like the perfect excuse. I slapped together a basic demo using Kenny's Top Down Shooter asset pack. The result was... playable, albeit uninteresting to look at:

It didn't give me quite the same feel as I enjoyed from the game, rays of light and shadow cast around. So I went looking for more inspiration around this, and stumbled on Sight and Light, a page on how to create light effects. This was exactly what I was after. You don't need to trace a ray for every pixel, as light only ever changes shape at the corners of walls. A ray cast at the end of each wall, and one either side gives you everything you need to draw a beam of light around the corners. Sorting the hits by angle, join them up, and you have a polygon. My version keeps the walls as a flat Float64Array of segments and reuses its buffers between frames:

for (let i = 0; i < segs.length; i += 2) {
	const a = Math.atan2(segs[i + 1] - py, segs[i] - px);
	angles[n++] = a - RAY_EPSILON;
	angles[n++] = a;
	angles[n++] = a + RAY_EPSILON;
}
angles.subarray(0, n).sort();

for (let i = 0; i < n; i++) {
	const dx = Math.cos(angles[i]);
	const dy = Math.sin(angles[i]);
	this.#cast(segs, px, py, dx, dy);
	points[p++] = px + dx * this.#hitT;
	points[p++] = py + dy * this.#hitT;
}

This also means it applies perfectly to Canvas. That can become a Path2D, and it's a clip region in Canvas. The rest is just drawing the pre-rendered tiles underneath:

ctx.save();
ctx.clip(this.#lightPath(map, eye, radius, cacheId));
ctx.drawImage(this.#art.floor, 0, 0, map.worldWidth, map.worldHeight);
this.#lightWash(ctx, eye, radius, monster);
ctx.restore();

The visibility polygon becomes the core mechanic of the game, it shows the player exactly where they can be caught.

Drawing the rest of the owl

You might have noticed I settled for a dungeon style theme rather than the forest theme of Waldschattenspiel. Having an explorer escaping from a monster inside a dungeon felt compelling, and enough of a deviation so as not to totally rip-off the board game.

This game also can't be a solo game. Waldschattenspiel can't be played single player, a computer can use AI, but the social aspect is what makes it compelling.

The board game has a fixed map, but I felt like a digital version needed a map generator to keep it from being too repetitive, so it generates rooms and corridors, in a way which tries to breaking sightlines. Maps are seeded with a mulberry32 PRNG, so a map can be replayed, debugged, and the algorithms tweaked. The first iteration made large open rooms which worked badly for the line-of-sight mechanic, so slowly through a few iterations I managed to find a good balance: corridors stagger between axes rather than running as a clean line, and rooms get pillars dropped in them. Then a final pass walks every row and column and drops a pillar into any straight run of floor longer than six tiles. This gives enough variety for an interesting set of maps:

Multiplayer

A huge part of this work was around multiplayer, and getting something working with WebRTC. I implemented a whole bunch of changes in HTMLGameKit and a new signalling server, so that the next game gets multiplayer by writing HTML.

WebRTC is great for peer to peer but it can't find the other browser by itself, so it required servers to bootstrap the connection. There's a bunch of machinery around ICE & STUN, and for connections behind NAT they need a TURN servers. All of this was new to me, but I slowly pieced together a Rust server to make this easy for htmlgamekit developers. The signalling server talks JSON over a WebSocket to handle bootstrapping WebRTC, with a variety of messages.

"Rooms" are six character codes you send to a friend, and they expire after a few minutes of silence. The queue is for an open lobby, so a game registers its slots (Dungeon has an explorer and a monster; another game might want two reds and two blues), players join with a preference, and the server picks a group that satisfies the slots, scoring candidates by a blend of geographic distance (from a GeoIP lookup, so you get matched with someone nearby) and rating spread. Ratings use Glicko-2 which seems like a good ranking system based on my research. The rankings update only when both players report the same result, and stored per game in SQLite along with room history.

For a small game like this, it might be overkill to have a full ranking system and WebRTC handoff (for a handful of kb of data per game), but this was built with the idea it could be used in more games and this one becomes a proving ground (I have a few prototypes which I'm building out using this too!). What took the real effort, as ever, was the unhappy paths. Tons of testing for killed tabs, lost connections, mobile networks. So peer connections heartbeat over the WebSocket every couple of seconds, so if a connection is lost players can know about it. All of this hopefully makes the next networking game way less painful to build.

All of which means the game itself has very little to do. Dungeon is deterministic: given a seed and both players' plans, both browsers compute the same map, the same moves, the same winner. So nothing about the world ever needs to cross the wire. The whole game protocol is three messages:

/** Host tells the guest which match, which map seed, and which role. */
export function startMessage(matchId, seed, hostRole) {
	return { v: PROTOCOL, t: "start", matchId, seed, hostRole };
}

/** Guest sends its locked plan for one turn. */
export function planMessage(matchId, turn, steps) {
	return { v: PROTOCOL, t: "plan", matchId, turn, steps };
}

/** Host releases both plans once every actor has committed. */
export function resolveMessage(matchId, turn, plans) {
	return { v: PROTOCOL, t: "resolve", matchId, turn, plans };
}

The "plan" is the users turn, it's at most five strings of up, down, left, right. The host holds onto both plans and only releases them together, so a plan never leaks early, and both sides run the same resolveRound on the same input. Could it be gamed? I mean sure, there are lots of ways to cheat, I'm not trying to make it impenetrable, just to ensure good faith players can have fun.

Go play it. If you find a map with a long, dark corridor, send me the number.

You can probably pin my age down as a millennial, by reading into my inspiration for games; I grew up in the Bullfrog era which was dominated by RTS and FPS games, two genres enshrined in the PC era of Mouse & Keyboard. Occasionally I dare to look above the parapet and peer beyond my own presuppositions, and take a view into what's popular more generally. I've been fascinated by the boom of "friendslop" as a genre of games. Games like RV There Yet, PEAK, R.E.P.O.. The emergence of this genre, as I understand it, is the result of Roblox gamers aging out of that game but still desiring a social and serendipitous experiences and don't mind low poly or (some might say) low effort aesthetic. The gap in the market created, and subsequently filled. Similarly, as I'm writing this, I watch my partner - a recent Unpacking completionist - play through The Librarian, and realising there's another genre that doesn't exist in my experiential canon: the cosy organiser game. A genre demanded by a different generation, one who seeks to decompress after a stressful day with something rote, simply but carnally satisfying. A sense of order among the chaos. These games have no fail state. Nothing chases you, nothing runs out, there's no competition, no antagonist. The whole loop is "here mess, make not mess", the reward is the mess going away.

Both of these genres seem worth exploring, and I've been working on adding multiplayer capabilities to HTMLGameKit, but it's proving more difficult than I anticipated, and I needed to get a game out for August, so mumblecore organiser it is! I set to work building one of these - but expressly an homage to my childhood - and end up with defrag, a game where you, the player, manually defragment a hard disk drive.

The disk

The whole model is an array of clusters, with three states: free, used, bad. The map fits at least 600 clusters (more if the window has room), four of them bad sectors; the level picks everything from a small table:

const LEVELS = {
	easy: { fragments: 8, maxRun: 3, fill: 0.6 },
	medium: { fragments: 14, maxRun: 4, fill: 0.7 },
	hard: { fragments: 22, maxRun: 6, fill: 0.78 },
};

Those are Drives C, D and E in the "Select Drive" dialog. The game keeps one extra number, firstFree, which is the index of the first free cluster from the top. Everything before it is "optimised"; a block is only allowed to move if it sits past that line:

#scan() {
	const i = this.#cells.indexOf(FREE);
	this.#firstFree = i < 0 ? this.#cells.length : i;
}

#movable(i) {
	return this.#cells[i] === USED && i >= this.#firstFree;
}

Players move fragments into the free space. Grabbing any used cluster picks up the whole run around it, and it can be dropped on any stretch of free clusters it fits in. The grab offset is preserved, so if you picked up the third block of a four-block run, the third block is the one that lands under your pointer. The disk is done when every used cluster sits before firstFree.

Generating a convincingly fragmented disk took more thought than the game itself. My first attempt was single-cluster moves with holes punched at random, but it looked like noise than a disk, and wasn't very satisfying. With some tweaks the generator now looks more like:

[solid prefix][gap 1][chunk 1][gap 2][chunk 2] ... [gap n][chunk n]
[free][run 1][free][run 2] ... [free][run n][free tail, with bad sectors]

It rolls n gap sizes between 1 and maxRun. Chunks get smaller as they go. It then shuffles the same n sizes and scatters them into the tail as the stray fragments, with the free space between them getting larger as they go. This means it remains solvable; just rewind that process. It also means we can work out the optimal path, by simply counting moves.

Sound

I sampled this hard drive sound for the ambient noise, and tried simulating the clicks of a hard drive to get the "defragmenting" noise, so I had more control of the timings and pace. Every block written gets a burst of three to five clicks, each a few milliseconds of noise through a bandpass filter with a tiny low thump underneath, and each block's burst is pitched a step above the last:

const step = Math.min(1 / 12, 0.5 / Math.max(1, blocks - 1));
for (let b = 0; b < blocks; b++) {
	const rise = 2 ** (b * step);
	// ... bandpass at (2200..3700Hz) * rise, thump from 180Hz * rise down to 60
}

So a one-block fragment is a tick, and a six-block fragment is a little climbing rattle. The pitch rise is there to try and give the player a sense of satisfaction that they completed a long run.

Go play it.

I spent June working on a new mini game: Wire Loop. It's a buzz wire game - the one at carnivals and science museums where you guide a metal loop along a bent wire without touching it. Steady hand, hold your breath, and if you graze the wire it buzzes and you lose a life. It's something simple and fun for kids to play, not too cerebral (unlike the last few games).

It ticks some boxes I've not yet really explored. The mechanic is dead simple: drag the loop from the green start to the gold end. A five-year-old understands it instantly - no tutorial needed. It's also challenging, it's got that one more go pull, because failure is always feels like something you did wrong, and if you could just get better, then you'd succeed. Simple effective game loop.

Crucially for me, it's endlessly iterable. I can add levels forever, each one a slightly meaner bend than the last, and I can pour time into juice: sparks, screen flash, a buzzer sound, a gold pulse marching along the wire to show you the path. Good practice for making a game that actually feels like it could live on an app store.

Of course I couldn't resist in making it a programming challenge. The piece I'm most pleased with is how levels are authored. All levels are loaded in via an svg file, and each <path> in the svg represents a level. That's it. The wire you trace is literally the d attribute of a path element.

I started with the first level, the simplest thing imaginable, a straight line:

<path d="M 10,50 H 90" />

The next one bows into a single arc, then a double S-curve, then sharp zig-zags, then a tight loop-the-loop:

<!-- level 2: one gentle arc -->
<path d="M 11.331,49.834 C 32.697,15.9 69.917,18.248 90,50" />
<!-- level 3: a double curve -->
<path d="M 10,50 C 24,80 36,80 50,50 64,20 76,20 90,50" />
<!-- level 4: sharp zig-zag -->
<path d="M 10,50 30,18 50,82 70,18 90,82" />
<!-- level 5: a tight loop -->
<path d="M 10,50 H 40 C 55,50 55,32 45,32 35,32 35,50 50,50 H 90" />

The whole difficulty curve is just me drawing progressively nastier paths in Inkscape. No code changes to add a level. Reordering the difficulty curve is as simple as re-ordering the SVG nodes - dragging one group above another. I also don't have to do any curve maths. The gameplay needs to know, for any point in time, where along the wire the loop should be, and how close the player's cursor is to the centreline. That's a lot of bezier evaluation... except the browser already ships a bezier engine behind getPointAtLength and getTotalLength.

So I parse the SVG, drop the paths into an off-screen document so they have real geometry, and sample them:

const doc = new DOMParser().parseFromString(text, "image/svg+xml");
const svg = doc.querySelector("svg");
// Paths need to be in a rendered document to expose geometry.
svg.style.cssText = "position:absolute;width:0;height:0;opacity:0";
document.body.append(svg);

const path = svg.querySelector("path");
const len = path.getTotalLength();

// Sample the wire into normalised 0..1 points -- no curve math here.
const norm = (count) => {
	const pts = [];
	for (let k = 0; k <= count; k++) {
		const pt = path.getPointAtLength((k / count) * len);
		pts.push({ x: pt.x / 100, y: pt.y / 100 });
	}
	return pts;
};

Any bezier, arc, or polyline Inkscape can draw "just works", because the sampling is the browser's own path implementation. Levels are easy to iterate on, and stroke-width does double duty too: it's the corridor tolerance and the hoop radius. A wider stroke is a more forgiving level. So the one number that makes a level look easier also makes it play easier, which is a nice bit of the medium matching the mechanic.

Because a level is a self-contained bit of SVG, some really nice features fall out of this, almost for free. Editing levels in Inkscape was fine but it was a few hours work to add a level editor. Drawing a path in the browser, then serialising it back to a <path> was straightforward, then base64-encoding those to make shareable levels was trivial. Edit a level, copy the link, send it to someone, and they play your level. Of course this then enables me to trivially (and shamelessly) steal the best levels and incorporate them back into the game!

This is exactly the kind of lesson I want to carry back to the RTS. Not the SVG specifically, but the shape of it: make level data a first-class artefact that tools and gameplay both consume, and pick a representation that makes authoring cheap. The faster it is to make a level, the more levels get made, the more you can iterate on feel.

Go play it, and if you make a nasty level with the editor, send me the link.

Another mini-game this month: Wordn't. It's a parody of Wordle, but the answer is a word that doesn't exist. You guess a made-up word (wuzblef, say) with the usual style green/yellow/grey feedback, and when you crack it you've earned the right to define it. This combines a few interesting ideas I had around a "meta game" with a social aspect, and also trying to make games that get people to laugh, and maybe get them to make others laugh.

The guessing game is a few evenings of work on top of HTMLGameKit. The whole thing is declared in HTML. The front-end is the easy bit, though. Two other pieces are where it gets interesting: where the fake words come from, and where the definitions go.

The whole game hinges on having a word that looks like English, is pronounceable, but isn't real. wuzblef is fair. xzqhpt is not. Getting that right turned out to be its own little project. For this I built words.htmlgamekit.dev which acts like a "Words as a Service" for little word games. I generated a bunch of word lists of real words, in various themes, and also generated a bunch of fake words.

The fake words are built offline by a script that generates them phonotactically rather than randomly. It has pools of English digraphs and trigraph (bl, str, th, ee, ou) and assembles words from these. It also adds prefix/stem/suffix combos (un- + stem + -ing), and so on. Because it builds from genuine English building blocks each word "feels" real, and is pronounceable, rather than just random letters.

Then it filters hard. A candidate is thrown out if it's actually a real word (checked against the other sets in the system), or if it's a truncation of a real word (prud is out because prude exists), or if it has ugly patterns: triple letters, four consonants in a row, no vowel. What survives is a word that could be real but isn't. Each one gets fake but plausible metadata baked in too: an IPA transcription generated by a grapheme-to-phoneme mapping, a made-up etymology ("Old Norse wuzblus, meaning rough or coarse"), a syllable count and so on. Of course, the aim of the game Wordnt is to generate definitions, and I am sure the community will come up with much better definitions than I could, which is part of the excitement that inspired me to get this one shipped.

Serverless

The serving side is a small Rust service, and it has a property I really like: it stores nothing. The wordlists are compiled into the binary at build time (include_str!), and the word of the day is a pure function of the date.

The daily pick is essentially:

let day = day_of_epoch();           // integer days since 2025-01-01
let seed_hash = hash_seed("wordnt"); // per-game seed, so each game differs
let raw = (day.wrapping_add(seed_hash) as usize) % n;
let idx = permute_index(raw, n, seed_hash ^ n as u64);
candidates[idx]

It was important to make things sufficiently random between games (seeds) and days, but also stable, so that the day+seed can be replayed. The permute_index tries to randomise such that consecutive days don't give you neighbouring words in the list. Day N and day N+1 scatter to opposite ends. Effectively, it's a shuffle without storing a shuffled list and blowing up memory or having to use a database.

So the game has no database, no cron job writing "today's word", no state to back up. Every player worldwide gets the same word on the same day because they all compute the same function. Ask for ?day=-1 and you get yesterday's; ?day=1 refuses, because you can't compute the future without waiting for it. The word service is stateless, and so, it turns out, is the definitions service.

The definitions are the other half of this. Wordn't has user-generated content, voting, per-day threads, moderation-by-crowd... but still zero tailored backend.

The definitions live in messages.htmlgamekit.dev, a dumb little message-board service I'd already built for HTMLGameKit. It does exactly one thing: it stores short messages in named groups, and lets you vote on them. The entire API surface is four calls:

// post a definition
await fetch(`${MSG_API}/${groupId(word)}`, {
	method: "PUT",
	body: JSON.stringify({ body }),
});

// read them back, best-first
const { messages } = await fetch(`${MSG_API}/${groupId(word)}.json`).then((r) =>
	r.json(),
);

// vote
await fetch(`${MSG_API}/${groupId(word)}/${direction}/${msgId}`, {
	method: "POST",
});

A day's definitions are "the messages in group wordnt-wuzblef". No per-game table or authentication. The wordnt- prefix namespaces it away from every other game that shares the same board. Adding definitions to a brand-new game is one function that returns a string.

Even the submission form leans on it. The <form> in the result screen has method="PUT" and action="https://messages.htmlgamekit.dev/m/...", so it would almost work as a plain HTML form post. I do intercept it in JS to prefix the word type ("noun", "verb", ...) and redirect to the definitions page, but the shape is just an HTML form pointed at a URL. The medium doing the work again.

For the finishing touch I did end up writing a cron-job, it pulls yesterdays top definition and posts it to bluesky and mastodon. Occasionally there's one that makes me chuckle enough to repost.

So, go play Wordn't, solve the word, and leave a definition. If it's good, it'll rise to the top, and maybe get a re-post from me.

Right. Enough about other games, let's get back to the RTS. The construction pipeline was almost complete when I left it. So this week I sat back down to re-orient myself around the code, and finish up some of the rough edges.

Mostly small refinements, but a few new features. I added building demolition. Select a building or construction site, hit Delete, and it begins tearing down. This was tricky, as buildings can be demolished mid build, so Workers need immediately released and set back to idle. The navmesh obstacle also gets removed so units can path through the space again. The structure transitions to a DemolishedSite -- rubble with a configurable timer. When the timer expires, the rubble despawns. Definitions can also specify a demolition_refund -- a map of resources returned to the player.

(
    demolition_time: 5.0,
    demolition_refund: { "wood": 50.0, "gold": 25.0 },
)

Not the most interesting development, but hopefully I'll have something more interesting now this system is more refined.

This week saw a new game shipped - CSS or BS on April 1st - a quiz where you're shown a CSS property name and have to decide if it's real or made up. It felt like a good April Fools' gag but it turns out CSS is weird enough that it's genuinely hard. This has been in the works for around a month, while building out HTMLGameKit. I really tried to focus on "juice" for this one.

With a few games shipped now I've been sketching out what to explore next. I have a bunch of ideas pulling in very different directions.

I'm trying to explore various mechanics, to see what can fit. One direction I've been exploring is some kind of meta-game. Can the community become part of the game itself, not just a leaderboard bolted on at the end? I've been sketching something where the creative act of playing is as important as the logical one.

I've also had a post on the back-burner for probably 6 months, writing a performance in csskit. This has lead to another game idea to make the post more engaging. A bit like What's My JND - this takes a core concept from the post and turns it into a puzzle game. Pedagogy seems to be good inspiration for games: "how can we make this concept more intuitive to learn". Looking at games like Satisfactory, Factorio, and co, where they take logical concepts and apply them in abstract is a super interesting direction to explore. It's satisfying when you find an elegant and engaging solution to explain a problem. There's a whole category of puzzle games hiding in the things we take for granted about how computers work.

I'm also exploring a completely different direction: narrative games. People seem to have enjoyed the sarcastic or even satirical humour in my prior games, and maybe this is "my voice". I'm trying to lean into this for a third game idea, where I've been thinking about what a text-driven game looks like in 2026. I'm having a lot of fun with it. It's closer to interactive fiction than anything I've built before. I've been sharing early demos with friends and getting a kick from their reactions.

I've also been exploring audio a lot more. Learning about the web platform's AudioContext APIs and trying to slowly incorporate a bit more audio juice in my games. But I've also been wondering what a game looks like if you strip away the visual layer almost entirely and lean hard into sound -- not as accompaniment but as the primary interface. Designing for the ear rather than the eye is a constraint I find genuinely exciting, even if I'm not sure yet what that looks like. I've made some very early prototypes, but they're not great.

Not all of these will get built. But having a pipeline of ideas with very different shapes means I can pick whatever fits my energy on a given week. The RTS is still in the back of my mind. I want to come back to it with some renewed energ. But for now, the rhythm of smaller games feels right. The web is just such a great platform for experimentation, it's so easy to share something by handing someone a URL, and watching the fun people have with these if filling me with joy.

Last week I talked about stepping back to ship smaller games. While I will absolutely be continuing to develop an RTS, I think building small simple games will be a regular focus, also. This is for a couple of reasons:

Firstly, I love shipping stuff. Getting lost in work for months on end can be draining, and disorienting. Shipping something tight, getting feedback, and iterating can be very appealing. Having a venue to take concepts or ideas and explore them in a constrained way can help refine them for a bigger platform. Getting stuff in the hands of players is always a fantastic lesson that can feed back into the larger, longer projects.

For example, working on What's My JND pushed me into lots of research. Learning about Psychophysics, difficulty curves, and building a staircase difficulty algorithm to "find" the point of difficulty for the player. Something that stuck with me ever since playing games like Left4Dead is the concept of a difficulty director and how the game would try to maintain a continued pace for the player, by choosing to spawn enemies or ammo depending on how well the player was doing. Games that adapt to how you play fascinate me, and having a cheap way to prototype that seems useful.

Secondly, and naturally flowing from that, is I want a place to experiment, prototype. Bevy is wonderful and I enjoy building the RTS but it's also a learning curve. I want to get to the point where I can build a simple game in a couple of evenings, to test out a concept easily, then take those concepts into the RTS.

So with that, I've built a mini framework: HTMLGameKit - a Web Components game engine for building browser games declaratively in HTML. The idea is that simple games should need zero custom JavaScript. You compose a game out of custom elements: a <game-shell> manages the state machine (intro, playing, between rounds, results), <game-timer> handles countdowns, <game-quiz> handles multiple-choice, and so on. Events bubble up from game components, signals flow down from the shell. No build step - pure ES modules.

HTMLGameKit has a few progression strategies built in: fixed rounds, adaptive staircase (which ramps difficulty based on pass/fail streaks), and tiered difficulty with promotion and demotion. This is the kind of work I want to easily prototype out here in the framework, then bring back to the RTS as a more fully fleshed out concept.

I've built out a games page, showcasing the handful of games built so far: What's My JND and its hard mode from a couple of weeks back, Hue Shift - another colour-matching game - and a couple of older word games built during the "Wordle" craze: Cyphle (Wordle but with substitution cyphers) and Neardle (Wordle but with Hamming distance). They're all small, all free, all web-based. I've got some more in the pipeline, too.

The RTS isn't slowing down. But having a space to ship small self-contained games to explore mechanics feels right. Each one is a chance to explore a single mechanic or idea in isolation - difficulty curves, input design, scoring feedback - and carry those lessons back into the larger project.

Ugh, over five weeks since the last update. Not for lack of thinking about it. Just no progress on the RTS.

After getting the trait and buff systems in, I started thinking about how the map or level system might scale out. Given an RTS relies on maps, a map editor felt needed. The game needed proper authored levels, and placing things in RON files wasn't going to scale. So I went looking at how other games solve this.

First stop was Hammer and TrenchBroom -- the Quake/Source-lineage editors. They're great at what they do, but they're built around brush-based BSP geometry, which isn't really what an RTS needs. I looked at how they handle entity placement and terrain, but the mapping from "place brushes in 3D" to "place buildings and units on a navmesh" didn't feel right. Having said that the community around these editors is astounding. bevy_trenchbroom seemed like an interesting library to explore more, but not for this project.

From there I looked at other engines. Godot's editor is impressive and its scene system is flexible. Unity's tooling is polished also. I looked through demos and tutorials, and toyed with the idea of building out a map editor within my game, but quickly realised this was a gigantic undertaking. I spent a while thinking about whether you could build a level editor as a Blender plugin, exporting scenes to RON or glTF, since Blender's already good at placing objects in 3D space.

Then I found skein, which might just fit the bill. It lets you edit Bevy scenes directly in Blender, round-tripping data between the two. It was early but it felt closer to the right shape of solution. With Blender installed I started working through various tutorials to get more comfortable before committing to a pipeline.

But I also took this time to step back a little. I'd been building systems - traits, buffs, construction, animations, pathfinding - without ever finishing a playable thing. I needed to land a simple game to scratch that itch. Aside from building games I also spent a lot of time in the world of CSS. As part of this I wrote a long post about CSS colour precision, and decided to take a break from the RTS and refocus on smaller, shippable games. I needed something for readers of "Too Much Color" to viscerally feel the difference, the interactive demos in the post were interesting but I wanted something more fun, so I iterated on a prototype game.

The first iteration was more interactive: two different colours, side-by-side, drag one colour to match the other. It didn't quite hit the mark, which taught me a valuable lesson: iterating on something playable as early as possible can help establish if the core gameplay loop is actually right. What I ended up with was something more subtle: What's My JND -- two adjacent colours in a sharp gradient, where the goal is to click the transition point. Over a pint with my colleague Jake, he suggested 9 colours where 1 is different could be a good gameplay mode, so that evening I iterated on a hard mode variant that removes the gradient crutch. These were fun to build, satisfying to ship, and a good reminder of what "done" feels like.

The original game has received over 4 million hits in 2 weeks, hit the hackernews front-page, made it onto Tom Scott's newsletter, and had some copycats, which all feels like as good a metric of success as any.

The RTS isn't abandoned. But I want to come back to it with better instincts about scoping and finishing, and maybe a clearer picture of what the minimum playable version actually looks like.

This week's focus was around construction workers. Previously construction sites just ticked progress on their own. Now they track which units are actually working on them via a ConstructionWorkers component, with a ConstructionThroughput model that accounts for diminishing returns as more workers are added. It uses an exponential saturation curve -- one worker always gives 1.0x throughput, but adding more yields diminishing marginal gains based on a configurable coordination_drag parameter. Workers are detected by proximity once they've arrived (no Path component + within range), and are automatically released when the site completes.

This actually became part of a larger system, which includes all kinds of traits that units can have, expressed via their definition. For example, up until now, units had a hardcoded speed field and a can_construct_sites boolean -- fine for getting things moving, but not a foundation that would scale in interesting ways, so I replaced it with something more flexible: a D&D-inspired trait and buff system.

As its core is a TraitKind enum -- Movement, Construction, Attack, Defense, Perception -- with each kind backed by a TraitValue that tracks a base value, buff total, level bonus, and a computed effective value. Each trait gets its own Bevy component with a matching name - generated via a macro.

Trait definitions are loaded from a definitions.ron file that controls per-trait behavior, things like stacking rules (additive vs highest-only), RNG ranges for checks (0 for deterministic, 20 for a d20-style roll), and buff clamping. For example, Attack uses HighestOnly stacking with a d20 check, while Movement uses Additive stacking and is deterministic:

// Definition for the "Attack" trait
(
    kind: Attack,
    name: "Attack",
    rng_range: 20,
    default_dc: Some(10),
    stacking: HighestOnly,
    max_buff: Some(30),
),

Traits also buff. Each Unit can have many Buff components. Each Buff component carries an id, a trait kind, a value, and metadata about its type (permanent, temporary with a duration, or proximity-based) and source. All buffs get collected up into the matching trait, which computes the effective value, with all the stacking rules and logic and such. Practically this means units can have a base Attack of, say, 10, but effects in game (garrisoning, proximity to allies) can temporarily bump that by 5, whereas the units level might permanently raise it to 20.

Ah, yes, leveling. Units can also have a LevelConfig component with XP thresholds and per-level trait bonuses, plus XpRules that define how XP is earned -- the Builder unit for example earns Construction XP while actively constructing:

// level_config definition for Builder unit
level_config: Some((
    thresholds: [0, 100, 500, 2000],
    level_bonuses: [
        (level: 1, trait_bonuses: { Construction: 1 }),
        (level: 2, trait_bonuses: { Construction: 2, Movement: 1 }),
        (level: 3, trait_bonuses: { Construction: 3, Movement: 2 }),
    ],
)),

This is all conceptually a little vague but it feels like a good system to grow into. Traits themselves are easy to add (a macro makes this as easy as define_trait!(Movement)), but their curves are endlessly tweakable via definition files, meaning no recompiles to balance units.

This week was spent getting animations working. The Quaternius model comes with a set of named animations, but getting them to play correctly in Bevy turned out to be trickier than expected.

I decided to load the full GLTF asset then hook up animation names to definitions.ron, so e.g. a unit has idle: "Idle_Loop", moving: "Sprint_Loop" so it was "just" a matter of running these.

The bigger challenge was timing. In Bevy, when you spawn a SceneRoot the scene's children - including the AnimationPlayer - aren't available immediately. They're spawned asynchronously. So any attempt to play an animation right after spawning the unit would silently fail. So I implemented a two-phase setup: first a NeedsAnimationSetup component waits for the GLTF to load and builds the AnimationGraph, then a NeedsInitialAnimation marker waits for the AnimationPlayer to appear in the entity's children before kicking off the idle animation:

fn start_initial_animations(
	query: Query<
		(Entity, &UnitAnimations, &UnitAnimationState),
		With<NeedsInitialAnimation>,
	>,
	children_query: Query<&Children>,
	animation_player_query: Query<&AnimationPlayer>,
	mut commands: Commands,
) {
	for (entity, animations, state) in &query {
		let Some(player_entity) = find_animation_player(
			entity,
			&children_query,
			&animation_player_query,
		) else {
			continue;
		};
		let node = match state.0 {
			UnitState::Idle => animations.idle,
			UnitState::Moving => animations.moving,
		};
		commands.entity(player_entity).insert(
			AnimationGraphHandle(animations.graph.clone()),
		);
		commands.entity(player_entity)
			.queue(move |mut entity: EntityWorldMut| {
				if let Some(mut player) =
					entity.get_mut::<AnimationPlayer>()
				{
					player.play(node).repeat();
				}
			});
		commands.entity(entity)
			.remove::<NeedsInitialAnimation>();
	}
}

With animations sorted, I moved on to unit movement. Units need to rotate toward the direction of travel, so adding a simple slerp toward the movement direction handles this nicely, interpolating smoothly so the units don't snap instantly:

if distance > 0.01 {
	let direction = toward.normalize();
	let target_rotation =
		Quat::from_rotation_y(direction.x.atan2(direction.z));
	transform.rotation = transform.rotation.slerp(
		target_rotation,
		(time.delta_secs() * 10.0).min(1.0),
	);
}

I also pulled the hardcoded movement out and into definitions.ron. Small change that will be useful for different unit types.

The result is units that animate, face the direction they're moving, and smoothly transition between idle and sprint:

With the new Kenney assets for buildings, these grey blocks and beige capsules weren't really cutting it so I thought I'd replace the grey blocks in the map with the same buildings, then I went on the hunt for a good placeholder asset for units, and discovered Quaternius' fantastic universal animation library. I thought I'd also take the opportunity to remove the slew of hardcoded functions that create these units and map objects, and actually build out a map definition which can then be used as the basis for... well, maps.

I went into this thinking it would be straightforward but I ran into some surprising difficulties. Taking a map.ron and loading it was fine, but then came asset loading issues, because loading so many glbs at once caused visible pop-in, as I hadn't handled any form of asset loading. So I introduced a new asset loader based on Tainted Coders' Advanced Asset Techniques section. This all worked really nicely and the code feels better for it; pulling the game world from a Ron file rather than manually coding meshes.

The next issue was that path-finding broke, and selection broke. These were two issues with the same root cause: while the building and unit entities used to be simple meshes, they were now "SceneRoots", and the Aabb which was on the entity was now on a child entity. For now I've fixed this by adding Aabbs to these entities and adding a new system to compute their Aabb bounds from their child Aabbs. I don't like this system but it'll do for now, and I'll come up with something smarter, later on.

I'd hoped to have the time to tackle some unit movement animations but given the time it took to get all of the asset systems built and path finding and selection systems refactored, I didn't find time by the end of it all to tackle animations.

All this to say, the net result doesn't look so different, the main visual change is pulling in models rather than simple shapes:

I thought I'd dip more into shaders this week, and refine the somewhat clunky selection indicators. I didn't like how for each unit two meshes were created: one for the "over" (hover) state and one for the selected state. These two circle meshes were likely simple enough but armed with my new shader knowledge I thought I could simplify down to a single mesh that updated its material via a fragment shader depending on state.

I also added some configuration options to the SelectionIndicatorMaterial to allow customising of colours and borders:

struct SelectionIndicatorMaterial {
    is_over: bool,
    is_selected: bool,
    inner_radius: f32,
    over_color: vec4<f32>,
    selected_color: vec4<f32>,
};

@fragment
fn fragment(in: VertexOutput) -> @location(0) vec4<f32> {
    // Discard pixels outside the outer radius
    let distance = length(in.uv - CENTER) * 2.0;
    if distance > 1.0 {
        discard;
    }

    let in_annulus = distance >= material.inner_radius;

    if material.is_over && in_annulus {
        return material.over_color;
    } else if material.is_selected {
        return material.selected_color;
    }

    discard;
}

This results in a much nicer single mesh material for all selection states:

This week I wanted to further the building system to add placement and construction. This works by using the BuildingGhost; when a click occurs with an active BuildingGhost then a new ConstructionSite is spawned in that position. The ConstructionSite has a Bar component that shows the progression - how long until the building is constructed - based on the buildings construction time in definitions.ron.

The first iteration of the Bar was a Cuboid just to get the basics down:

This clearly needed improving. I want the progress bar to billboard. I found bevy_mod_billboard which seemed just the ticket, however this was last updated to support Bevy 0.14. I peeked at the code, and figured out the real magic was within billboard.wgsl. So with that as a reference and a slew of other resources and guides (1, 2, 3, 4, 5) I set to work building my own (which I'll keep until maybe bevy gets it built-in at least).

The result is this bit of wgsl. The vertex shader re-orients the vertexes to always face the camera, while the (very simple) fragment shader colours the in-progress section. Fortunately not too much math as Bevy has some useful built in functions:

@vertex
fn vertex(vertex: Vertex) -> VertexOutput {
    var out: VertexOutput;

    // Get entity world position (includes parent transform + local offset)
    let entity_world_pos = get_world_from_local(vertex.instance_index)[3].xyz;

    // Transform to clip space
    let clip_position = position_world_to_clip(entity_world_pos);

    // Scale based on depth for consistent screen size
    let scale = max(10.0, clip_position.w / 40.0);

    // Billboard: add XY offset in clip space
    out.position = vec4<f32>(
        clip_position.x + scale * vertex.position.x,
        clip_position.y + scale * vertex.position.y,
        0.0,  // Near plane - renders on top of everything
        clip_position.w
    );
    out.uv = vertex.uv;
    return out;
}

@fragment
fn fragment(in: VertexOutput) -> @location(0) vec4<f32> {
    return select(
			material.background_color,
			material.color,
			in.uv.x <= material.progress
	);
}

The result? A nice clean animated progress bar that faces the camera, no matter the rotation or zoom:

This week I thought I'd get to work on a system for pick-and-place buildings. My vision is to not end up with traditional RTS style pick-and-place, but for now making what I'm familiar with and iterating sounded like a sensible approach. I've gone with a Command & Conquer style pick-and-place, where players select a building from a palette and get a "ghost" building they can lay down onto a grid-snapped map.

However it's now 2026 and we don't need square tiles to show where the building will be placed, and I didn't want to use more grey boxes - not just because they're boring but I also need to look at how Bevy's asset loading systems work. I took a peek at this city builder demo from Kenney who provides wonderfully crafted assets sets. Pulling in some of the glbs, with some ron through serde to pull in definitions and size, I built an asset loader that loads all of the assets.

From there, I added a GridPosition struct that simply rounds world coordinates to create a grid snapping effect, and a PlayerCursorMode state which tells the engine if the user is able to select units, or if their building BuildingGhost should be visible. The BuildingGhost simply follows the mouse position with a ray:

let Some(mut cursor) = window.cursor_position() else { return };

// Generate a ray from the active camera
let Some(ray) = cameras.iter().find_map(|(camera, transform)| {
	if let Some(viewport) = &camera.viewport {
		cursor -= camera.to_logical(viewport.physical_position).unwrap_or_default();
	}
	camera.viewport_to_world(transform, cursor).ok()
}) else {
	return;
};

let t = -ray.origin.y / ray.direction.y;
// Ray doesn't intersect plane (pointing away)
if t < 0.0 {
	return;
}

let intersection = ray.origin + ray.direction * t;

// Snap to grid
let grid_pos: GridPosition = intersection.into();
let snapped_world_pos: Vec3 = grid_pos.into();

// Update all ghost transforms
for mut transform in ghosts.iter_mut() {
	transform.translation = snapped_world_pos;
}

The result is a ghost building perfectly following the cursor, but also snapping to a 1x1 unit grid:

That weekly update thing really slipped off. Around April I found myself applying for, and accepting a new job, which has been very rewarding but very challenging. I only had a few hours a week to work on personal projects, but with on-ramping to a new job as well as maintaining existing projects, game dev had to be put aside for a little while. However given it's a new year, and I'm feeling more comfortable and confident at work, I'm trying to find my way back to this.

So it sat, unloved, until late last year when I tried to pick this back up again and update some dependencies, but I found that Polyanya and Vleue Navigator needed updates, so I sent PRs to update those libraries. Polyanya just needed some version bumps, and Vleue Navigator had a few more changes, but luckily the Bevy migration guides make this quite straightforward. Waiting for those to release distracted me enough that I didn't pick this back up again until just now that I've finally updated this engine to Bevy 0.17.3. No new screenshots or videos, but just the knowledge that we're back.

This week I introduced a path finding system for units. Going in, I expected to be searching for an A* path finding library, but I decided to first research the options for state-of-the-art path finding systems for many units, which sent me down a rabbit hole. The first stop was Flow Fields / Vector Fields. I couldn't find an off-the-shelf library for flow fields in Bevy so in order to build myself up to writing one I began looking for more applicable literature. I landed on a fantastic devlog on building an RTS which covered FlowFields in excellent detail, but exploring the rest of the blog lead me to "Dynamic Navmesh with Constrained Delaunay Triangles". This post goes into a lot of detail around solving performance of navmeshes within unity, but my take-away was that it would be a more flexible solution, albeit one that requires more computation. I tried to look further to see if more recent research had more optimal solutions. Eventually I landed on a paper titled "Fast optimal and bounded suboptimal Euclidean pathfinding" - maybe one day I'll spring the $35 to pay for it so I can read it but - the excerpt alone proved very useful, as it mentioned that it's an optimisation over the cited "Polyanya" algorithm. This algorithm seems to be covered in the paper "Compromise-free pathfinding on a navigation mesh". The top result for "Polyanya" isn't the paper itself, but a rust library! It must be fate. Further still, vleue/vleue_navigator seems to be a bevy implementation for generated navmeshes and using polyanya to pathfind on them, so this felt like a sure bet.

So with most of the week over, I set to integrating this library. I introduced a Waypoint component which each Unit requires. Right clicking the mouse ray-casts to find the Ground and hands the Vec3 hit to the Waypoint on all selected units (using my PointerSelections component). Thanks to the foundations laid in the last few weeks, it was very simple to get this implemented. Waypoints represent "where the player wants the unit to be" making it quite simple to get Vleue Navigator to connect the dots:

fn update_path_from_waypoint(
	movables: Query<(
		Entity,
		&Transform,
		&Waypoint,
		Option<&PathFinder>
	), Changed<Waypoint>>,
	navmeshes: Res<Assets<NavMesh>>,
	navmesh: Query<(&ManagedNavMesh, &NavMeshStatus)>,
	mut commands: Commands,
) {
	// ...
	for (entity, transform, waypoint, path_finding) in movables.iter() {
		let from = transform.translation.xz();
		let to = waypoint.position().xz();
		if let Some(path_finding) = path_finding {
			path_finding.compute(mesh, from, to);
		} else {
			let path_finding = PathFinder::default();
			path_finding.compute(mesh, from, to);
			commands.entity(entity).insert(path_finding);
		}
	}
}

With the path being computed each time the Waypoint changes, it was then just a case of moving any unit along its path... Except that Vleue Navigator's paths are of course multi-point, to allow for navigating around obstacles. I didn't have time to implement a way for units to navigate to subsequent points; when they reach the end of the first point they stop. I think the best solution for moving across multiple points is to pop the 0th point from the path vector every time the entity moves on top of it, however that doesn't feel very robust, so I'll be looking at this in more detail next week.

The other problem is that multiple units do not consider each other, selecting multiple units and commanding them to one location means they end up stacking over each other. This will also need some solution as it's far from desirable. Perhaps one solution here is that the user clicking gives an indication of a waypoint to set, but not the exact space the unit will move to. Or perhaps implementing a Boids system is next on the agenda.

This week I chose to work on some developer tooling to make it easier to visualise and alter parts of the game during runtime. Motivated by last week's work on the selection code, where I found myself in a tweak-recompile-try-repeat loop. I think some interactive developer tools would provide much quicker feedback loops, so it feels like getting this established now will pay dividends later. I created a devtools feature flag to scope all of this too, took a deep breath and set out to build the devtools crate...

Luckily this was way simpler than I imagined it would be, dropping in bevy_inspector_egui coupled with egui_dock got me very close. Going back and deriving Reflect on all my components was also a must. Beyond that I added a couple of custom panes that I was kind of surprised didn't exist off-the-shelf (at least that I could find). One of the custom panes shows the fps/frame count using bevy's built in DiagnosticsStore. Quite simple:

let diagnostics = self.world.resource_mut::<DiagnosticsStore>();
egui::Grid::new("performance")
  .num_columns(2)
  .spacing([40.0, 4.0])
  .striped(true)
  .show(ui, |ui| {
    for diagnostic in diagnostics.iter() {
      let value = diagnostic
        .average()
        .or_else(||
          diagnostic.smoothed()
        ).unwrap_or(0.);
      ui.label(diagnostic.path().to_string());
      ui.label(
        format!(
          "{value:>.0}{suffix:}",
          suffix = diagnostic.suffix
        )
      );
      ui.end_row();
    }
  });

The other was a pane to enable & disable debug Gizmos. Bevy's Light & AABB controls have built in Gizmos for debugging. Getting these working was quite straightforward by using bevy's reflect module. Iterating over GizmoConfigStore entries, this code tries to grab the draw_all field, to turn it into a checkbox in the UI:

egui::Grid::new("gizmos")
  .striped(true)
  .show(ui, |ui| {
    let mut gizmos = self
      .world
      .resource_mut::<GizmoConfigStore>();
    for (_, config, value) in gizmos.iter_mut() {
      let name = value
        .reflect_short_type_path()
        .to_owned();
      let ReflectMut::Struct(value) = value
        .reflect_mut() else { continue };
      let Some(enabled) = value
        .field_mut("draw_all") else { continue };
      let Some(mut enabled) = enabled
        .try_downcast_mut::<bool>() else { continue };

      ui.checkbox(&mut enabled, name);
      ui.end_row();
    }
  });

I find both of these implementations to be quite elegant in how generic they are. I imagine I'll be able to trivially add new diagnostics to the DiagnosticStore, while also it should be possible to implement draw_all as a field in new Gizmos, should I need that (e.g. for path finding, which I aim to tackle next).

The result of all this is that with the --features devtools enabled, the game loads up with the inspector view which will make runtime debugging far easier:

This week I worked on a selection engine for picking units to control. Most of the work builds upon Bevy's picking engine, which has a built-in way of managing cursor hover/click events by using ray-casts to find a mesh. The picking engine, as I learned this week, used to be a third party module called bevy_mod_picking, but it seems Bevy does a good job of upstreaming very popular libraries.

One thing the picking engine doesn't handle is selection. This is handled by bevy_mod_picking's bevy_picking_selection crate, but it looks like that wasn't folded into Bevy's picking module (perhaps it will be later). This meant I had to write something myself. I think my solution is a little more flexible than the mod picking one - it takes Pointer<Down> and Pointer<Click> events dispatching new Pointer<Select> and Pointer<Deselect> events. This system is quite straightforward - anything clicked gets queued up for selection, and after that system runs, another one replaces the current selection with the queued one, and dispatches events. It even allows for multi-select. Coupling this with a SelectionIndicator component, means a unit can toggle between "over" and "selected" states. The SelectionIndicator might be the more interesting piece:

#[derive(Component, Copy, Clone, Debug, Reflect)]
#[reflect(Component)]
#[component(on_add = setup)]
pub struct SelectionIndicator {
	over: bool,
	selected: bool,
}

fn setup(mut world: DeferredWorld, entity: Entity, _: ComponentId) {
	world
		.commands()
		.entity(entity)
		.observe(move |
			trigger: Trigger<Pointer<Over>>,
			mut query: Query<&mut SelectionIndicator>
		| {
			if let Ok(mut indicator) = query.get_mut(trigger.entity()) {
				indicator.over = true;
			}
		}).observe(move |
			trigger: Trigger<Pointer<Out>>,
			mut query: Query<&mut SelectionIndicator>
		| {
			if let Ok(mut indicator) = query.get_mut(trigger.entity()) {
				indicator.over = false;
			}
		}).observe(move |
			trigger: Trigger<Pointer<Select>>,
			mut query: Query<&mut SelectionIndicator>
		| {
			if let Ok(mut indicator) = query.get_mut(trigger.entity()) {
				indicator.selected = true;
			}
		}).observe(move |
			trigger: Trigger<Pointer<Deselect>>,
			mut query: Query<&mut SelectionIndicator>
		| {
			if let Ok(mut indicator) = query.get_mut(trigger.entity()) {
				indicator.selected = false;
			}
		})
}

Picking individual units can be time consuming though, so I wanted "box" style selection. I couldn't find anything similar (bevy_mod_picking nor bevy picking had modules or examples, and a web search turned up empty). So I wrote a box selection utility for this. This became the most complex piece. The box that gets drawn needs to be facing the camera, but checking the collision with entities in world space. It took a few days of reading and understanding just to come up with these 4 lines:

let world_from_local = transform.affine();
let aabb_center_world = world_from_local
	.transform_point3a(aabb.center)
	.extend(1.0);
let position = aabb_center_world.xyz();
if let Ok(xy) = camera.world_to_viewport(camera_transform, position) {

The result however, was worth it. Selection boxes will highlight any element whose AABB center is within the bounds of the box, and releasing the mouse pointer will take all of those highlighted units and select them, using the same Pointer<Select>/Pointer<Deselect> events, meaning the SelectionIndicator "just works", without any knowledge that the selection box systems are running or even exist:

This game is going to be a top down real time strategy game. I have the ambition to set it in a city, and so I wanted to work a bit on a camera system to enable that.

In most RTS games the camera is a top down view of the world, the player has a commanding view over the world - the camera isn't attached to any one object. While classic RTS games of the 90s and 00s had a fixed view, this was largely due to limitations of sprites, and so movement was largely limited to panning. This game will be fully 3d, so in addition to panning, I'll be adding zooming, and rotation.

So I created a very basic 3d view with some block shapes which represent buildings, and created Camera & CameraController components. The controller allows the camera to pan with WASD as well as the Arrow Keys, and the mouse while holding space or middle click. Using Leafwing Input Manager simplified this a lot. The zoom functionality also rotates on an EasingCurve, meaning as the player zooms in the camera pitches up, giving them more of a "third person" view, rather than top down. I hope this will let players get in close to the action when they need to.

pub fn adjust_camera_angle_based_on_zoom(&mut self) {
	self.target_angle = self.min_angle.lerp(
		self.max_angle,
		self.easing_curve.sample_clamped(self.target_zoom)
	);
}

Given there will be a lot of verticality to a top down view of the city, I also decided to have the camera try to keep a fixed distance from the ground. Every time the camera moves it ray-casts out to the world, finding the Ground component (which the buildings, as well as the floor plane, possess). The intersection point of the ray cast becomes the new minimum height the camera sits at. This works somewhat well, but due to the ray being a single point it's possible for the camera to be close to a building without being directly on top of it, which means it feels more arbitrary than intentional. Some improvements to make later would perhaps be to fire multiple rays around the center of the camera - rather than just one - and take the max. Alternatively, perhaps it would be better to use more traditional collision system by checking AABBs within the bounds of the frustum and getting the max height; one issue here is that the camera pitch can wind up so that many buildings are in front, which might cause problems. Keeping the code well separated by putting simple methods in the structs impl will, I think, keep things flexible; the basic code for the ray-cast becomes:

let hits = ray_cast.cast_ray(
	camera.ray_from_center(),
	&RayCastSettings {
		filter: &|entity| grounds.get(entity).is_ok(), ..default()
	},
);
if let Some((_, hit)) = hits.first() {
	camera.move_focus_height(hit.point.y);
} else {
	camera.reset_focus();
}

Either way, here's what it looks like so far:

I've decided to try to build a game. Game development fascinates me, and I think I'd enjoy developing a game more than playing it. I've been toying around with the idea since early-2023. First I tried writing a simple ECS in TypeScript, and built a basic Pong clone. Around February I moved on to toying with Bevy, but ultimately I paused in May 2023.

Throughout 2024 I wrote a lot of Rust in order to improve my skills. I made a few simple web sites using Actix, and built some bigger projects from scratch. I wrote about 100,000 lines of Rust in 2024, which helped improve my understanding of it immensely, which made Bevy less intimidating.

Now that we're in 2025, I'm going to revisit this. I'd like to build a real time action strategy game, like the classics from the 90s & 2000s. My inspiration comes from Bullfrog games like Syndicate, Theme Hospital, Dungeon Keeper, and the amazing Westwood Studios games like Dune and Command & Conquer. They were the games I enjoyed as a teen and I'd love to recreate something which pays homage to them.

In order to keep myself on track, I intend to write here, every Saturday, explaining what I've managed to accomplish in the week before. I'll be developing this in my free time so these updates might be small, but hopefully I'll make useful progress each week.

To that end, today I managed to make a simple menu. Not much but it's a start: