Are there bugs? Undeniably. But I'm fine with where they sit. Sometimes you just have to stop and tell yourself: good enough.

The Two Blogs I Buried

First there was WordPress. I hated it from start to finish. Bots came at it around the clock trying to break in, though honestly they needn't have bothered: it broke itself just fine. The database went down for reasons I never did pin down. Had it not kept falling over, I'm fairly sure it would have turned into a virus hub: holes on top of holes, patch constantly or pay for it. And all that joy ran me seven dollars a month. Short version: I'm happy it's gone.

Then came a run at Next.js. I didn't write that one myself — I asked my brother and his girlfriend. A school project for them, a blog for me. The result was meh. I just didn't like how Next does routing, or how big and ungainly the whole thing is. The repo's still around, gathering dust since late 2023.

And yet the direction was exactly right: static generation, articles in Markdown, components in React. MDX, if we're being precise. It was just miserable to actually build. Server components were their own saga; the thing still dragged all of React onto the client, and a heap of code with it. But that was the moment I first saw my own architecture clearly. The idea of the ideal blog that eventually turned into this one.

First the Engine, Then the Blog

I've written about Moku Core already: a month spent not over code but over the kernel's spec. That post ended on a glum note — no second layer yet, no third, all of it pure theory, and me just hoping they'd show up.

They showed up. Moku Web is the second layer, the framework. The blog is the third, the app itself. The three-storey tower from that post is fully built now, and you're reading its top floor.

The entire blog is a single createApp call. No globals stashed in corners: you register plugins, hand them config, and that's the end of it.

// src/app.ts — the whole blog is one createApp() call.
const app = createApp({
  plugins: [contentPlugin, buildPlugin, deployPlugin, dataPlugin, cliPlugin],
  config: { mode: "hybrid", stage: "production" },
  pluginConfigs: {
    site: SITE,            // name, url, author — one source of truth
    i18n: i18nConfig,      // en · uk · ru · es
    content: {
      providers: [
        fileSystemContent({
          contentDir: "./content",
          shikiTheme: warmSyntaxTheme,                  // code blocks
          mermaid: { mermaidConfig: warmMermaidTheme }, // ```mermaid fences
          embed: { facade: EmbedFacade },               // ::embed{...}
          gallery: { component: Gallery }               // ::gallery{...}
        })
      ]
    },
    router: { routes },
    deploy: { target: "cloudflare-pages" }
  }
});

One file, and you can see what the blog is made of.

Where Everything Lives

The rest of the project is just as flat. No magic folders, no hidden wiring — you open a directory and it does what it says on the door:

blog/
  src/
    app.ts        # Node-side composition — the createApp() from above
    spa.tsx       # browser entry — same routes, none of the Node plugins
    routes.tsx    # THE route table — one source of truth (next section)
    config.ts     # SITE identity: name, url, author
    i18n/         # en · uk · ru · es — UI strings + locale config
    pages/        # one Preact page per route (home, article, archive…)
    components/   # SSR'd UI: nav, gallery, the embed facade
    islands/      # the tiny client scripts, hydrated on demand
    lib/          # pure helpers: articles, head, urls, dates
    styles/       # CSS: tokens, fonts, article typography
    og/           # build-time OG-image cards (Satori)
  content/        # the articles — one folder per post (see above)
  public/         # served as-is: fonts, _headers, favicons
  scripts/        # one-liners: build / serve / preview / deploy
  tests/          # unit · integration · e2e (the paranoia, below)

Two files carry the weight: app.ts, the one you just saw, and routes.tsx — which is the part I actually care about.

The Router Is the Heart of It

If the blog has a heart, it's routes.tsx. One table, and three different things read from it: the static build (which pages to generate), the in-browser navigation (what to render on a click), and the link builder (every href on the site). Define a page once, in one place, and all three agree forever.

A route is a little chain of declarations:

// src/routes.tsx — define a page once; the build, the SPA, and every link obey it.
article: route("/{lang:?}/{slug}/")          // {lang:?}: bare "/slug/" for en, "/ru/slug/" for the rest
  .generate(async ctx =>                       // which static pages to emit at build time
    (await allArticles(ctx)).map(a => ({ lang: ctx.locale, slug: a.computed.slug }))
  )
  .load(async ctx => {                         // fetch the data — runs at build, persisted as JSON
    const article = await articleBySlug(ctx);
    const all = await allArticles(ctx);
    return { article, related: relatedArticles(all, article, 5) };
  })
  .render(ctx => <ArticlePage article={ctx.data.article} related={ctx.data.related} />)
  .head(ctx => articleHead(ctx, ctx.data.article))   // <title>, OG, canonical, hreflang

.generate says which pages to stamp out — one per article, per locale. .load fetches the data. .render is the Preact component. .head is the SEO. That's the whole contract.

Here's the trick that turns it into a single-page app without me writing any of the plumbing. At build time .load runs, and its result is baked into the HTML and dropped next door as _data/<lang>/<slug>/index.json. Click a link and the browser doesn't reload — it fetches that little JSON file and runs the same .render. One piece of code, two moments: the build on my machine, the click in your tab.

And because the links come out of the same table, they can't rot:

// links come from the SAME table — a typed builder, so a link can't drift from a route:
urls.toUrl("article", { lang: "en", slug: "spark" }); // "/spark/"     — en is bare
urls.toUrl("article", { lang: "ru", slug: "spark" }); // "/ru/spark/"

I never type a URL by hand. I ask the table for one, and the day I rename a route, every link moves with it. That's why the router sits in the middle and everything else hangs off it.

A Post Is Just a Folder

To write a post I don't open an admin panel (hi, WordPress). I make a content/<slug>/ folder and drop one file per language into it:

content/how-this-blog-works/
  en.md
  uk.md
  ru.md
  es.md
  images/   # images, if you need them

Up top, each file has frontmatter — plain YAML:

---
title: "Take Three: How This Blog Actually Works"
date: "2026-06-14"
description: "One hook of a sentence — it doubles as the OG card and the archive teaser."
tags:
  - moku
  - programming
language: en
draft: false
---

draft: false and the post ships to production. Set it to true and it's visible only locally, while you're still writing. No Publish button, no database. Git is my CMS.

The Parts I Actually Wanted

This is the part I built the thing for. You like technical details? I do.

Syntax highlighting. Every code block in this post is coloured by Shiki, at build time, not in the browser. The theme is warm, tuned to the blog; the actual token colours live in inline styles.

Diagrams. Drop a ```mermaid block and the build turns it into a static SVG. Right below this paragraph is a live one, the very feature I'm describing. It's the path text takes before it becomes a website:

I draw the same diagrams in the posts on Moku Core and Spark.

Galleries. ::gallery{src="./images/board/"} turns a folder of images into a gallery with a lightbox. That's how I showed off board-game boxes in the best board games and in Descent.

Embeds. ::embed{src="…" title="…"} is a lazy iframe: nothing loads until you click. In the Screw Master post you can play the game I made right inside the article.

All of these are directives — a single line of Markdown each.

Four Kinds of Paranoia

I don't trust myself, and I trust the AI that wrote half of this even less. So there are several layers of tests:

• Unit tests for pure logic: pagination, date formatting, link building. Fast, no browser.
• Integration tests build the real content, every article in full, and check that nothing fell off. Including the rendering of those mermaid diagrams.
• E2E on Playwright run the live, built site across three engines: Chromium, WebKit, and Firefox. Because Safari has broken on me on its own before, and I've learned.
• Visual baselines: golden screenshots of the home page, the archive, an article. If code shifts the layout, the screenshot won't match and the test fails.

One subtlety: e2e runs against a frozen set of fixtures, not the live articles. So I can publish whatever I want to content/ and the tests don't flinch. A new post needs zero changes to the tests.

Hosting for the Price of Nothing

And now the money. Remember the seven dollars a month for WordPress? Here it's zero.

The blog is just a pile of static files. I run git push, CI runs the lint and the tests, and if everything's green it ships itself to Cloudflare Pages. Static files on the free tier cost nothing a month. No server to patch, and update, and bring the database back up every week. The page arrives as finished HTML; the interactivity comes in as tiny islands (small JS scripts that hook onto the content, or just run on the client).

From seven dollars a month to nothing. I didn't get rich, but it's nice to save.

So that's the beginning. Or the end, depending which way you look at it. The blog I rewrote three times (maybe four — I lost count) finally stands on the foundation I wanted from the start.

And I've got a new toy now, plus one more hobby: Spark, a game engine in Rust I've already started writing about. So the story doesn't end. It just moves to a different repository.

It was also the most fun my wife and I have had in front of a screen all season.

Kimi Antonelli won it, by the way — lights to flag, utterly in control. I'd genuinely forgotten he won, and honestly nobody gave a damn — and that tells you everything about where the story actually lived.

A race with one overtake and a hundred plot twists

Monaco isn't a race you win. It's a race you survive. And this year the survival rate was comedy.

Hadjar drove a wreck onto the podium

Isack Hadjar spent what felt like sixty laps nursing a broken Red Bull around the houses, collecting what felt like every penalty in the world on the way. Then the stewards quietly dropped the one that mattered — the team had started illegal work on his car under the red flag and then thought better of it — and he climbed out of that mess onto his first podium for Red Bull. P3. Not because he was fast, but because everyone ahead of him found a more creative way to lose.

George Russell got the opposite gift. A five-second pit-lane penalty he couldn't even serve properly — because under the late safety car one half of the pit wall thought they had to sit out the five seconds and the other half thought they didn't, so the crew just went ahead and changed the tyres while George sat there asking the radio whether he was even stopping. The FIA was not amused, and the five seconds became a drive-through that folded his afternoon shut like a cheap deck chair. Two drivers, the same circuit, opposite endings. That's the whole sport in one stop.

Stroll started it, Leclerc had to one-up him

Lance Stroll planted his Aston in the barriers first — first to get bored, evidently, first to decide he'd seen quite enough and head home early. Then Charles Leclerc, apparently deciding the drama wasn't quite sharp enough, repeated the trick almost note for note at the restart — and binned a podium doing it. The FIA pointed at the track surface breaking up at exactly the spot where both of them lost the car. Both drivers shrugged and blamed their own machinery — engine braking, brakes, take your pick. Nobody agreed on anything, which is the most Monaco outcome imaginable.

And the Ferrari heartbreak underneath it all: Leclerc, at home, throwing away a podium car. Rage? An honest mistake? He came out of it sad and furious in equal measure, and you genuinely couldn't tell which one put him in the wall. Piastri, for the record, dragged his McLaren home a frustrated fourth — a podium that was right there and simply never arrived.

Six speeding tickets in one afternoon

And the penalties. Oh, the penalties. Six drivers — six — got done for speeding in the pit lane. Half the grid, near enough, all caught doing the one thing every team has a literal button to prevent.

THE PENALTY BOX · Monaco 2026
Gasly       P3 on the road  ->  P7   (two separate 5s pit-lane penalties)
Russell     5s pit-lane     ->  drive-through, afternoon over
Hulkenberg  10s             ->  for collecting Sainz
Perez       false start     ->  P10 stripped, sent to the back
... and two more for the road. Six speeding tickets in total.

So which is it? Did half the paddock set their limiters wrong on the same day, or did something go sideways on the FIA's side of the measurement? They're usually surgical about this stuff. This time something smells off. Gasly is the one I ache for — he crossed the line third for Alpine and got demoted to seventh by two separate five-second penalties. A Monaco podium, gone, over a handful of km/h.

I haven't even named everyone who got burned. Carlos Sainz — forgot him completely, poor guy, just unlucky from lights to flag. Hülkenberg picked up a penalty for tipping Carlos into trouble. The casualty list reads like a phone book.

The footnotes nobody clapped for

Nearly forgot the best little story of all: the final point. Fernando Alonso, P10 — Aston Martin's first point and first top-10 of the entire 2026 season. Let that land. Their year is so grim that one point, handed to them by someone else's penalty, counts as a party. They will not get this lucky twice.

Then there's Pérez, in a league of his own — only the league turned out to be the losers' one. How do you line up in the wrong grid box, and then fumble the restart, knowing full well you've already been warned? He was genuinely quick — close to winning the loser's cup outright — and then a false start dropped him to the back and stripped his P10, denying Cadillac their first-ever point. Second place in the championship nobody wants.

But honestly? Cadillac keep getting better and the Astons keep getting worse, so my prediction is they level it out at the bottom. And as much as Alonso charms me, it's no comfort — I reckon he and Stroll finish dead last in this loser's championship, together.

What Monaco actually needs

Everyone's begging for more overtakes at Monaco. Wrong fix. We don't want more passing — we want more carnage. And this year Monaco delivered.

Here's my unpopular take, and my wife co-signs it. People moan that Monaco needs eight overtakes, ten, fifteen, whatever number makes a spreadsheet smile. Others want the V8s screaming back, as if engine noise ever won anyone a race. I could not care less about any of it. Give us drama. Give us a broken car on the podium, two heroes in the same wall, six speeding tickets, and a first point that feels like a trophy.

That is what makes this thing watchable for hamsters like us.

More drama. More spectacle. That's the whole review.

Quick recap for anyone who skipped part one: Spark is my game engine in Rust where everything is built around a single ECS. I steal the system syntax from Bevy, workloads from Shipyard, and the storage I built my own way.

A sparse set, not archetypes

The most important architectural decision is the storage, and there are two big camps here. Bevy (and hecs, and flax) use archetypes: entities with the same set of components sit together in dense tables. Shipyard uses a sparse set: every component type gets its own separate storage.

I went with a sparse set, like Shipyard, rather than archetypes, like Bevy. The reason is embarrassingly simple: it's easier. Archetypes are faster on pure traversal, but writing them from scratch is its own genre of pain — entities migrating between tables, fragmentation, all of it. And I cared more about understanding every line than about squeezing out the last microsecond. Besides, the API is designed so I can move to archetypes later without breaking anything on the outside. But more on that at the very end.

How it sits in memory

The storage for one component T is three parallel arrays:

sparse:        [ Some(0), None, Some(1), None, Some(2) ]
                   E0            E2             E4
dense:         [ Pos0,          Pos2,          Pos4 ]     <- packed back to back
entity_index:  [ E0,            E2,            E4   ]

sparse is indexed by the entity's number and tells you where its data lives in dense (or that there's none at all). dense is the components themselves, packed back to back, no holes. entity_index answers the reverse question: whose row is this in dense. Insert, remove, lookup — all O(1). Removal is a swap-remove: plug the hole in dense with the last element and fix a single pointer in sparse. The array stays dense.

And here's the answer to "why is it even fast." When a system walks every Position, it reads dense straight through, byte after byte. The CPU adores this: the prefetcher guesses what's coming next, and the cache lines are stuffed with useful data instead of pointers. Compare that with classic OOP, where you have an array of pointers to objects scattered across the heap — there, every step of the loop is a trip to memory and a cache miss. Data-oriented design basically says: lay your data out the way the processor will read it, not the way that's comfortable for a human. The ECS takes that idea to its logical extreme.

Workloads: a real example

A system in Spark is a plain function, and its parameters declare what it reads and writes. A workload is a named batch of systems that belong together:

// A workload is a named batch of systems. Each system's parameter types
// declare what it reads and writes; the scheduler uses those access sets to
// decide what may share a parallel batch and what must run in order.
app.add_workload(Workload::PowerGrid, Stage::FixedUpdate, |w| {
    // Both write the grid, so they can't share a batch — and an *undeclared*
    // order between two writers is a registration error, not a guess.
    let supply = w.add_system(collect_supply);
    let demand = w.add_system(compute_demand).after(supply);

    // Reads the finished grid, so it runs last.
    w.add_system(distribute_power).after(demand);
})
.after(Workload::Simulation); // whole workloads order by label, same .after / .before

The scheduler reads the access sets (the parameter types declare them) and works out for itself what conflicts with what. If two systems both write the same PowerNetwork and no order between them is declared, that's a registration error — not "eh, it'll sort itself out." But systems that touch disjoint data, it's free to pack into one batch and run in parallel.

Free to — but not doing it yet. The parallel executor is M4, still ahead of me, and today everything runs sequentially. The access model is already in place, though, and that's deliberate: when I get to Rayon, it'll be swapping a RefCell for an UnsafeCell behind an already-proven-correct scheduler, not a rewrite.

How the files are laid out

lib/ecs/
├─ src/
│  ├─ entity.rs       # Entity = (index, generation) + allocator with a free list
│  ├─ storage.rs      # ComponentStorage<T> — sparse set + the change counter
│  ├─ world.rs        # World: HashMap<TypeId, Box<dyn AnyStorage>>
│  ├─ query/          # Query<D, F>: data, filters, joins, driver selection
│  ├─ system/         # SystemParam + IntoSystem — a function becomes a system
│  ├─ workload.rs     # workloads: labels, builder, topo-sort
│  ├─ scheduler.rs    # runs stages → workloads → systems
│  ├─ commands.rs     # deferred spawn / despawn / insert / remove
│  ├─ events.rs       # Events<T> + Reader / Writer (double-buffered)
│  └─ access.rs       # access sets + conflict detection
└─ macros/            # #[derive(Component / Resource / Event / WorkloadLabel)]

How a frame runs

Once per frame, App pokes the scheduler. It walks the stages strictly in order; inside each stage, the workloads run in their .after / .before order; inside each workload, the systems run in batches by access. Commands (spawn, despawn, insert) aren't applied right away — they pile up and flush at the workload boundary. Events live in a double buffer and swap once at the top of the frame, so a reader always sees exactly the previous frame, and the order of systems within a frame stops mattering. Boring and predictable, which is what a simulation wants.

Change detection: on the second attempt

The piece I'm happiest with is change detection. The Changed<T> and Added<T> filters let a system process only the entities whose component changed (or first appeared) since its last run. For a simulation where three of ten thousand entities actually move in a given tick, that's the difference between "recompute everything" and "recompute three."

// `Query<&mut T>` hands back a `Mut<T>`, not a bare `&mut T`. Taking the
// mutable borrow *is* the change signal: write through it and this entity's
// `changed_tick` moves; read through it and nothing is marked.
fn fluctuate(mut q: Query<&mut BusVoltage>) {
    for mut v in q.iter_mut() {
        v.0 = v.0.wrapping_add(1); // DerefMut here -> this bus is "changed"
    }
}

// Re-solve only the substations whose voltage actually moved this tick.
// `Changed<BusVoltage>` filters to those; the three-component shape already
// drops bare buses before the filter even matters.
fn grid_solver(q: Query<(&BusVoltage, &Transformer, &Feeder), Changed<BusVoltage>>) {
    for (_v, _t, _f) in &q {
        // ... re-solve this substation
    }
}

The precision rides on a small trick. Query<&mut T> hands you a Mut<T> wrapper, not a bare &mut T, and the "changed" signal is the very act of taking the mutable borrow through DerefMut. Walk a thousand entities, write to three, and exactly three marks move. Read through Deref only, and nothing moves.

The decision I'm proudest of cost me two implementations. The change counter can be done two ways: one global counter for the whole World, or a counter per component type. The original plan had the global one. The AI and I wrote both and compared them head to head. The per-component counters won — they solve three problems the global model could only paper over with warnings:

• components attached before any system runs are visible on a system's very first pass (counters start at 1, the reader's baseline at 0);
• a tuple-join driver doesn't mark the extra entities that never made it into the join;
• entities spawned through Commands reach an Added reaction the next frame.

The global version didn't get thrown out — it sits on a branch as a monument. And somewhere along the way it turned out the u32 counter will eventually overflow, and the naive "tick greater than baseline" check quietly breaks at the wrap. The cure is comparing relative age with the wrap in mind (current - tick < current - baseline). A genre classic: the feature works, and then you spend half a day thinking about what happens four billion ticks from now.

And how badly we lose

With stage one wrapped up, I put together a benchmark harness: spark-ecs against five live ECS on one machine. Here's the gist (10k entities, single-threaded, Apple M4 Pro; lower is better):

In short: on reads we're about 3–4× slower than the leaders, on writes about five. Sounds like a death sentence. But before I start the sackcloth and ashes, three caveats:

1. This is single-threaded. Spark has no parallel scheduler yet (that's M4), and Bevy's defining superpower — its parallel scheduler — is switched off here too. So it's an honest snapshot of "where I am right now," but it is not the real gap to Bevy. That one opens up under multithreading, which nobody runs here.
2. This is a pure-traversal test — archetypes' best friend and a sparse set's worst enemy. The scenario a sparse set is built for in the first place (cheap insert / remove with no migrations between tables) isn't measured here at all. So my architecture hasn't even played its own home game yet.
3. Writes are slower for a reason — every &mut goes through that changed_tick stamp. That's the price of change detection, which half the rivals don't even do by default.

The bright spot is the dependencies. Spark drags in 6 crates. Bevy, 59. I'm second only to hecs, and that's with everything written on the bare standard library. On memory, a solid mid-table finish. So for a naive, from-scratch sparse set, three-to-four times slower on someone else's turf is, honestly, not that bad.

What's next

The benchmark itself is the plan. It pins down the "today" point so future work can be measured as a delta on the same machine, not on vibes.

Next up is a detailed performance inventory: run not just iter and spawn but every slice of the API, and dump it all into a report with numbers. After that, an AI optimization pass — this time with those numbers in hand.

The one lever I'm sure of is M4: Rayon and the parallel executor. But Stage 24, the move to archetypes, I haven't decided. I kept the API stable from day one precisely to keep that option open — but it's an option, not a promise. Shipyard, on the same sparse set, posts very respectable numbers (on reads it's faster than every archetype engine in the field). So my deficit is the naive implementation, not the architecture, which means maybe I don't need archetypes at all — just a sparse set polished to a shine. Do I even need archetypes? I don't know yet — but now I can answer that with numbers and an AI, not a guess.

I wanted to climb into the skin of the people who live inside all that and actually understand it. So an idea was born: make a game about power grids. I called it Spark.

But just making games is boring

Just grinding out a game bores me. I want to experiment with AI on the side and learn something myself in the process. I've taken runs at this before (a game engine in Rust), so why not resurrect it. My first project bored me at the exact moment I reached the renderer: I slammed into a wall of problems with the Shipyard ECS. It was never built to be used like that.

My brilliantly dumb idea

And here comes my favourite genre of idea: brilliantly dumb, as usual. What if I threw out almost the whole engine, every last bit of its API, and replaced it with one single ECS? Sounds unhinged, I know.

Let everything in the engine be one of three things. There are components, and there are loads of them. A resource is the thing there's exactly one of. Systems are where all the logic lives. And then the fun part: the renderer, the asset manager, the camera, the audio are just resources too. Any system that needs one simply asks for it by name. One world, one set of rules for everything.

Since every system says up front what it reads and writes, I can build a scheduler that scatters the non-overlapping tasks across threads, and the whole thing runs in parallel on its own. Which is exactly why the ECS ended up the heart of the engine rather than just one of its parts.

In code it looks roughly like this. No "engine object" with methods — there's a World, and everything lives in it:

// In Spark there is no "engine object" with methods. There is a World, and
// everything lives inside it — as a Resource (one of a kind) or an Entity
// (many of a kind). The renderer, the GPU, the input, the power grid: all
// just Resources. Nothing hidden away in global statics.

#[derive(Resource)]
struct RenderContext {
    device: wgpu::Device,
    queue: wgpu::Queue,
    surface: wgpu::Surface<'static>,
}

#[derive(Resource, Default)]
struct PowerNetwork {
    supply: f32,
    demand: f32,
    ratio: f32,
}

// A system is just a function. Its parameters declare what it touches —
// and the scheduler hands it exactly that, nothing more.
fn balance_grid(mut grid: ResMut<PowerNetwork>) {
    grid.ratio = grid.supply / grid.demand.max(1.0);
}

Why not just take Bevy or Shipyard

Fair question: why build my own when Bevy and Shipyard exist. I love Bevy's syntax — it's noticeably more logical than Shipyard's. But Shipyard has workloads, and those are done beautifully. And I plain cannot choose.

Bevy's also a monster. And Shipyard's no picnic either. And the day I need something that isn't there and isn't supported, no AI is going to pull it out for me — because I don't even roughly know how these things work on the inside. Which is the real reason for the whole exercise: I want to understand. At least at the level of the data structures and the decisions the authors of such libraries make. Why it runs so fast. What compromises they made to get there.

Here's the same thing in both. Bevy:

// Bevy — a system is a plain function; you ask for data by its type.
fn movement(mut query: Query<(&mut Position, &Velocity)>) {
    for (mut pos, vel) in &mut query {
        pos.x += vel.x;
        pos.y += vel.y;
    }
}

let mut schedule = Schedule::default();
schedule.add_systems(movement);

Shipyard:

// Shipyard — a system takes "views" into storages, then iterates them.
fn movement(mut positions: ViewMut<Position>, velocities: View<Velocity>) {
    for (mut pos, vel) in (&mut positions, &velocities).iter() {
        pos.x += vel.x;
        pos.y += vel.y;
    }
}

world.run(movement);

And here are the workloads from Shipyard I want to steal. You name a batch of systems, hand it to the world, and it works out from the "views" which systems can run in parallel:

// Shipyard workloads — name a batch of systems, add it to the world, and it
// works out which ones can run in parallel from the views they borrow.
Workload::new("simulation")
    .with_system(movement)
    .with_system(collide)
    .add_to_world(&world)
    .unwrap();

world.run_workload("simulation").unwrap();

So Spark robs them both. Bevy's function-systems, Shipyard's named workloads:

// Spark steals from both: Bevy's function-systems, Shipyard's named workloads.
// Because every system spells out what it reads and writes, the scheduler can
// batch the ones that don't collide and run them on separate threads.
app.add_workload(Workload::PowerGrid, Schedule::FixedUpdate, |w| {
    w.add(collect_supply);                      // reads plants
    w.add(compute_demand);                      // reads cities — runs in parallel
    w.add(distribute_power).after_all_prior();  // needs both, so it waits
});

A different approach than Moku

My son showed an interest too — he might end up taking part in something. And I want to come at this project from a different angle. If Moku is the story where code generation sits at the centre (fire off a prompt, go watch a show), here I want the exact opposite. To climb into the code it generates. To understand, at least in part, why it picks one solution over another. How it sits in memory. And to design an API I personally consider right. Most likely that same mix of Bevy and Shipyard.

I'm also curious to see how the models write Rust. At TypeScript, frankly, they're so-so.

How the development actually works

I'm doing it in stages, and there's one principle the whole thing rests on. First we kick the general idea around — goals, a rough API. That conversation turns into a design document: ECS, renderer, asset server, the lot. Then a roadmap, sliced into stages. A task gets filed, and the AI takes on the implementation. When the PR is ready I look it over, try to understand it, talk it through with an AI to make sure I really get how and why it works (or doesn't). I propose edits. I accept, we merge, on to the next task. A plan is good. A false sense of control.

Codex or Claude Code only ever touch the code, nothing else. All the discussion happens with ordinary, non-code agents. Why it matters: I don't want the agent I'm hashing decisions out with to know anything about the code, or to dig into it and clog its context. Let it talk things through with me, not reach in to "fix" things and, as usual, break them.

Let's see where I tap out

So, an ambitious plan. Let's see where I fold this time. Last time it was the second implementation of a WebGPU renderer. Will I get any further?

And of course, the moment that idea landed, everyone started bolting on clever little plugins, skills, call them what you like, anything to make the prompt behave, and behave long enough to deliver. There will be stages. There will be a review of every stage of the project. GSD was the first of these I tried, and I was genuinely stunned: it created the appearance of serious engineering. Then came a thousand more equally clever schemes for manufacturing activity and the feeling that the software you ordered is almost here. You have a plan. You have a spec. Everything is under control. The thing is so easy to drive that I sat my wife down in front of it, and she had no trouble at all; she only called me over to answer the technical questions. Tell me that's not a fairy tale.

Not quite a fairy tale

The idea is genius from every angle: pennies in, everything you ever wanted out, all rosy.

...Well. Not quite. And not so rosy. What you actually get goes more like this: it'll probably even boot, but the bug count will be spectacular. You'll debug till you're blue in the face, fixing it through the AI, naturally, and what you end up with is a hundred spaghetti functions. It sort of works, but at any given moment something somewhere is broken, visually or invisibly, and working out what's actually going on is no longer humanly possible.

And none of the generated stuff, I noticed, has a unifying concept. No idea of how the whole thing hangs together. Everything touches everything, every API gets yanked from everywhere, state gets dumped wherever it happened to land. That is not how you build software. Okay, fine, it is, people do. But if you want something that works and can be maintained and extended later, you need an idea of the architecture. A simple one, like a tree. Because the AI isn't fond of following instructions, so the architecture has to be obvious. To the human and to the machine.

So Moku Core was born

A system of plugins that together assemble an application. Each piece lives isolated inside its own plugin. What goes in and how it's configured is the entry point's call. How a plugin works on the inside is nobody's business, as long as it works and honours its contract.

// A plugin is one self-contained contract: its config, its state, and the API it hands out.
export const routerPlugin = createPlugin("router", {

  // config — the defaults; every key becomes optional for whoever uses the plugin.
  config: { basePath: "/", notFoundRedirect: "/404" },

  // createState — private mutable state, owned by this plugin and nobody else.
  createState: () => ({ currentPath: "/", history: [] as string[] }),

  // events — declare what this plugin emits, with typed payloads.
  events: (register) => ({
    "router:navigate": register<{ from: string; to: string }>("Fired after navigation")
  }),

  // api — the public surface, mounted on `app.router`.
  api: (ctx) => ({

    // Become: app.router.navigate("/about");
    navigate: (path: string) => {
      ctx.state.history.push(ctx.state.currentPath); // remember where we were
      ctx.state.currentPath = path; // move to the new path
      // emit — announce it so any plugin listening to "router:navigate" can react
      ctx.emit("router:navigate", { from: ctx.state.history.at(-1)!, to: path });
    },

    // Become: app.router.current();
    current: () => ctx.state.currentPath // read the current path
  })
});

// Subscribing — another plugin depends on router and reacts to its events:
export const analyticsPlugin = createPlugin("analytics", {

  // defaults again — the entry point overrides this below
  config: { trackingId: "" },

  // unlocks the typed "router:*" events below
  depends: [routerPlugin],

  // runs on every "router:navigate" — the payload type comes from the declaration
  hooks: (ctx) => ({
    "router:navigate": ({ from, to }) =>
      console.log(`[${ctx.config.trackingId}] page view: ${from} -> ${to}`)
  })
});

Every plugin declares its contract: its state, the events it subscribes to, the API it exposes, and the helpers it throws out into the open. Which means that by reading one file, you can tell exactly how badly the AI botched the design of that plugin. And the entry point just gathers them up:

// The entry point decides what goes in and how it's configured:
const app = createApp({

  // order matters — analytics depends on router, so router comes first
  plugins: [routerPlugin, analyticsPlugin, blogPlugin],

  pluginConfigs: {
    router: { basePath: "/blog" }, // overrides the "/" default declared by the plugin
    analytics: { trackingId: "G-XXXXX" },
    blog: { postsPerPage: 5 }
  }
});

// In client code you just call the typed API — autocompleted, no imports, no globals:
app.router.navigate("/about"); // analytics logs: [G-XXXXX] page view: / -> /about
app.router.current(); // "/about"
app.blog.listPosts(); // 5 per page — straight from the config above

You can extend them, complicate them. There's a way to test them deterministically. And the whole thing is packed as minimally as it goes, plus it hands you the freshest guarantees there are, like type safety — the kind TypeScript can actually prove. The point is to shrink the room for error as hard as the language will let you.

A month on a spec, not on code

I sat with this idea for about a month, not over code, over the spec. Mostly I had the AI model different situations against my API. I've tried to build a plugin system like this many times before, at work and in my own game engines; the idea keeps resurfacing. Case in point: Beavy, my dream project — a game engine in Rust. I think it's genuinely brilliant, and I draw inspiration from it (lying) at every opportunity.

The spec took a month. I had to work through a pile of variants: how to run it in the browser, how from the console, how on Node, how to make things isomorphic, how to drive coupling down to nothing. I have never in my life sweated so hard over documentation and the endless debugging of this stuff. The AI writes docs beautifully. Coding, though, is not the AI's strong suit.

Three layers

I also arrived at the idea that the structure has to be three layers deep.

The kernel stays ascetic. The framework on top of it exists to hoard all the patterns of one specific kind of software (web, a client app, whatever), purely to spare you the endless AI-debugging when you get to the app. And the app on top of that just uses the framework. So the bottom is a licked-clean kernel; one floor up we relax a little and generate a ton of code, sorted neatly by plugin; and at the top sits client code that answers for the visual part alone. The interface, roughly speaking.

For now, it's all theory

And that is how the project was born.

One thing to keep in mind: there is no second layer yet, and no third. It's all pure theory. I'm hoping they show up soon, so I can finally test the architecture I've been dreaming about.

I studied the mechanic and set myself a task. I had exactly eight days — no more, no less. I had to make the game with AI as fast as possible, at the best quality possible. All the code, all the graphics, the concept art, everything — AI. Me, I only orchestrate: I organize the gameplay and decide what gets done and how. That's how Screw Master happened: my first attempt at making a game without making it with my own hands.

I'm Not an Animal — I Don't Poke Buttons

I started with the code: ODIE (one of our internal engines, a classic ECS) with PixiJS 8 doing the rendering. The first thing I did was tighten every TypeScript validation as strictly as it would go, and I decided up front: testing would be automatic, and the game would be built from day one with self-verification in mind. I'm not an animal — I don't poke buttons by hand.

The idea was this: Playwright plays the game. It gets the whole harness and the instrumentation to do it: access to input, access to the render graph, access to the ECS. Every feature is proven by video: the AI builds something, opens a PR, attaches a recording — I watch it, decide whether I like what I see, and give feedback. No "trust me, it works." Here's the footage, see for yourself.

And here, in fact, is what came out of it. You can unscrew a few bolts without leaving the article:

All the code is on GitHub, PRs and video proofs and all: AlexTiTanium/screw-master.

Figma, MCP, and the Battle for Sanity

The entire interface went through Figma. I assembled the scenes the way they were supposed to look, then the Figma MCP gave the model access to the data and the assets — and the UI got built from that.

A whole separate problem was teaching that MCP and the model to be friends and not build nonsense. I had to go deep into Figma: structure every component with ruthless logic, so that what came out the other end was something sane instead of gibberish. I spent ages picking components so they'd all sit in more or less one style. Generating identical models in a different color — same suffering.

Bugs Are What AI Generates Best

And now for the biggest problem of all.

Bugs are what AI generates best. And what bugs — honestly, you just stand there marveling.

The real challenge was even explaining what the bug was. Especially when the AI had to do something concrete: say, several animations have to drop bolts onto their slots at the same time. It simply lost its mind over that. No, you can't do it the pretty way, with a queue or a stack — you need exactly this weird contraption and nothing else: cancelling promises, pausing them. Basically the most direct way to pile up problems for yourself. Hundreds of prompts. Pure pain.

So, Can You Make Games This Way?

I'd say the experiment ended on a positive note: I took it all the way to the finish. What I learned for myself: building a prototype with AI is completely fine. Building a product… that I honestly don't know. You'd have to be cocky. Very, very cocky.

Image generation wasn't great either: you'd order red bolts and get mushrooms. Why? No idea. Maybe the shape, maybe the color. But like everything in this world, enough work, nerves, and swearing gets you something more or less not-terrible.

Is it faster to just do it by hand? For code — the other way around, actually: by hand is faster. But only if you don't count the tests, of which there are more than the code itself — so, nuances. For the art — I could never have drawn it myself, but any artist would have done it better. So draw your own conclusions. The bar will probably rise, and projects like this will become genuinely possible. Right now, the level of quality AI can carry is an MVP or a prototype. Past that, it's a lottery.

But I learned a lot for myself: Figma, how to do e2e tests — and how not to do them. So I count the experience as a win. I'd love to have more time for things like this, but alas: a day has 24 hours, food doesn't earn itself, and the kid needs to get to school. So I had my fun. That'll do.

Gloomhaven: Jaws of the Lion

A masterpiece of a dungeon crawler. On paper it's a fairly brainy game and you need to know how to play it, but god, the balance, the synergy between the cards and your character. I don't know how they do it, but you win on your last card, on your last hit point. And when you lose, you always know exactly what you did wrong. Tons of scenarios, four characters in the box with real progression, a quick and painless setup, and the best part — the price: fifty bucks for a good fifty hours of content! I don't recommend its big brother with a 120-hour campaign, or the new Frosthaven, which runs god knows how long, because realistically you don't have that much life left, and your friends certainly don't. Components, gameplay, replayability, and that price — I don't think anything has topped this little box. An absolutely brilliant game, can't recommend it enough. My wife and I run it as a two-player game; getting a bigger party together is the hard part.

Terraforming Mars

Terraforming Mars is something else. Over two hundred cards, unbelievable combinations of things you can build, and no two games ever look alike. I don't know what you call the genre where you get a huge pile of cards and try to squeeze the maximum out of a random deal every time, but every game is a battle with my wife and every game is a new experience. Fair warning: the standard edition has some issues with component quality and the player boards, so buy the organizer and the proper dual-layer boards right away. I also picked up metal cubes, but that's pure indulgence. As a two-player game it's an absolute hit in our family.

<>

Clank!

The Clank! series, from the regular one to the legacy version: grab any of them, you can't go wrong. Very simple, very fun, best with three to five players. It doesn't run long, if you don't drag it out, and there are plenty of ways to throw a friend under the bus. What else do you need.

Detective

My wife and I adore detective shows: Castle, The Mentalist, Bones, Columbo (if you're old enough) — all rewatched twenty times over. And there are board games that let you step into those detectives' shoes and try to crack a case yourself. There are quite a few, some harder than others, but the one that stuck with me is Detective: A Modern Crime Board Game. You'll need a computer. The game essentially hands you a simulated police database and leans heavily on the actual internet for solving its puzzles. I can't spoil any more than that, sadly. You have to play it yourself and enjoy the process. Not all the cases are equally good, but some are genuinely excellent.

Unlock!

Escape rooms: you can play these at the table instead of grimy basements and secret rooms in apartment blocks (those who've been know exactly what I mean). Sure, the weird rooms and flats have their charm, all those physical gimmicks. But if you really want to play at home, the Unlock! series is our favorite: clever, logical escape quests (hi, Exit), an app that gives you hints and makes the whole thing more interactive, and a different style and theme every time — you genuinely feel the atmosphere of each adventure. The downside, same as every game of this kind: they're one-shot. Once you've solved it, sell it, gift it, or shelve it until you forget what was inside.

Brass: Birmingham

I love economic games: money, income, all of that. But I despise Monopoly — a game where you literally decide nothing and nothing depends on you. It's nonsense; how people keep fussing over it, and why, is beyond me. Thank god there are proper games where your decisions matter and decide the outcome, and most importantly, shape the outcome for your opponents. The Brass series by Martin Wallace is my favorite. The components are superb: the deluxe version has literal poker chips, the board looks downright gorgeous, and the whole art direction is stylish as hell. Very unusual mechanics (this isn't your dice-chucking) and the best interaction model I've seen in this kind of game: everyone at the table depends on everyone else and on each other's decisions. I've seen proper backstabbing there, and I've seen genius moves where you literally force your opponent to play the way you need them to. Nobody here gets to quietly tend their own garden: it's direct competition inside one interconnected system. Highly recommended. Two to four players, but four is where it gets really interesting.

London

My little love, and Martin Wallace again, see above. London is a small box with a ridiculous number of clever mechanics inside. It's strictly a card game: there is a board, but it's nominal. There's a caveat, of course. Know the deck well and some cards are clearly better than others. I honestly can't explain why I love it so much, but I do, for the life of me. It's a balancing act between wealth and poverty, where you rake in a pile of money and then blow it all on other cards, where you live on the edge between failure and success. One wrong decision and you're simply done; one right one, plus some luck with the cards, and you're riding high. That emotional ride is probably why I love it. Strictly two players. And I won't even recommend it: it's my game, and good luck finding a copy these days anyway. But if you ever see one — take it, you won't regret it.

Through the Ages

The monster civilization game, the mother and father of all civilization games. Through the Ages is a minimum, again, a minimum of eight hours of uninterrupted play with two players. Don't even attempt it with three or four: you will never, ever finish. The game has three small boards, no world map at all, really just mats for holding playing cards. And hundreds of cards: war is in there, peace, science, culture. How any of this works, I have no idea, but it works. You sit down intending to quietly build a civilization with your wife and see who scores more points, and it all rapidly turns into a bloodbath: the constant threat of war, resource shortages, the fight for colonies. And all of it on ordinary playing cards. How, tell me, how does this all work?! I can only recommend it if you're a proper geek. Not just any geek — that exact breed of nerd who's ready to fight with a friend or a spouse for eight hours straight — and not fall out, and not get divorced, when that snake declares war on you out of nowhere.

<>

Mage Knight

Some games have mechanics better than the game itself. The deck-building in Mage Knight is absolutely brilliant, but everything around it is so convoluted that I'm not prepared to actually play it. I just sit down sometimes purely for the deck-building system itself, for that card synergy: chaining combo after combo, wriggling like an eel in a frying pan to squeeze out one more play and deal damage to some nameless monster. At its core it's tabletop Heroes of Might and Magic: you move, you flip a tile, you hire units, you kill monsters — that's it, there's nothing else. I could spend hours criticizing this game: how tangled it is, how dull the missions are, how arbitrary the random monsters feel. But god, the card mechanics in there are gorgeous. Oh, if only there were an option to get this engine in some other wrapper.

<>

Alchemists

There's this thing called a puzzle. Now imagine solving a puzzle while playing a board game: that's Alchemists. I haven't played a harder game — and not because the rules are complicated. The point is that you have to crack something like a sudoku puzzle and somehow play the game at the same time. Your solution, even a partial one, has to be woven into your play: publishing theories, debunking your rival's publications and even your own, taking risks, guessing, exploiting your opponent to extract more information for the puzzle. Only to find out later that you got it wrong, solved the whole thing incorrectly — and won anyway. That's Alchemists for you.

<>

Cosmic Encounter

There's a pile of social games out there: all the Mafias, Dixits, Imaginariums, Codenames. They're fun for a couple of plays, then it all starts wearing thin: you get the emotions, but mechanically it's, well, whatever. And there's one game that simply tears those Mafias and Dixits apart in a single breath. Betrayal on the level of Cosmic Encounter you have never seen or experienced in your life. The box holds fifty aliens, broken from start to finish. Some swap cards with you. Some get to peek at the combat card the whole battle hinges on. There's even a Bride character who picks herself a husband and can look at his cards, the husband can't attack her, and when she divorces him, she takes half his cards. Can you picture the level of madness at a table with characters like these? If you haven't played it you won't get it, and if you have, you already know exactly what I mean. This game destroyed every social game for me. The fun bar is set so high that nothing else even comes close.

So that's my little selection. Have fun out there.

Photos: El Pantera, wetwebwork, JIP · CC BY-SA / CC BY. Press photos: © Cephalofair Games, Dire Wolf Digital, Portal Games, Space Cowboys. The rest of the photos are mine.

In the darkest depths of Terrinoth, an ambitious overlord gathers his minions to lay siege on the world above. Only a small band of heroes, gifted with courage and power, will be able to save the land from the cold grip of domination. Now is the time to venture into the dark and unravel the overlord's plot before it's too late...

What the game is about

The game is about the epic adventure of heroes in the dungeons of a Dark Evil Overlord who won't miss a chance to show the heroes who's boss. It's a game for 2--5 players -- where am I supposed to find that many friends? One player takes on the role of universal evil and becomes the Overlord. The rest become regular heroes, divided into classes and archetypes. Heroes roam dungeons, search for treasure, fight the Overlord's minions, buy equipment... in short, they go all out.

All combat is dice-rolling -- there are both melee and ranged attacks. And of course spells, lots of spells. Can't do without them -- it's fantasy, after all.

The game features both standalone missions and campaigns. A campaign is a set of individual missions tied together by an overarching story. Heroes can carry their hard-earned (read: looted) gear into the next mission, accumulating a small fortune by the end of the campaign. You won't finish a campaign in a single day -- it takes dozens of hours, and the game thoughtfully provides a save system: a notebook and pencil.

<>

Impressions

Haven't actually played yet -- haven't even finished reading the rules (a 20-page booklet). But I'll definitely report back once I get the chance to try it.

The miniatures are impressive -- they're quite detailed and genuinely menacing. I liked the tile system: you lay out the dungeon map from tiles, and since there are so many of them, it gives the game great replayability and variety.

<>

On the downside, there's the balance issue. From what I've read in the rules, playing the Overlord seems kind of dull, and the heroes almost always have the upper hand -- they're essentially immortal.

<>

<>

Main stack

Plain JavaScript ES5

JS modules in CommonJS format (like Node.js, but on the frontend)

Webpack 1.x -- not sure 2.x is solid yet; even the first branch is still rough (IMHO). We'll see, maybe we'll migrate.

Rendering by PIXI JS

Using PHASER IO as the game engine

CSS generated from Less -- I just like it

You can follow the project's progress on GitHub: STDS. Too early to think about the server side, but it'll most likely be Node.js.

Beautiful code... let's talk about that, shall we?

Recently I was listening to Radio-T (a popular Russian tech podcast) -- don't remember which episode, one of the recent ones -- where they discussed an article about outsourcing.

Yet another client decided to save money and ordered iOS app development from the cheapest company they could find on the internet. The result is obvious: a complete disaster. And he goes point by point explaining why, in his opinion, everything went wrong.

Of course nobody's willing to admit the correlation between price and quality. It must be something else, right? You want to believe you can get the best for five bucks an hour. Though you should understand that a big price tag doesn't guarantee anything either.

There was a lot of back-and-forth on this topic. Umputun's brief take was that there's a difference in mentality: for Americans, the result is everything, the process is nothing. For Russians, the process is everything, and the result is a side effect. For Indians, one thing's rubbish, another thing's rubbish -- life's too short to sweat it.

So I'm sitting there thinking: damn, there's something to this. Should you even bother with the process?

After all, the client needs results, and what am I doing? I'm fussing over the process. Sure, I fuss over it to produce the best result I'm capable of, but you could get results faster.

The task: write a simple autocomplete for a service. Just shove everything into the damn controller that renders the list of results and call it a day.

But no, I have to extract it into a separate controller, refactor it -- because someone will come along to maintain this, and what will they think of me?

And what about the server side? A normal, efficient programmer would just regex through the database and be done with it. Result achieved.

But no, we're "special." Everything has to be fast, and the autocomplete has to actually help you type something. Instead of regex search, let's build a prefix tree? And let's add tag weights to surface the most popular ones first. And of course we need tests and documentation.

And just like that, I'm deep in the weeds of process.

This is not results. The client doesn't need any of this. Not only doesn't need it, but it's actively harmful -- financially and deadline-wise. And in a year they'll rewrite the whole thing anyway, if anyone still cares.

Maybe subconsciously I realize I'm paid by the hour, and if I do it in one hour instead of ten, I'll earn less? No, that's not it -- I did the same thing back when I worked for a fixed price.

What's bad is that for me this is a conscious choice. I don't want to change, to adapt to the market. (Probably why the last time I looked for a job it took me about three months.)

Kill me, but I want to write proper code. And proper code takes time, and time is money. The conclusion: by all rights, I should be fired. In this unequal battle between process and results, I'm the broken gear.

Beautiful code to you all, friends!

Programming

This part's simple -- me and Nikita Sidorenko (Division). People say two programmers on one simple Flash game is too many. I categorically disagree. In practice, if you write a game solo, you eventually give up. Maybe it's just us, but trust me, we tried -- working as a pair is both more fun and more productive. I explain it through guilt: if one person is working on something, the other feels ashamed for slacking and starts pitching in.

Design

Everything starts with design, and in a quality game it's front and center. As you know, I was the one who drew (read: borrowed) the art for the previous version. That flies for a contest, but for a real product you need proper, and most importantly, original art. Kherson is a small city -- everyone knows everyone -- and there aren't many good designers around, so we didn't have to search long for Semyon Khramtsov, the "freelancer from the provinces".

"Even though I didn't particularly like puzzles, the guys' enthusiasm was infectious. First I proposed several art styles, including a stylization of Leonardo's manuscripts. That's the one everyone fell for. Sure, it's a pretty mainstream trick in graphic design, but the allure of synthesizing an interactive environment with that famous sketch style of the Renaissance mega-designer was too strong. I re-read his biography, googled all his works to mine as much flavor for the game as possible -- basically, immersed myself in the right atmosphere as deeply as I could. Of course, I consider the result an affront to his image and inventions, but who are we compared to the Master? Thank God I didn't repaint the game in bright 'casual' colors, as one of the judges suggested at the game-lynch -- we'd definitely be burning in hell for that. My biggest achievement in this project was diving into level design and combining the artist's grim self-portrait with the Mona Lisa's smile :)" -- Semyon Khramtsov

Sound and Music

The last but by no means least area -- the musical and sound design of the game. It doesn't just bring the game to life; it keeps the player from getting bored -- at least until it starts to annoy them. Semyon happened to know a very talented composer he'd been working with on small Flash projects for a while -- Vladimir Marinichev -- which was perfect timing.

"First things first, to immerse myself in the Renaissance atmosphere, I re-watched a biographical film about Leonardo da Vinci and listened to works by composers of that era. For the menu theme, I based it on a piece by Claude Gervaise that would convey the mood of a thoughtful Creator and transport the player to the Renaissance. I tried to keep the arrangement and instrumentation true to the style of that period. For the gameplay sound design, many sounds were recorded using everyday objects. We decided to leave the levels without a musical score and instead convey the atmosphere of a workshop. During gameplay you can hear Leonardo constantly scribbling notes and humming something to himself, engrossed in yet another experiment. Unfortunately, in trying to reduce the game's file size, we had to degrade the quality of all sounds and music, which of course made it harder to realistically convey all the nuances and details. But overall, many people were happy with the result, and it was very gratifying to receive a high rating from FGL." -- Vladimir Marinichev

And so, with the team assembled, off we went...

The Beginning

The first commit was on August 4, 2010 -- that's when you can mark the start of development. We slowly began fixing bugs, and since we all had day jobs, progress was very slow. We set up a task manager, created a pile of tasks, had lots of discussions -- all about nothing, really. In its final form, if you took all the tasks into account, the game should have looked like a mini Starcraft 2 with its own BattleNet (which had just come out at the time -- very distracting). The unrealistic scope of our plans was our first mistake. Don't build enormous castles. You'll abandon most of it once you realize your plans would have surprised even Napoleon. That's exactly what happened to us. We came to our senses when we decided to participate in FlashGamm KYIV 2010. We needed something to show, and we had nothing -- not even a working prototype. That's when the real work began. First we axed most of the tasks, minimized and optimized everything we could. And that produced results.

FlashGamm KYIV 2010

By the start of the conference we'd managed to cobble together something resembling a prototype and build a few lackluster levels. With that, Semyon and Nikita headed to Kyiv. We competed in the Indie category, plus we signed up for the game-lynch (a public critique session) -- oh boy, did they tear us apart... But the game-lynch itself was incredibly useful. They pointed out our game's shortcomings, our mistakes, and gave us advice on where to go next. The encouraging part was that we'd already anticipated many of the flaws they called out. During the audience vote for best game-lynch game, ours scored exactly 0 points (zen mode) -- and after that, none of us expected to win anything at all. But out of nowhere, we won the "Future Hit" nomination! The joy was immense. I think this event had a really positive effect on the team's morale -- we realized there was something to this game and we needed to finish it no matter what.

Wrapping Up

After the conference, development settled into a steady rhythm and everything ran like clockwork. But there were annoying bugs. The first was objects falling through other objects -- a ghost that had haunted us since Ball Factory (the first prototype). We solved it pragmatically, by trial and error. I started tinkering with Box2D settings and found a quirk: changing b2_aabbMultiplier from 0.2 to 0.1 magically fixed the fall-through issue. The second bug crept up from where we least expected. Everywhere we needed a button, we used SimpleButton, and it never even crossed our minds that in newer Flash Player versions, button states would start "sticking" -- and there was no way to fix it no matter what hacks we tried. We had to build our own solution. Discussion on flasher.ru.

Selling the Game

Another thing happened at FlashGamm -- we met Stefan Keisch. We had no idea how to sell a game. There was some information online about FGL (Flash Game License), but it was all vague, and you needed to attract sponsors. That's exactly what Stefan does -- not for free, of course: 30% of the game's sale price. After some thought and deliberation, we accepted the offer. Stefan also gave recommendations on how to make the game more attractive to sponsors. The first thing he pointed out was the name. Our working title was "Balls Da Vinci" -- that's the name we competed under at FlashGamm. Unfortunately, the name triggered too many unwanted associations with Leonardo's manhood (which we found hilarious, admittedly), so we rebranded to "Fun Da Vinci" (maybe it's only a puzzle for us -- for da Vinci's brain, it's child's play).

The listing went up on FGL on January 14, 2011. FGL reviews every game submitted.

Review Information:

Intuitiveness: 7 Good Fun: 6 Average Graphics: 7 Good Sound: 8 Great Quality: 7 Good Overall: 7 Good

Comments: Standard execution of a traditional physics game with a Leonardo da Vinci theme Creative level design, familiar game mechanics, polished interface Lacks depth beyond first playthrough. Consider adding achievements or a scoring mechanism of some sort

Right away someone offered us $1,000, but we wanted more -- at least $3K. That bid sat there for about a month. We were starting to lose hope when suddenly several major portals began competing for the game (I suspect Stefan had something to do with it). Bids rose and fell. We noticed that sponsor activity picked up toward the end of each week. When the bid hit $3,000, we nearly caved and accepted, but a certain bald someone suggested we hold out -- right at that moment, we'd received an offer from jayisgames.com to write a review of the game. We were thrilled -- besides the "street cred" from a well-known portal, it could trigger a new wave of bids. And it did... After another round of sponsor bidding wars, the price settled at $5,600. We strangled our inner cheapskate and accepted. That was another victory. From listing on FGL to accepting the bid: exactly 2 months.

As you've probably guessed, Armor Games won. Sponsors usually ask you to brand the game for their portal -- add an intro, integrate their API, and so on. All easy enough, but we ran into problems with the Armor Games API, which absolutely refused to connect. We made a blank project -- worked perfectly there. In the actual game project -- nope. By some miracle, Nikita figured out that if you initialized the API in the preloader, everything was fine. Weird, but whatever.

Splitting the Money

So, you all want to know how much we made? Here's the breakdown: FGL takes 10% for its services (half of which Stefan pays by agreement); 10% of 5,600 = 560 (FGL's cut); 560 / 2 = 280 (our share of FGL's fee); 30% of 5,600 = 1,680 (Stefan's cut); Bottom line: 5,600 -- 280 -- 1,680 = 3,640.

Three and a half grand split four ways over four months -- not a bad result, for Nigerian guest workers. How to make a living from games alone? -- a question that puzzled us. But our enthusiasm only grew, and we're not giving up this hobby. We'll figure out the answer eventually -- maybe even in the comments to this post ;)

Future Plans

We're already working on a second version with new items, levels, and features. We have ideas for interesting game mechanics and unexplored themes. On the technical side, we're looking toward the App Store and Android Market, with Unity3D to help us get there.

The Contest

For those who don't know, IGDC is a community of people who enjoy making games. A contest is announced, rules are set, and off you go -- anyone can participate. The theme for this particular contest was genuinely interesting: Indirect Control. The idea is that the player has no direct control over the game process. You can only influence things indirectly.

I'd never entered one of these contests before, unlike Nikita, who had even placed in the top ranks. We decided to write in ActionScript 3, which I knew only vaguely. Why AS? Simply because Division had an engine built on AS that used the well-known Decorator pattern -- used it so heavily, in fact, that the engine itself was called Decorator.

When I heard "indirect," the famous puzzle game "The Incredible Machine" came to mind. I got the idea to make something similar but change the goal. In The Incredible Machine, the objective is to get a mechanism working. In our game, you'd make all the balls roll into a specific pipe using various boxes, planks, and -- of course -- physics. Luckily, the Decorator engine supported Box2D, though looking at the relative sizes of the engine and Box2D, it's hard to tell who's supporting whom. Anyway, physics sorted.

Design, hmm... neither I nor Division could draw at all. We decided to offer the honorary position of designer to an acquaintance of mine. He drew a couple of scenes, but then something came up, and we had to draw everything ourselves -- by "ourselves" I mean me.

Development

One key rule of the contest: you have to make the game in 9 days. So work kicked off at a lively pace. I was coming up with the concept, sketching out what everything should look like, while Division was preparing the engine. We used Dropbox for file sharing -- once again convinced that app is indispensable.

The engine prep took about three days and fell squarely on Division's shoulders. But for collaborative work we needed version control. The choice was between Git and SVN. We chose SVN, which we would later regret.

We got into a rhythm pretty quickly. Development happened at night. Since my AS experience left much to be desired, Division would explain over Skype what I was doing wrong. Skype was a huge help on this project, actually -- first, it made things more fun, and second, we could quickly coordinate our tasks and actions.

I fondly remember those sleepless nights. It was genuinely exciting to learn something new (AS) by doing it. I used to think you had to read a thick book before you could start writing in a new language -- how wrong I was. In those 4 days of coding, I learned more than I would from a month of reading a smart book. Sure, I lacked theoretical knowledge, but that was quickly fixed by the school of hard knocks...

The SVN Disaster

Things went smoothly for about four days, but then Saturday came -- the turning point. We wrecked SVN. Here's how it went down... I pushed a new commit, Division was supposed to update his repo, but there was a conflict that needed manual resolution. Out of inexperience, Division clicked the wrong thing or pressed the wrong button, and wrecked one file. All his changes in that file were lost. And of course, stupidity never comes alone... In a move that was more dumb than inexperienced, I advised him to roll back to the previous revision, assuming he'd committed before that. Naturally, the previous revision wiped out an entire day's work... We were livid. The submission deadline was the next day, and we hadn't even built the levels yet -- and as if by Murphy's Law, the most complex and tangled part got erased.

Nothing to do about it -- Division had to restore everything. Morale was dented, but the payoff was worth it: we ended up with a solid level editor and a pretty good-looking game (you're welcome, that was my design work).

The Disqualification and Redemption

Murphy's Law, act two... According to contest rules, you could be a day late with a 30% penalty, but you had to notify the organizer. Of course we weren't going to make it, and we'd known it beforehand. In the relevant IGDC forum thread, Nikita had been voicing concerns and guesses that we wouldn't finish on time. We weren't sure yet, so we warned them more explicitly once we realized our earlier posts hadn't been taken as an official late notice. The organizer said "why so late?" but nothing more. We were drawing levels until about 3 AM (with work in 4 hours). We'd wanted to submit earlier, but as always, things never go the way you want. Realizing we were looking at the full 30% penalty, we went to sleep. During the day, in breaks between my day job, I kept tweaking levels, fixing issues, preparing the game for release. And then, like a bolt from the blue -- we get disqualified. For being late. I was honestly in shock. So much effort and soul poured in, it was really upsetting. But what can you do -- we packed the archive and sent it off.

Dragging myself home, I bought a bunch of junk food -- chips and cookies -- to at least console myself somehow. Got home and crashed without even reaching the cookies or chips. Around 10 PM, my wife wakes me up with great news -- the admin reversed the disqualification! The joy was beyond words. Special thanks to the admin! The world was right again... We're in the fight... We're competing... And we wait for the scores...

Lessons Learned

Lessons I took away: -- Learn by doing. -- Making games is fun. -- To hell with SVN. Next project, we're using Git.