Skip to content

Month: October 2026

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.

The Prototype Without a Team

Published by Paolo Gambardella on 05/10/2026

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

This past weekend I was completely captivated by the stream of news about video game code decompilations. This came after a week of surprises, in which I discovered I can basically have an idea and see it come to life immediately. On my own, without asking anyone for their time.

Make your own mix

At work I built something that would have been unthinkable three months ago, but for obvious reasons I can’t go into it. In my personal life, I’m studying Catalan and I made a video game for my class, starting from an expression we use a lot: tros de quòniam, which roughly means “a person who’s not the sharpest tool in the shed”. In class we’d done a verb trivia game, so I asked my teacher if I could photograph it. Then, using all the free material available online, ChatGPT helped me structure my own version.

My idea was to keep the dice roll and add objectives to complete — like in mobile puzzle games — which drive much stronger engagement. There are four colours, one for each verb family. Each correct answer is worth ten points multiplied by the dice roll, and filling the bar lets you capture the “trosset” of that colour. Mistakes don’t set you back and there’s no timer, because the goal is to learn.

The start screen of Tros de Tríviam

When I think about it, there isn’t a single new element in this game. The class trivia game, the exercises from official sources, the dice, the progress bars from mobile puzzlers — all of it already existed. The creative work was deciding how to fit the pieces together. You can try it here, if you’re studying Catalan.

A game in progress: the four trossets to capture and the dice roll

What I’m seeing now is that people are using Claude to decompile games and mash them together. In the video below, for instance, someone merged EA’s Skate and Modern Warfare 2: the player can switch to third person, hop on a skateboard, and shoot enemies while doing it.

This is absolutely fascinating, and it breathes new life into the many mechanics that repeat from one game to the next.

I can picture a future where belonging to an ecosystem lets players try out whichever combinations appeal to them. You finish Spider-Man and Wolverine, then use each character in the other’s game. New life for what you’ve already bought. Really exciting stuff.

As a game designer, though, the first thing that springs to mind are the problems. Spider-Man is an acrobatic improviser — he hits and bounces between enemies, and his combat is designed with lots of space and spread-out foes. Wolverine’s combat is far more brutal and visceral, all close-quarters. Put Wolverine in Spider-Man’s New York and you immediately wonder how he moves between skyscrapers without webs. Put Spider-Man into Wolverine’s close-range brawls and his acrobatic rhythm has nowhere to breathe. Every game builds its enemies, levels, and camera around its protagonist’s core verbs. The most interesting mix is the one that forces you to rediscover a game you thought you already knew.

Thoughts on creativity

Some people might raise an eyebrow — fairly enough — at this avalanche of novelty arriving within the space of a few weeks. There are genuine ethical issues tied to all of this. For me, though, creativity somehow exists outside the reach of overly conscious logic and deliberation.

In one respect this situation resembles the question of chasing trends, which I struggled with a great deal working in mobile free-to-play. Chasing trends is a fundamentally anti-creative act. Being aware of trends certainly enriches your knowledge, but creativity is a process of discovery rather than an exact science. Those who chase trends always stay on the too-familiar side of things. A good mix starts from something the player already knows and adds just one surprise: familiar enough to get them in the door, fresh enough to keep them there.

In the same way, having these new tools available unlocks an enormous number of opportunities. Here’s a concrete example: before, to run some experiments and show the team I had a worthwhile idea, I’d have to ask the producers to assign me at least one artist and one programmer. Today I don’t need any of that. I’m not spending anyone else’s time, and that gives me a much wider space to explore. I can make five rough prototypes in an afternoon, throw four of them away, and discover things I didn’t even know I needed to ask.

Impossible to ignore

I use tools that are built on the large-scale appropriation of intellectual property, and that’s simply true. But the benefit from a purely creative standpoint is enormous. There are people more talented than me who could do without them — I can’t, and right now I’m not blocked.

My personal limit is to use them only for prototypes. I’ve written a story, La Principessa Melone, which I hope to publish in Italian in December. I illustrated it first with ChatGPT, and it was precisely those images that helped me understand what I was looking for — which then sent me looking for real artists to actually draw it. The prototype helped me figure out what I wanted, while the book itself will be drawn by human hands.

I don’t know how long this will last: there are various ethical and geopolitical questions that could shut down certain services within hours. So I wouldn’t recommend anyone build their strategy around any of this.

But it’s impossible to deny that we’re looking at a dazzling and in some ways incomprehensible situation, because everything is moving incredibly fast. My practical advice: prototype a lot and quickly, and keep anything that really matters out of a service that could be gone tomorrow.

If copying a game becomes trivial, what remains of value?

Published by Paolo Gambardella on 01/10/2026

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

If copying game mechanics and entire systems becomes trivially easy, what’s left that actually holds value? I think the answer lies in live operations.

I’m coming at this from a very concrete experience. Six months ago I had to write prompts to get LLM services to do what I needed. Then I moved on to drafting markdown files with detailed instructions. Today I can just record a video, talk through what I want while moving things around on screen, and that’s enough. Each step has lowered the bar for turning an idea into something that actually works — and I don’t see why it would stop there.

Which inevitably leads me to think we’re approaching a point where a progression system, a game loop, or a well-crafted mechanic can be replicated in a matter of days. Code and design ideas stop being a lasting advantage. What you can’t copy with a video, though, is the work that happens after launch: the seasonal events, the updates, the way you listen to your community, the relationship with the creators who tell your game’s story. Live operations are made of people and time, and time can’t be duplicated.

Something similar happened with music. Musicians went from playing live only, to playing on the radio, then to recording albums, and finally to digital platforms where they make practically nothing. How do you survive? By playing live. For them it was a return to the beginning — almost an unavoidable choice.

In our case, though, it’s an evolution, because nobody is forcing us to go back. The long-term winners are always the ones who manage to carve out a niche, to build their own audience. And this will only become more pronounced. Since dropping in new mechanics on the fly is becoming trivially easy, the real difference will show in the narrative that tomorrow’s studios know how to build with their audience as they go. I’m thinking of studios that document development as it happens, that show their decisions and their mistakes, that make players feel like part of a story still being written. Improvising a narrative means exactly that: building it together with people, day by day, rather than packaging it once before launch.

The game itself can be copied by anyone, sooner or later. First it was only companies of similar or greater size who could do it — now it’s genuinely anyone. The audience that follows you from the very beginning, on the other hand, can’t be duplicated.

Powered by