Skip to content

Tag: professional

The GDD Beyond the Template

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.

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

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

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

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.

The Business I Chose

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

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

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!

Eagles Dressed as Pigeons

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

Sometimes we romanticise work to the point of ignoring that moment — which always comes — when we start running on autopilot. We begin measuring our value by the time we put into something, without thinking about the actual outcome or what we’re really delivering to players.

I’ve often found myself in situations where colleagues were clocking loads of extra hours just for the sake of it, or because they’d been pulled into this endless loop. Which inevitably leads to poor project estimates, treating things as feasible when they simply wouldn’t be without the overtime — overtime that, for the most part, adds no real value to the game.

I can’t change those attitudes, though I’ve tried. But I don’t fall into that trap either — I don’t do unnecessary extra hours, especially unpaid ones.

Disagree and commit

These days I’d rather focus on my own work than get into debates, because I’ve noticed people get defensive pretty quickly.

On one hand, I work on what I’ve been assigned, always trying to deliver on time and with something extra thrown in. On the other, I keep proposing improvements on whatever initial vision I’m given. They’re rarely accepted, but the exercise helps me think through the product — and it also signals what I’m capable of.

  • A client’s game is not my game
  • If a client asks me to design a half-baked feature, I first design it exactly as they’ve described
  • Then I offer what I’d consider an improvement, without pushing it. If the client says no, it’s no. Again — not my game.

Show, don’t argue

In a lot of organisations — bigger companies especially, where people go through incredibly elaborate hiring processes and are expected to show up with an impressive track record — verbal disagreements are very often read as personal attacks. Particularly in remote settings, without face-to-face contact, I’ve found that either I’m rubbish at arguing my corner, or people are just too proud to budge.

If I want a design change, I never raise it in the meeting. For me, meetings are a tool for one thing only: showing you want to work as a team, and giving people credit. What I’d rather do is present the requested version alongside a quick prototype of the improved one.

Eagles don’t crunch

I’m like an eagle — I fly high, and occasionally I dive to solve a concrete problem. A lot of clients want me to be a pigeon: fly low, peck around, make a mess here and there.

I have the experience to work efficiently. I don’t need to put in more hours than necessary. I’d rather focus on delivering high-quality work within my contracted hours. I always back other people’s ideas, however odd, but when my day is done, I switch off.

And if they’re paying me eagle rates to do pigeon work — fine by me. Less responsibility.

Professionalism Above All

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

I had a colleague a while back who seemed genuinely brilliant. They had made some specific lifestyle choices, and before they joined, a few people in the work chat had made the odd joke at those choices’ expense. Nothing malicious — just the usual banter.

When they joined the company, this person went through Slack looking at old messages to see if anyone had previously taken a dig at their lifestyle. They found the messages, and managed to work with HR to get the people who’d been laughing fired.

Years later, this person was let go themselves, and since then they’ve been constantly in the middle of some controversy or other. I’m not saying they’re wrong — in principle, they have a point. But I have to say things start to smell a bit off when either you keep getting sacked or there’s always a problem with the CEO or senior leadership.

I won’t set myself up as anyone’s moral compass here — my own tolerance for certain things is genuinely low, and I work hard to train it. For me, professionalism comes before everything else. If your colleagues make jokes that offend you, stop and think about what happens to them if they lose their jobs over it. Professionalism also means being patient when the situation calls for it.

If your company lets you go for any reason — say, because it would rather replace you with AI — the professional thing to do, in my view, is to accept it and move on to the next thing. Turning into a keyboard warrior and leaking company strategies that are covered by an NDA is not professional. I know it’s infuriating, I know it hurts, but professionalism, I’ll say it again, comes first.

If one of your employees calls something out publicly, professionalism requires that you go to your comms department and craft a proper response — not react from the gut, and certainly not without getting some advice first, ideally not from Claude.

The lack of professionalism I see in this industry is staggering. We all need more patience and more professionalism — every single one of us. Have a good weekend.

Changing Your Mindset Isn’t Enough

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

Benjamin Carssage, former Riot producer, sums up the AAA crisis in a single sentence in this video: record budgets, bigger teams than ever, longer timelines than ever — and the success rate still dropping. His diagnosis is that it all comes down to two missing ingredients: real leadership and real product thinking. Nobody inside these machines asks themselves why a player would choose this game anymore. They just ask whether the milestone was hit.

I agree, and it hits close to home. At my first job in a social games studio, my manager asked me to copy FarmVille’s progression curve wholesale onto a blackjack game we were working on. I had to explain what a mathematical function actually is before he could understand why a curve designed for a farming game couldn’t simply be transplanted onto a card game. The response: just do it anyway.

The video lands on four solid recommendations and frames them almost like a shift in posture.

  1. Hire real leaders
  2. Find the vision
  3. Don’t scale too soon
  4. Validate with players first.

All correct — but far harder to pull off than the list makes it sound, for two reasons in particular.

The first is that the incentives need to change. Things work this way because leaders are paid to behave this way. You can hire the most courageous person in the world: if the system punishes anyone who looks like they want to pump the brakes, that person either falls into line or walks. Trying to change people’s mindset without touching what gets rewarded is pure wishful thinking.

The second is that the video underestimates how much time and money the transition actually takes. You need cycles of failed projects before an organisation genuinely learns; teams also need to hire a very different kind of person from the ones their current recruitment processes look for — generalists whose whole job is hunting for new ideas.

“Find the fun” is easy to say, but it takes a certain intentionality that goes well beyond Gantt charts. It takes taste, artistic intent — things that are hard to justify when it looks like you’re just messing around. It’s easier to do in smaller, more agile setups, which look set to be the near future of this industry.