Skip to content

Paolo's Blog Posts

Clone a Game with AI: Should This Be Done?

Published by Paolo Gambardella on 09/11/2026

This post was originally written in Italian by Paolo Gambardella. It has been translated by an AI agent and may contain inaccuracies.

Mark Brown, the creator of Game Maker’s Toolkit, has published a video in which he tells a story that could apply to anyone making games today, big studios or solo devs alike.

What happened

Two Hungarian developers, working as a hobby project, used Claude Code to build a word game that they themselves describe as “Word Play with a bunch of extra stuff on top”. Word Play is the word roguelike Mark released in 2025. It took them eleven days, and they added a time mode, a daily challenge, multiplayer, and a meta-progression system. Before doing anything with it, they emailed Mark to ask what he thought, and promised to keep the game private if he wasn’t comfortable with it.

Mark spent twenty minutes thinking out loud: he’s losing money on it, clones have always existed, he’s not a fan of AI, and their game is better than his in some respects. In the end he didn’t reach a conclusion and asked his viewers for their opinion.

I watched the video from a particular vantage point, because I use these tools every day. I work with Claude and ChatGPT together, each one checking the other. At work, at GSC, I use them to build prototypes, update documentation, make sense of the many texts written in Ukrainian, and cross-reference information across a huge number of documents. At home, this blog has expanded to nine languages, and I’ve picked my dog game back up: on one side I’m migrating it from Blueprint to C++, on the other I’m laying the groundwork for the mechanics and game feel. The results genuinely surprise me.

In my view, the two Hungarians did the right thing. They built something they cared about and, before going public, they asked. What they made is legitimate. Mark is right to be concerned — Word Play still brings in revenue every month — but if I were in his position, I’d see it as an opportunity. Two people who’ve put hundreds of hours into your game, who know it inside out and have already built the features you never got round to finishing: why not bring them into the original project? They could handle live ops, updates, new modes. Mark himself admits he was too burnt out after launch to keep working on it. That strikes me as a far more productive path than a video spent airing grievances.

Clone or homage?

Where’s the line? For me, cloning means “I don’t care about the thing itself, I only care about the outcome.” Inspiration — even outright copying — can be a wonderful way of paying tribute to what came before. Word Play itself comes from Balatro, which comes from Luck Be a Landlord, which comes from Slay the Spire.

The line is about how much you care that the thing actually exists, for its own sake. There’s really only one question worth asking: does this thing deserve to be made? The money and the followers come later.

There’s a moment in the video that stuck with me. Mark reads through the chat logs and sees Claude add twenty-one modifiers in one go — something that had taken him months to code. I understand the frustration, and it’s a perfectly natural reaction. A farmer today uses a machine to do what once took hours with a scythe. Nobody expects him to miss the scythe.

Mark also mentions Lucas Pope, the creator of Papers, Please, who stopped talking about his games before release out of fear of clones. That’s his call and I respect it. Even so, I’m convinced that people will always prefer a new Lucas Pope game to any potential clone of one. Players follow the author — their sensibility, their perspective, the way they see the world.

Then there’s the advice from a Valve executive: don’t rely on a single mechanic, because it’s too easy to copy. Advice — especially from people who aren’t in the trenches — should always be taken with a pinch of salt.

If your game finds a market, a single mechanic can be enough. The real work starts afterwards, when you have to sustain it. And this is where technology plays in our favour: today it’s affordable to grow games that previously weren’t worth maintaining at all. The very tool that’s worrying Mark could help him pick Word Play back up and finish the daily challenge and speedrun mode that, by his own admission, he left half-written in the codebase.

What I’m taking away from this

Mark received that email and was able to turn it into a video watched by a huge number of people, because years of work had earned him an audience. That’s the real asset: the people following you are waiting for your next game, and anyone can rewrite the code in twelve minutes. So let’s use these new tools to help the things that deserve to grow grow better.

What would you say to Mark? And what would you say to the two Hungarians? Feel free to reach out directly on LinkedIn.

More dialogue, less megaphone

Published by Paolo Gambardella on 06/11/2026

This post was originally written in Italian by Paolo Gambardella. It has been translated by an AI agent and may contain inaccuracies.

Ho voglia di rinnovare un po’ le mie iniziative online. Finora il blog, LinkedIn e qualche podcast sono stati i miei tre pilastri. Adesso però l’editore si è svegliato e si impegnerà a rivedere il mio libro e ad aiutarmi a raggiungere i potenziali lettori, quindi voglio migliorare il mio modo di comunicare.

Game Design in Practice

The book is called Game Design in Practice: A Professional’s Guide to Entertainment Ideation and it’s published by Jettelly, a Toronto-based publisher that produces books and courses for video game developers.

It’s a practical guide to the ideation phase — the moment when a rough idea takes shape and becomes a concept. I’ve packed into it everything I’ve learned over years of mobile and indie development: understanding what players are looking for from entertainment, looking beyond genre labels to find a game’s core experience, brainstorming with the team, building playable prototypes, and finally pitching your vision through briefs, pitch decks, and demos.

It’ll come out in English, as an ebook, one chapter at a time. If you’re interested, you can already sign up to the wishlist on the book’s page.

Until now I’ve used these channels in a one-way fashion. Public comments don’t really appeal to me — partly because I often end up having to moderate them. I prefer private contact, which allows for real relationships and genuine conversations with people. It’s brought me a lot of joy and some new friends. So the time has come to rethink my communication strategy and make it easier for those kinds of connections to happen.

Alongside the book I’m developing a few game ideas, so I might add a video dimension to all this. I’m thinking short vertical videos where I comment on a video game while it’s playing on screen — what works, what I’d change, what’s the idea underneath it all. With one twist: the game would be mine. That way I could reach people who respond better to visual content, and who knows, new opportunities might open up. It’s also a way of checking how fresh my ideas actually are, so sooner or later I’ll give it a go.

One challenge is language. Italian is my mother tongue, but my Italian has been coloured by Castilian Spanish, since I’ve been living in Spain for a long time. I make mistakes and use constructions that you simply wouldn’t hear back in Italy; the result is understandable, but not good enough for my perfectionist streak. English is the language of business, but there’s an enormous amount of English-language content out there, and I think native speakers use a richer, more varied register than I can manage. Spanish could also work, but I’m not sure. Which language would you prefer to read and listen to me in?

That’s all the news for today: I’m pressing on with the book and carrying on making my games. I can only do this thanks to new technologies, which let me juggle several things at once by building my own tools from scratch.

If you have any advice — on language, on the videos, or on anything else — feel free to drop me a private message on LinkedIn: I’m all ears.

Investing Means Making a Commitment

Published by Paolo Gambardella on 27/10/2026

This post was originally written in Italian by Paolo Gambardella. It has been translated by an AI agent and may contain inaccuracies.

Some time ago I wrote a fairy tale, and I found an artist who’s helping me bring it to life visually. She sends me sketches every week for review, I give her feedback, she applies it — sixteen images in total. This is taking up a huge amount of my time, and it all started from a desire to leave something behind for my daughter, just in case I disappear too soon. I’m not expecting success, or to sell millions of copies — I’m well aware of the quality of my writing and my limitations. I’m doing this purely for the joy of creating.

Machine learning helped me visualise this fairy tale, and it pushed me to look for a professional to illustrate it. That’s certainly a good thing, but I have to say it’s eating into my personal time more than I expected. Delegating doesn’t simply mean putting money in and saving time — it means committing to working on something together with someone. I forget this far too often, and I end up spreading myself across a thousand projects that I never see through to the end. It’s a pretty common trait among creative people, and I wanted to share it with you today.

I’m hoping to publish my fairy tale by Christmas — I’d like to print some copies in Catalan and give them to every child in Maria Laura’s class. Then I’ll post the link on my blog and on my LinkedIn, so it’ll be possible to buy it in Italian and Catalan.

Return of Micro

Published by Paolo Gambardella on 26/10/2026

This post was originally written in Italian by Paolo Gambardella. It has been translated by an AI agent and may contain inaccuracies.

Write your post here in Markdown.

You can use bold, italic, headers, lists, code blocks, and so on.

A Section

Lorem ipsum dolor sit amet. Reference images like this:

A descriptive caption

Or images in the images/ subfolder:

Another image

Another Section

Keep writing…

Mobile F2P: How Small Studios Rewrote the Rules

Published by Paolo Gambardella on 22/10/2026

This post was originally written in Italian by Paolo Gambardella. It has been translated by an AI agent and may contain inaccuracies.

I asked Claude to study 2.5 Gamers, the podcast by Jakob and Matej that dissects a mobile game every week. Here’s the prompt I used:
I want you to browse the most-viewed videos from the past five years, pull the transcripts, and go through the content carefully, word by word. Then write me a breakdown of mobile F2P trends over recent years, with a particular focus on games coming from lesser-known developers.

What makes this podcast compelling is that the main characters are often two-, seven-, twenty-person teams — frequently based in Turkey, Vietnam, China, or some small town in Northern Ireland — pulling in numbers that turn heads.

A note on figures: almost all the revenue numbers I mention are estimates made by Jakob and Matej using market intelligence tools. Treat them as ballpark figures.

2023: the rise of hybrid games

After Apple’s privacy changes, user acquisition costs climbed to the point where the hyper-casual model — masses of downloads at a few cents each, monetised purely through ads — stopped making sense. In early 2024, a Voodoo executive said it plainly: hyper-casual is dead as a business, and their entire prototype pipeline is now aimed at hybrid casual.

Hybrid casual means starting with an ultra-simple hyper-casual core and layering a meta on top of it: currencies, progression, events, battle passes, some in-app purchases.

  • SayGames set the template with My Perfect Hotel: over a year in soft launch, then 13 million installs in the first month.
  • Habby did the same with their action RPGs, building a template they reuse from one game to the next.

User acquisition has increasingly spilled over into design, to the point of actually driving it. Whiteout Survival by Century Games, for the first thirty minutes, is indistinguishable from an idle game. Then a “World” button appears and you realise you’ve been playing a 4X all along. They grafted a low-CPI idle game onto a deep strategy title, because idle sells cheaply in ads while the 4X monetises for years. You’re essentially building two games in one.

2024: core mechanics start to matter again

2024 is the year small studios prove that a fresh mechanic is worth more than any amount of market research.

  • Lessmore is a remote team of 17 people. The prototype for We Are Warriors was built by two people in two weeks, with zero market research: they believed in a moment-to-moment gameplay loop that nobody had done yet. Estimated result: around $200k a day from ads alone, with rewarded ads capped at two per day to stop ads from becoming the main strategy.
  • Quokka Games, based in Turkey, has about ten people. Screw Jam is a mash-up of three existing games: the nuts and bolts from Nuts & Bolts, the exit limit from Bus Jam, and the bench mechanic from tile-match games. Within four months it goes from zero to roughly $130k a day in in-app purchases.
  • Hexa Sort, published by Lion Studios, invents a new puzzle mechanic and builds the whole thing around advertising: ten-minute levels, rewarded ads that appear directly on the board when you need space, and an interstitial when you reopen the app.
  • Offline Games — a collection of solitaire, chess, minesweeper, and clones of well-known games, apparently made by a single person. Zero progression, zero currencies, virtually no ads. By July 2024 it’s hitting one and a half million downloads a day. No paid acquisition campaigns found anywhere: just solid ASO, a YouTube channel with trailers racking up tens of millions of views, and cross-promotion across its own apps. One line from the episode stuck with me: “maybe the answer to monetisation is not having one.”
  • The WeChat mini-game market has around 400,000 developers, 70% of teams have between 5 and 30 people, and a game takes two or three months to make. China is running one to two years ahead of the West.

2025: execution and speed

By 2025 the mood shifts. The ideas are out there, but the trend is to copy them fast — and in mobile, it looks like the winners are whoever executes that best.

  • Rollic becomes the master of “deterministic puzzlers” — levels that play out identically every time — and bets on many games doing one or two million a month rather than chasing a single Royal Match.
  • Block Blast by Hungry Studio, a small Chinese team obsessed with A/B testing, takes Tetris, strips out the time pressure, and turns it into a three-piece puzzle with dynamic difficulty tuned to each player. It becomes the second most downloaded game in the world.
  • Grand Games, a Turkish studio, takes water sort — a genre packed with low-effort games coasting on ads — and applies the same level of polish as Royal Match: effects, animations, the game immediately telling you when you’re stuck and offering you an extra bottle.
  • Falcon Games, in Vietnam, copies Royal Match’s events system wholesale and drops it onto a puzzle about sorting objects onto shelves, overtaking the games that had invented the genre.

To me, this is a clear sign of dwindling originality and creative ambition. The sector is increasingly being taken over by a pure-greed mindset.

2026: the sort genre and the 30-day window

By 2026, execution is optimised even further — the winning teams are the ones who move fastest.

  • Pixel Flow comes out of Loom, a Turkish team of 7–8 people who left Rollic. No investor wanted to back them — according to Akin Babayigit, because they hadn’t come from Peak, the “right” studio. They put in all their own money, ran UA themselves, and went from zero to over a million dollars a day in ninety days. Then Scopely acquired them. A one-to-one Vietnamese clone reached $140k a day within two months, before being pulled from the stores.
  • Cube Land by RotateLab, a remote Turkish team, arrives after about twenty released games with nothing to show for it. Idea in November, retention test in March, $300k a day six months later. They call it “volume of shots”: keep taking them.
  • Smash Fest takes its core from a mini-game inside a Toon Blast live event — a cannon shooting balls at physical structures — and turns it into a full game. It scales to 300k downloads a day. Within a month, seven clones drop from established studios. Pixel Flow had three months before being copied; Smash Fest had one. The advice they keep repeating is blunt: you’ve got 30 days to scale.

The creative arms race

If there’s one thread running through all four years, it’s the weight of ad creatives. Since 2023, the volume of videos a game needs to produce has kept growing. Vita Mahjong, a simplified mahjong game aimed at older players, produced 23,000 creatives in a single month. One example cited: 1,800 creatives tested to find one capable of sustaining a million in spend. The takeaway is “whoever executes at volume wins.”

AI has accelerated everything. Some Chinese studios claim to produce 70% of their videos with AI. But the same technology has reached smaller players too: Matej, who’s developing his own game solo, generated ten videos starting from nothing but the store link, in an hour and a half. His conclusion is that ten imperfect videos beat one perfect one.

And there’s a darker side to this, which needs saying. Ads featuring fake neurologists, falsified gameplay, Marvel and Nintendo characters used without permission, families freezing to death to sell a gardening game. The platforms do very little about it. It’s one of the reasons I look at this market with a mixture of admiration and unease.

What I take away from all this

Laid out in order, these three years tell me a few things I want to keep in mind.

The barriers to entry are low; the barriers to excellence are sky-high. Akin says it, and the facts back him up. Anyone can clone Pixel Flow in two weeks. Meowdoku copied an almost note-for-note sudoku that had been sitting on the market for eighteen months going nowhere, and made it explode. Block Out took the same mechanics as Color Block Jam with a completely opposite level design philosophy and surpassed the original. The idea gets you through the door; execution decides who stays.

Specialisation pays off. Loom came from years of deterministic puzzles. Malpa Games spent ten years sharpening their production on word games and sudoku before hunting for new ideas, because “ideas get copied immediately if you’re not precise and fast.” People who know a genre inside out spot where it can be pushed before anyone else does.

Fresh ideas come from outside the genre. A mini-game from a live ops event becomes a full game. A game for older players becomes a monetisation model. Township, after seventeen years, is a match-3 with a tycoon layer in front of it that exists purely to lower the cost of acquisition. “People don’t look outside their own genre,” they say in the Township episode. Those who do find room to move.

Organic reach still exists, but it’s the exception. For most small studios, distribution remains the core problem — and with AI bringing production costs down, it’s only going to become more so.

What reassures me, in all of this, is that the game still matters. Akin says the industry has swung too far towards data, and that today the ad networks’ algorithms raise the quality bar at launch: you can’t ship a half-finished game and test your way to success anymore. You need instinct. You need someone who knows what to keep and what to cut.

And for anyone working in design, that’s good news.

Five Uncomfortable Questions About the Video Game Industry

Published by Paolo Gambardella on 19/10/2026

This post was originally written in Italian by Paolo Gambardella. It has been translated by an AI agent and may contain inaccuracies.

Over the past few months, the same questions keep coming up. The tone is almost always anxious. I’ve tried to line them up and answer them in my own way.

1. Are we making more games than the market can absorb?

Production capacity is growing, AI promises to push it even further, and yet players still have the same number of hours in the day. The argument seems to hold up.

And yet this past year, with one of the most packed release calendars in recent memory, told a different story. Players have far more time — and far more appetite to spend — than we give them credit for. You don’t need to finish a game to feel good about having bought it. Just look at your own Steam library: mine is full of games I’ve started, dropped, and will get back to eventually. Buying them is already part of the enjoyment.

The market absorbs well-made games just fine. What struggles in a crowded landscape is the mediocre game — the one that in a quieter year might have scraped by, and today disappears within a week. I’ve said it before and I’ll keep saying it: games are a form of art, and the people who play them can tell the difference between something made purely to sell and something made to say something unique.

2. Is this a funding crisis, or are we funding games by rules that no longer apply?

I lean towards the second. The industry has stopped growing at the pace it once did, and the investment models built on those growth curves have aged badly. Anyone pitching a business plan with 2020-style projections will rightly get the “heard it all before” look.

There’s something else that doesn’t get said enough. For years, the assumption was that putting someone from a big AAA studio in charge of a new team was a safe bet. Managing three hundred people inside an existing structure is one job. Building a studio from scratch, on a shoestring, with no safety net, is a completely different one. The string of ventures led by ex-Riot, ex-Blizzard alumni and so on proved that. Many promised a lot and delivered little, and investors haven’t forgotten.

Investors want to see clear distribution strategies that do something a bit different, ideally backed by solid numbers. And if your business isn’t built around growth but around building intellectual property, you’re better off looking at other funding models and saving yourself the headache.

3. If AI makes execution cheaper and faster, what’s left that’s defensible?

I’ll start by questioning the premise, because I’m not convinced. I think AI will make development bigger before it makes it cheaper.

Generating more assets and more code means someone still has to review them, test them, discard them, integrate them. The bottleneck shifts to revision and QA, and that’s where complexity balloons. Once the excitement dies down, we’ll see new specialised roles emerge just to keep all of this running — and the final bill will be higher than it is today. If I could previously develop one mechanic to a certain level, and now I can develop five simultaneously, that also raises the bar for the complexity players expect from us.

So what remains defensible? What’s always been there: the taste of the person who decides what to keep and what to cut, the relationship with your players, the ability to say no. The more material there is on the table, the more valuable the person who knows how to choose.

4. If no one is hiring juniors today, who will the seniors of tomorrow be?

This is the easiest one, which is precisely why it baffles me that people keep asking it. The companies that will still be here tomorrow are the ones investing in their juniors today.

Every single company that stops hiring juniors is making a choice that looks sensible on this year’s spreadsheet. If everyone does it, in five years the senior talent pool will be empty and eye-wateringly expensive. Those who invested in people when it was hard work will have an advantage that money simply can’t buy.

If you’re a junior, don’t lose heart — focus on making things, putting your voice out there, and meeting people. If you’re a founder, think about the future of the industry you live and work in.

5. Are we designing creative risk out of games?

Good design is a balance between what the player expects and a well-placed surprise that catches them off guard in just the right way. Strip out all the risk and you’re left with a game everyone recognises and no one remembers.

It’s natural for large companies to play it safe — they have a lot to lose, shareholders to keep happy, franchises to protect. But that caution leaves an enormous amount of space for anyone who’s small, fast, and willing to try something new. Every time the big players retreat into the safe formula, a door opens for someone else.

It’s worth always keeping the core fantasy of our games front of mind. Push against it with ideas drawn from other media. And be bold enough to bring those ideas in through your own creative lens — players tend to appreciate that far more than we expect.

Miyamoto Didn’t Write Code

Published by Paolo Gambardella on 14/10/2026

This post was originally written in Italian by Paolo Gambardella. It has been translated by an AI agent and may contain inaccuracies.

From what I can gather, Miyamoto never wrote a single line of code for his games. In an old Iwata Asks, lead programmer Toshihiko Nakago describes how it worked. Miyamoto and Takashi Tezuka would sketch levels in pencil on enormous sheets of graph paper. Nakago’s team would then enter the data by hand, block by block. In the evenings they’d burn everything onto a ROM, and the two designers would play through the level. Corrections would come back as pencilled notes on the sheet. “We could barely manage one round of changes a day,” Nakago recalls.

One cycle a day. Today, with a language model open alongside the editor, I can run one every two minutes.

I’ve written before that the lone genius is a myth and I still believe it: without Nakago there would have been no Super Mario. Today, a language model handles part of what used to be that dialogue between designer and programmer. But the dialogue itself remains — and the way Miyamoto engaged with it says a lot about what our craft is becoming.

The designer as director

I like to picture Miyamoto as someone who knew what he wanted and knew how to communicate it. His job was to describe: where the block goes, how high the jump reaches, what the Goomba does when it hits a pipe. Translating that into assembly was someone else’s problem.

Something similar happens with AI. I can describe a mechanic, a character’s states, the edge cases, and get back a script for Godot or Unity that implements them. The quality of the output depends on how clearly I’ve thought things through — the more precise I am, the fewer tokens I’ll burn.

The designer decides what should happen, why, and what it should feel like. Writing the code becomes a part of the process you can hand off. I touched on this recently when writing about junior devs: the job has always been to instruct a machine until it becomes a game.

The limits of today

The NES had 2 KB of working RAM. Nakago describes hunting for free memory: with twenty bytes to spare, you could add ten more blocks to a level. Some of the most enduring solutions in gaming came out of those constraints — like the clouds and bushes in Super Mario Bros., which are the same sprite recoloured.

Miyamoto didn’t program, but he knew those limits inside out. That’s why what he asked for was always actually buildable.

AI has its own limits, and anyone using it needs to know them just as well. The model forgets whatever falls outside its context window. It gives different answers to the same question. If it’s running in real time inside a game, every call has a latency and a cost. Knowing these things lets you design around them — and sometimes turn them into mechanics: a character with a faulty memory, an unpredictable oracle, a world that shifts every time you visit it.

Ten cycles a day, then a hundred

In the same interview, Nakago mentions that with later tools they could iterate on a level ten or twenty times a day. Today the loop between idea, implementation, and playtest is compressed almost to nothing. I tweak the gravity, play it, tweak it again.

That shifts the bottleneck. Before, the constraint was how fast someone could implement a change. Now, the constraint is how fast I can tell whether the change actually works. And to figure that out, I have to play, feel, compare. The feel of a jump only reveals itself with a controller in your hands.

What AI doesn’t know

AI can write code, sketch dialogue, generate assets in seconds. But it doesn’t know when a level has gone on too long, when an enemy arrives at exactly the wrong moment, when a jump tips over from challenging into frustrating. It doesn’t experience joy, boredom, or tension. It’s good at imitating solutions others have already found; deciding which ones to keep is down to whoever’s actually playing.

That’s why I think the game designer’s value is shifting even further towards taste, pacing, and an understanding of player psychology. Those are the qualities that made Miyamoto’s work timeless — and he honed them with a pencil and a sheet of squared paper.

Three things to practise starting tomorrow

  1. Write specs that someone else can execute. Take a mechanic you know well — Mario’s jump, say — and describe it in ten lines. Then hand it to a model and see what comes out. Every gap between what you had in your head and what you see on screen is a place where your description was fuzzy.
  2. Learn your tool’s limits. Miyamoto knew the NES’s memory; learn what the model gets wrong — where it gets confused, what it forgets, when it starts making things up. That’s design-relevant information.
  3. Play more than you generate. When an iteration takes two minutes, it’s easy to crank out fifty of them without actually playing any. Set aside time to pick up the controller and make a proper judgement — and write down what you felt before you ask for the next change.

Junior employees will have things I never had

Published by Paolo Gambardella on 13/10/2026

This post was originally written in Italian by Paolo Gambardella. It has been translated by an AI agent and may contain inaccuracies.

I remember my first job in video games: a small company in the South of Italy that distributed arcade machines and VLTs. The company had kicked off a project for a Linux-based machine, shipped once to the customer; games were then loaded via an external drive and a decryption smartcard.

My role was to help design and develop those games using a proprietary engine. In practice, I spent most of my time writing Lua. I hadn’t finished university yet, and I was making a lot of mistakes. More than once I put blocking calls inside a loop and the game would freeze. I used global variables where I shouldn’t have, and a change in one place would break something on the completely opposite side of the codebase. As I said, the company was very small, and my boss often caught these things too late, by which point they’d already become a crisis. Which inevitably led to some tense, frantic moments.

It was a tough gig for someone with no experience and no consistent guidance. I know now that the problem wasn’t just me: in a team that small, nobody had time to review my code. Code review was a role that simply didn’t exist. And so, line by line, I was accumulating technical debt without even realising it.

A junior in my position today would have an AI assistant at their side — one that flags, before the code ever reaches the boss, that a particular call is going to block the loop, or that a global variable is going to come back and bite them in a fortnight. Essentially, the review I never had. When I think that juniors in the near future won’t have to run those same risks, I feel genuinely relieved.

Then again, the job of a junior developer or designer has always been the same: instructing a machine to become a game. The language, the syntax, the tricks to stop everything from crashing — those are just the means to an end. If a tool takes care of the means and limits the disasters, the junior has more room for the part that actually matters: figuring out whether the game works and whether it’s fun.

That’s why, when I read that Epic Games wants to develop its Marvel and Star Wars shooter with an “AI-first” approach — code and art generated by AI, with humans directing and overseeing — and when Tim Sweeney talks about a major shift for the whole company, I look at it all with a degree of scepticism. And yet I feel that the underlying intention — setting aside, obviously, the one about cutting costs — is a positive one and could genuinely make things better.

If I were a junior today, I’d use the time AI gives back to me for two things. The first is building connections: getting to know other developers, going to events, getting your face known. The second is developing a real understanding of what players want. Play a lot, but critically — pick a successful game and ask yourself why it works, what need it meets, at what moment it makes you want to play one more round and at what moment it makes you put it down. Someone playing an arcade cabinet wants to feel skilled within a few seconds; someone playing a management sim wants to feel in control. These are questions no AI can ask on your behalf, and that’s where a junior can genuinely make a difference.

Games Like Toys

Published by Paolo Gambardella on 07/10/2026

This post was originally written in Italian by Paolo Gambardella. It has been translated by an AI agent and may contain inaccuracies.

In the last few days I’ve written about what retains value when copying a game becomes trivial and about prototypes built by mixing existing games together. Today I’m coming back to the same territory, but from the audience’s side — prompted by two pieces of content that landed in my inbox almost simultaneously.

Taking apart and putting back together

The first is a video from the AI Search channel that explains how to use AI to decompile games and remix them with each other. Mirror’s Edge parkour inside Skyrim, Minecraft inside GTA, Spider-Man in a Batman game. The parkour port, the author says, took roughly a day. His summary:

“Think of it as like copying and pasting various elements from different games to create a completely new game.”

A lot of these mashups are rough around the edges — collisions and physics breaking all over the place. Almost none of them will ever become a product. And yet loads of people watch them, recreate them, and share them.

That’s what I find fascinating. For a certain segment of the audience, the game has become a toy. The objectives we design become optional; the fun is in opening the box, pulling out the pieces, and building something nobody planned for.

What they’re really after

The second is a long post by Seth Godin on which AI businesses are actually worth building. Godin writes that at the root of almost every purchase there are three drives: status, belonging, and freedom from fear. On top of that he places an intermediate layer made up of things like control, transformation, and belonging to a narrative.

The people making mashups live exactly in that layer. They want control over the game they love, they want to transform it, and they want to show it to people like them. Every community swapping these experiments around is a network effect that nobody had to pay for.

Then there’s the line that hit me hardest as a game designer:

“Mechanics without a story is the race to the bottom.”

Godin is talking about startups. It applies to us just as well. If a mechanic can be lifted out in a day, on its own it’s worth very little. The player is looking for the story that mechanic lets them tell.

Fallout’s dog in Human: Fall Flat

I tried looking at my own game, Pawtners Case, through this lens.

Take Dogmeat, the dog from Fallout 4 — the one you order to fetch items and bring them back. Drop him into Human: Fall Flat, the physics puzzle game from No Brakes Games where Bob wanders through his own dreams grabbing everything with floppy arms. The result looks a lot like Pawtners Case: a police dog in a dreamlike city, two buttons, objects picked up with the mouth, and physics that makes you laugh.

Today I could watch that mashup running before I’d written a single line of code. It would be a private, unpublishable prototype — and it would be enough to tell whether the feel works.

There’s also a detail I now read differently. In Pawtners Case every case can be solved three ways: noob, pro, and hacker. The hacker route is designed for players who exploit the physics and the levels to reach the end in their own way — in other words, for people who treat the game like a toy. I’d designed it as a bonus feature. Maybe it’s actually speaking to the most interesting audience of all.

So, is it a business?

For the people making mashups, almost never. For whoever gives them a legal sandbox, pieces to combine, and a stage to perform on — very likely yes. Roblox, Mario Maker, and Fortnite Creative have been proving that for years.

For game designers, the question shifts: how easy is it to take my game apart, and what will players build with the pieces?

The GDD Beyond the Template

Published by Paolo Gambardella on 06/10/2026

This post was originally written in Italian by Paolo Gambardella. It has been translated by an AI agent and may contain inaccuracies.

When people talk about game design documents — about design documentation — they usually jump straight to templates and standard formats. In my view, that’s a missed opportunity to look at the bigger picture. Format is just one aspect of one of the five parts of good design documentation.

A few months ago I wrote about the difference between a document and documentation. This post picks up from there: once we’ve established that we’re documenting something concrete, what should the document actually contain?

Five perspectives

To keep things concrete I’ll use a simple example: the boost in a racing game.

Knowledge. First of all, a design document is built around a set of things the game — or the feature in question — should teach players. I’ve talked before about the player experience narrative, which is the story of the game or feature written from the perspective of an enthusiastic player. This helps us identify the components of what we’re describing, and therefore the skill atoms — the individual pieces of knowledge we’re trying to convey. Fun always comes from a process of discovery, much like a creative one: to play is to learn.

For the boost, the skill atoms might be: understanding when the bar is full, discovering that boosting through a corner causes you to lose grip, learning to save it for the final straight. Each of these is a small discovery, and each one needs to be described.

Objectives. Second, the document contains the objectives we have from the game’s perspective. These take the form of specific behaviours we expect from players, and sometimes emotions we want to evoke. You’d typically start from the game pillars (if you have them) and use them to articulate the goal you’re working towards.

For the boost, the objective might be that the player uses it at least once per lap and feels a rush of adrenaline on the straight. A pillar is only useful if it forces you to give something up: if the pillar is “speed”, the document should also say what we’re sacrificing to maintain it — for example, no menus during a race. And if we’re expecting a specific behaviour, we should also write down how we’ll measure it. An objective you can’t observe in a playtest or in the data is just wishful thinking.

Gameplay. Next comes planning the gameplay itself — making the player’s objectives concrete, along with the content, activities, and any strategies they might use to overcome obstacles. This is where you’ll most often find flowcharts, bullet lists, and so on.

This is where format comes into play. How we present the gameplay should serve whoever’s reading it. For the boost, a diagram showing the states (empty, charging, full, active) tells a programmer more than three pages of text, while a table with speeds and durations is more useful to whoever handles balancing. Format is chosen based on the content and the reader, and it can change from section to section.

Systems. A good design document can’t afford to ignore systems. A system is a group of mechanics that, together, teach the player something — which is why I see it as a collection of learning experiences. There are also unplanned dynamics that we can sometimes identify and that end up becoming part of the metagame.

Scott Mercer talks in a short video about how he designed Gruul the Dragonkiller, a boss from World of Warcraft: The Burning Crusade. He wanted to recreate the feeling of musical chairs — when the music stops and everyone scrambles to find a seat. The first mechanic, Shatter, deals damage to players who are near each other, so players learn to spread out. Mercer immediately anticipates an unplanned dynamic: the raid might assign everyone a fixed spot, and all the fun would vanish. So he adds Ground Slam, which flings each player in a random direction and forces them to improvise. Then there’s latency: in 2007 many players were still on dial-up, and everyone saw others in slightly different positions. So he introduces a gradual slowdown, which gives clients time to sync up and, as a bonus, adds tension. Finally, the more players die, the more space there is to spread out, meaning the fight would get easier over time. A steady increase in damage keeps everyone motivated to stay alive.

Each mechanic patches a hole left by the previous one, and each one changes what the player is learning. That’s why, if the feature we’re documenting is part of a larger system — or affects other systems — we need to show we understand the bigger picture and make a genuine attempt to anticipate how it’ll behave. Back to our example: if the boost recharges by collecting items on the track, that also changes how the player chooses their line, and level design needs to know that.

Production. Finally, good design documentation helps resolve design problems and challenges, and guides programmers and artists in building all the assets needed for the feature or game to succeed. For the boost, that means listing visual effects, sounds, and camera movements, and flagging the open questions: what happens if the player activates the boost mid-jump?

Templates have their limits

When we focus too much on the final format, we risk losing sight of the bigger picture and leaving out parts that one template might cover and another might not.

Take the one-pager. It’s great for aligning a team or pitching an idea to a publisher, yet there’s no room in there for systems and their interactions. Many classic GDD templates, on the other hand, have sprawling sections on gameplay and nothing on the knowledge the player needs to acquire. When I choose a format, I already know which of the five parts I’m sacrificing, and I document it somewhere else.

That’s why I use the five parts as a checklist, before I even open a template: knowledge, objectives, gameplay, systems, production. If one is missing, the document has a gap — whatever format it’s in.

Powered by