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.

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:

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.