Skip to content

Paolo's Blog Posts

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.

I Prefer to Build

Published by Paolo Gambardella on 28/09/2026

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

Se lavori a lungo per la stessa azienda, c’è sempre un gruppo di persone che si lamenta molto. Del prodotto, delle scadenze, dei capi, degli altri team. La cosa che mi snerva di più è che, di solito, non si raggiunge nessun obiettivo. La lamentela occupa il posto dove potrebbe stare il lavoro.

Complaining can serve a purpose: there’s a real problem, you name it, you try to fix it. When someone vents, there are three things they might be looking for:

  1. to be heard,
  2. to be comforted,
  3. to be helped.

Listening and comforting do little to actually reduce stress, whereas offering a solution or a different way of looking at things makes a real difference. If a complaint doesn’t lead anywhere, it’s usually just noise.

The uncomfortable side of building

In games we see this all the time:

  • An unfair boss should be flagged and, if possible, fixed.
  • A hard boss kills you, makes it clear why, and lets you try again within three seconds.

Healthy frustration points you towards mastery. Complaining is like sitting on the game over screen telling everyone who walks past how terrible the boss was.

Building has an uncomfortable side too. It can become an excuse to feel superior, and some processes are genuinely broken — in those cases, calling things out is already part of the work. Between a company where things can be changed and one where nothing ever changes, you can tell them apart by how people react when someone puts forward a proposal.

Before you slag something off

My rule, in the end, is simple. If I see a problem, I propose something. If I can, I do something. If after proposing and doing I still see things aren’t working, I leave. Staying somewhere that won’t change while I complain about it is the third option, and it’s the one I want to avoid. It’s happened, but with age and kids it gets harder and harder to go down that road.

Before you slag something off — who could actually change it? If the answer isn’t the person in front of you, that conversation is probably best left alone.

From Spending Depth to Attention Depth

Published by Paolo Gambardella on 25/09/2026

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

The entertainment industry uses time spent as the primary measure of a product’s or service’s value.

Value = Time × (Revenue / Unit of time)

I’ve been using LLMs and machine learning for a few months now, and in my view this wave of innovation will bring three things: more supply, less pricing power, and above all an audience that compresses everything it can into less time. If that’s true, the formula above starts to crack. Time becomes the scarcest resource, and anyone trying to grow purely by stretching sessions ends up competing with everything else for the same minutes. At that point, what matters is how much each minute a player chooses to give you is actually worth.

Judged by D1 and D7

I’ve worked in mobile games for years, and my job as a designer has always been measured against Retention and Monetisation. The first obviously leads to the second: D1, D7, DAU/MAU. It makes sense — an F2P game survives on the volume of people who show up every day and, crucially, come back. The more someone returns, the more likely they are to start spending serious money. So every feature I designed had to move one of those numbers, or it got cut.

The problem is that some features do their job quietly. A system that makes it clearer what to do next, a small narrative moment that gives a session some meaning, an interface that removes friction — none of these things will shift D7 on their own in an A/B test. So they end up at the bottom of the pile, behind yet another limited-time event that does move a number, immediately. I’ve watched entire roadmaps bend towards whatever was easy to attribute, and the games that came out of that process all had the same face.

The most painful example happened to me last year. I was working with a large client and one of the best teams I’ve ever come across — creative, capable people who genuinely believed in the project. The numbers coming in were interesting, at least from where I was standing. On top of that, we essentially invented a new genre from scratch. No metric was saying the game was doing badly; it was doing well, just not as well as the parent company expected — they were chasing D1 and D7 targets that were frankly unrealistic. The pressure became so intense that, from what I heard later, the project was shelved. A real shame. The way I see it, metrics are there to tell you where not to go — and when they become the only yardstick for judging an idea, they end up killing the good ones too. That company probably had a great product on its hands, and all it would have taken was letting the people get on with it.

A medium you can’t summarise

Video games broadly — not just F2P — are in an interesting position. Think about a film or a podcast: in theory you can swap three hours of film for a two-minute recap. With a roguelike, though, it’s hard to summarise a run… the value is in actually playing it. As a business, that puts us in a privileged spot, and I think it gives us a real edge over other media.

Right now the market is in a consolidation phase, so it keeps repeating formulas it considers proven. That happens in every mature market. And on top of that, as I was saying, new technology in theory lets every person on a team produce more.

Who comes back

I think players have always looked for games that feel unique, and when everything starts to look the same, that search gets more urgent. I wouldn’t be surprised if we started measuring retention differently — looking not just at how many people come back, but which people come back. WHO returns: that’s the real question.

And to understand who comes back, you have to look at what they do when they get there. The player who spends twenty minutes fine-tuning their build, the one who reads every line of dialogue, the one who skips an easy reward because something else interests them more — each of them is telling you something about what matters to them. Optimising, collecting, discovering, making sense of what they’re doing. Build the game around those values and that player stays for years. Treat them as a data point in your D1 average and you lose them without even noticing.

Some will say the industry already looks at “who”: whales, high spenders. For years we’ve optimised for spending depth — how far into their wallet someone was willing to reach. Attention depth is a different thing: how far into the game someone is willing to go, understand it, talk about it, stick with it. The two often overlap, but when they don’t, it’s the second one that lasts longer.

Very often the passionate player — the one who spends, who brings friends along, who stays with you for years — doesn’t stand out clearly on a dashboard showing D1 retention trends. And yet that player weighs heavily on the game’s profitability.

The bet on depth

This is where I think the next shift will come, and soon. A studio that builds its strategy around attention depth might have lower DAU numbers and still win on margins. At the micro level the metric can look a bit ugly, but at the macro level the picture flips.

In practice, that means looking at different numbers: 90- or 365-day retention for your most engaged cohort rather than the D1 average, how many players reach the deeper systems, how many bring a friend, how many create something around the game. These are slower, noisier metrics — and that’s partly why nobody puts them at the top of the dashboard today.

Two Days, Two AIs, and a Princess Turned into a MelonLa Principessa Melone presentata al regno, illustrazione generata con intelligenza artificiale

Two Days, Two AIs, and a Princess Turned into a Melon

Published by Paolo Gambardella on 21/09/2026

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

Last week a colleague showed me an interesting video: a game dev getting ChatGPT’s Astra and Claude’s Fable 5.1 to work together inside Unreal Engine, to build a Souls-like boss fight.

The video itself is about game development, but what struck me was seeing two different AIs working on the same material rather than just one. It reminded me of a story I’d had in my head for a while — “Princess Melon”: I’ve been telling it to my daughter Maria Laura at bedtime since she was born, and over the past month I’ve actually sat down and written it up properly in my spare time. So I thought: why not try the same thing myself, with Claude and ChatGPT, but to finally put a face to its characters?

I spent two days getting the two services to talk to each other: one would propose a character, the other would refine or build on it, until we landed on a consistent cast across all the illustrations — from King Ant to the Little Mist, who feeds on the gossip of people who judge without looking. The process helped me understand who these characters really are, and gave me a much clearer picture of the story itself. When I showed Maria Laura the princess and the friends I tell her about every night, her jaw dropped: for the first time she could see them, not just hear about them.

This morning at the gym I was already thinking about the next step: getting in touch with a professional illustrator to give the book a proper, original look — and maybe, who knows, self-publishing my first fairy tale.

There’s a small irony in all of this. “Princess Melon” is about a Little Mist who thrives on “apparently…” and people who laugh before they’ve even bothered to look for themselves. When I read the comments from the usual modern-day luddites, quick to pass judgement on AI instead of actually trying it, I feel like I’ve somehow wandered into my own fairy tale.

Princess Melon presented to the kingdom

The Business I Chose

Published by Paolo Gambardella on 16/09/2026

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

Yesterday I watched this interview with the CEO of Bulkhead, the studio behind Wardogs, an online multiplayer first-person shooter.

I knew the reaction would come instantly, and that this person’s words were perfect fodder for easy clicks and LinkedIn hot takes against crunch.

Today, a writer friend sends me this piece by another writer.

The business I chose

Nobody forced me into game development. My real passion is thinking about what kind of experience to bring to the medium. The part I enjoy most is discovering new cultures and finding brilliant people to talk and argue with about creative things. My dream is to put my name on a few games that actually leave a mark.

I don’t make games to get rich, and I don’t make them alone — though I had to try it on my own to figure that out. I make games because that’s the choice I made, pure love for it, if you like. Since I spend most of my waking hours at work, it matters to me to try and build something genuinely grand, rather than just tend a small, tidy little patch.

And when I work for others, I always look for projects that excite me. I don’t work just to pay the bills — I try to work on things I actually care about. And that sometimes comes at a cost: a mind that never quite switches off, extra hours, time taken away from my family.

The same was true for the family I grew up in. My mother, a paediatrician, worked far more hours than she was ever required to. My father, a lawyer, would pull all-nighters to draft briefs. My brother is a judge and he too has to do gruelling shifts with no extra pay. My family taught me that crunch doesn’t really exist as a concept — there are just things that need doing, and those things take time.

Recently I chose to move from mobile free-to-play to PC and console games, and that comes with a serious amount of extra hours. This is what I chose, and I know the consequences. We talk about our rights an awful lot, and about our responsibilities hardly at all.

The Pleasure of Walking

Published by Paolo Gambardella on 15/09/2026

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

Lately it feels like mistakes aren’t just piling up — they’re compounding exponentially. New technologies let us get from point A to point B sometimes almost instantly. But that very thing makes us miss out on opportunities that could turn out to be essential.

Imagine that this weekend you decide to visit a museum in your city. Imagine you have a helicopter at your disposal that picks you up from home and takes you straight there. A helicopter ride is fun (I assume — I’ve never been on one), so let’s say the price you pay is falling asleep for the journey. The upside is that you arrive at your destination immediately. But you lose everything else along the way: if you’d walked, you might have bumped into an old friend en route. Or, who knows, stumbled across a café doing a great breakfast. Or spotted a sign announcing the opening of another cultural centre and decided to head there instead. Sure, walking is more tiring, and slower — but it’s full of possibilities.

Right, well — in game design today you can generate a feature spec almost instantly. Your boss tells you to work on a feature, gives you a week, and within two hours you’ve already got a solid base to work from. All thanks to algorithms built essentially on probability, running on enormously powerful hardware, capable of producing structured, reasonably coherent documentation in next to no time. Far less time than you or I would need, that’s for sure.

The problem is what gets lost along the way: the chance to discover other things, to pick up new ideas and angles. But your boss gave you a week and you’re delivering in two days, so your OKR is probably going to look great — even if what you’re not doing is actually discovering anything new.

So where does that leave us? My own preference is pretty clear. For me, a true professional needs to take the time to do things properly — creativity needs constraints, yes, but it also needs time.

How to Stand Out Online

Published by Paolo Gambardella on 14/09/2026

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

There’s a worrying trend that has quite literally exploded over the past few months, at least in my social feeds: posting drafts and half-finished work.

I see established professionals posting rough gameplay examples, presumably to catch the eye of a potential client or employer. I see junior people posting screenshots from 3D authoring tools or game engines, probably to demonstrate their skills.

Noise. Nothing but noise.

I understand the anxiety around wanting to carve out a place in the industry, and I’m all for the drive to get things done — but the problem is what we’re actually showing.

  • If your goal is to develop your indie game, think about serving an audience rather than collecting reactions on LinkedIn
  • If you’re looking for a job, nobody’s going to hire you just because you can open a piece of software.

The reality of the industry

I was reading yesterday this very interesting post by an industry leader — one of the most clear-eyed takes I’ve seen in months. The reality is that we’re in a moment of consolidation (not a crash, as some people like to say), where the investor narrative can’t promise growth anymore. There’s an enormous amount of talent out there looking for work right now, which makes it genuinely hard to stand out.

This naturally leads people to think that standing out and differentiating yourself is what matters. And in a way, that’s true — but I don’t think speed is the key factor here. Posting half-finished work does get your voice out there sooner, yes. But it also shows your scrappy, unpolished side.

So how do you actually stand out?

I don’t have a magic formula, but I’ve been in the industry for years and built my own position from scratch, so I do know a thing or two. The most important thing is the relationships you build with other people — anything you can do to build them better is worth doing.

If you’re an indie developer looking to get visibility for your project, you need to do everything you can to connect with your early adopters as soon as possible. Find out where they are, talk to them, genuinely try to understand how they play, what they buy and why. If you’re putting together a video to grab attention, do it with the right level of polish.

If you’re a professional without much experience, rather than showing things that frankly anyone can do (look, here’s my axe on ArtStation!), put in the work to figure out what makes you unique, and show that in the best way you can. Nobody cares about the how — they care about the end result and why you believe it’s strong.

If you’re an experienced professional, there’s no point showing off that you built a new prototype in a few minutes. Instead, focus on helping people understand why working with you is a good idea. Nurture the relationships you already have, teach what you genuinely know — videos work well for this. Help people see that you’ve learned to think deeply about certain things.

Less slop, less spam, and more real connections and genuine knowledge-sharing!

Powered by