Skip to content

Tag: professional

The Future is Network and Lore

Published by Paolo Gambardella on 15/07/2026

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

The post today starts from this article by Seth Godin on disposable software.

Godin’s point is that software, even though it’s invisible, portable, and weightless, used to last. Building something complex took years and thousands of people to maintain it. Even a complex website could be considered a durable technical asset.

Now, with new technologies sitting on anyone’s desk, writing new software is often easier than maintaining the old stuff. We’re in the middle of an explosion of temporary software that will make everything that came before it look small.

Even Apple and Google are significantly increasing app approval times on their stores, because of “vibe coding.”

What endures

There’s one thing, Godin says, that holds up through all of this: the network. When an organisation sits at the centre of a network, it doesn’t matter if a competitor builds something shinier and newer. The network stays right where it is. A living network is worth more today than ever, which is why people keep choosing to stay “here” rather than “go somewhere else.”

The connection to discs

I wrote about Sony stopping physical disc production. Put together, these two pieces make me think about an uncomfortable question: can the future of games be built on disposable games?

With the right tools, a small team today can prototype and test in weeks a game that ten years ago would have taken a full year. I find concepts like this fascinating. If game software becomes throwaway, the relationship with the player risks becoming throwaway too: play, consume, discard, move on to the next thing.

But exactly as Godin says, what endures isn’t the individual product — it’s the network. A publisher that has built a living community, a lore players have grown attached to, maybe an ecosystem of creators and guilds, doesn’t lose ground just because a competitor has shipped a better-looking game. The real competitive advantage, in the games industry as anywhere else, is shifting more and more from the product to the network around it.

Perhaps the right question for anyone designing games today is no longer “how long will this game last?” but “how long will the network of people around it last?”

The Secret Is Making Them Feel Smart

Published by Paolo Gambardella on 09/07/2026

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

Many game designers start from a flawed assumption: they think the player needs to be skilled, attentive, strategic in order to enjoy the game. They build systems that only reward people who read tooltips, calculate probabilities, and optimise resources.

The reality is that most people don’t do any of that. And the real craft of design is making the player feel like they made a smart choice — even when the system quietly steered them there all along.

Building the feeling

A good combat encounter doesn’t ask the player to figure out the winning move from scratch. It puts options in front of them, makes one of them slightly more readable, and lets them get there “on their own”.

The same logic applies to puzzles: the solution feels like a personal insight, but the game has already silently ruled out ten red herrings before the player ever considered them.

Attribution matters more than difficulty

When a player wins and feels like the credit is theirs, they come back. The right question during design is: what can I remove, simplify, or surface, so that their conclusion lands easily and still feels like their own?

A designer’s skill is measured by how much invisible work they can do to make the player feel a certain way.

The Game Designer’s Creed

Published by Paolo Gambardella on 08/07/2026

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

Seth Godin published yesterday The Builder’s Creed, a rewrite of Christian Larson’s old Optimist’s Creed (1911), filtered through Reid Hoffman’s recent thinking on what it means to build something in an era that constantly asks itself whether it’s still worth doing. I read it twice, and the second time I thought: we game designers should have one of our own. We’re builders too — it’s just that what we build doesn’t exist until it takes shape in someone else’s head.

It brought to mind the opening of Jesse Schell’s The Art of Game Design, where he points out that game design isn’t one craft but many (engineer, storyteller, psychologist, mathematician), all held together by a single skill: listening. Listening to the game taking shape under your hands, listening to players, listening to your gut when something feels off before you can even put it into a slide.

Towards myself

  1. I’ll remember that the game isn’t the pieces, the code, or the document: it’s the experience the player builds in their own head, and I design for that, not for the slide.
  2. I’ll trust the build more than the document: less talk, more substance!
  3. I’ll listen to my gut when something feels wrong, even before I can prove it with data.
  4. I’ll stay a beginner in at least one discipline outside games, because the best ideas in this industry almost always come from people who didn’t start here.

Towards the work

  1. I’ll ship the build, not just the document about the build.
  2. I’ll protect the vision the project was born from, before a spreadsheet starts editing it.
  3. I’ll treat content as a means to reach an experience, never as the goal itself.
  4. I’ll hold inspiration and pragmatism together: the vision that gives a game its soul, and the market that keeps the lights on.

Towards players

  1. Players are people, not funnels. I design for what they’ll remember, not just for what they’ll spend.
  2. I won’t confuse a compulsive loop with a fun one. I know the difference exists even when the metrics don’t show it.
  3. I’ll make the work behind the game visible whenever I can: it’s the only real antidote to people taking everything for granted.

Towards the industry

  1. I’ll hire for curiosity, not years of experience. This industry runs on outsiders.
  2. I’ll say my trade-offs out loud, instead of letting a KPI take the blame for them down the line.
  3. I’ll keep believing that a better industry is buildable. Buildable, one honest game at a time.

I wrote this quickly, almost on a whim. Like the Sagrada Família, it’ll need revisiting scaffold by scaffold.

The Focus is Saying No

Published by Paolo Gambardella on 29/06/2026

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

The most common problem I see with my clients is that they often know too much. They listen to podcasts and take online courses, study competitors, gather feedback, analyse trends… and then they freeze.

Steve Jobs, in a famous 1997 interview, said that focus doesn’t mean saying yes to the most important things. It means saying no to hundreds of good ideas. Too much information can push you towards choices that are right, but not yours.

How I analyse the competition

When I analyse competitors for a client, I work in two columns:

  1. What interests me about this competitor? What are they doing that points in an interesting direction: vision, audience, priorities — in that order.
  2. What doesn’t interest me, and why? What are they doing that works, that the market accepts, that isn’t a mistake — but that simply isn’t right for me. Not for the audience I’m serving, not for the identity of the product I’m building.

It’s important to tell the difference between things that are too vague and things you can actually act on:

  • “We want to make something accessible” is vague.
  • “We will never build a system that requires an external guide to understand” is concrete, operational, and defensible.

The one thing to cut

In game design I often use a simple mental tool: find the one thing to cut. Almost always, it’s a good idea that someone has grown attached to. It’s not wrong in itself — it’s just wrong for this product, or at this moment.

The same logic applies to a strategy, a piece of communication, a roadmap.

Saying no to a good idea is the hardest part of the job. It requires knowing precisely what you’re trying to be, not just what you’d like to do.

And that clarity comes from deciding what to leave out.

Action, Response, Reaction, Consequence, Implications

Published by Paolo Gambardella on 09/06/2026

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

When we’re designing a new game, we very often look for verbs that describe what players can do. One way to stress-test those actions is to use a framework that forces us to think through every possible consequence.

  • Action: describe an action in three words or fewer
  • Response: the immediate feedback the system gives the player to confirm their action has been registered
  • Reaction: other entities in the system need to react to the action in order to give it meaning
  • Consequence: the game’s economy must be affected by the action, even if only slightly
  • Implication: wherever possible, the game’s narrative should also be something the action can influence

Players are the ones who make the story — we simply give them the tools to do it. That’s the best way to think about narrative, in my opinion.

Let’s look at a concrete example:

  • Action: throw a rock
  • Response: sounds, particles, objects hit and broken
  • Reaction: one NPC runs away in fear, another starts attacking us…
  • Consequence: there’s now a rock on the ground, plus scattered debris that could be picked up and used by the player or by NPCs
  • Implication: if you break something that belongs to someone, your reputation might take a hit until you’ve paid for the damage

Not every action needs to be put through this lens, but I do think games today should be thinking about these things — it’s what allows a system to respond meaningfully to whatever a player decides to do.

A useful cut rule: when you can’t afford to implement all five layers for an action, ask which layer is load-bearing for that specific action. Response and Reaction are almost always required — without them the action feels dead. Consequence is required if the action involves a resource. Implication is a bonus unless narrative is your core loop. Stripping a layer intentionally is fine; stripping it because you forgot to design it is where games start feeling hollow.

Digital Eye Strain: The Hidden Cost of Hyper-Focus

Published by Paolo Gambardella on 08/06/2026

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

These days I’ve been getting to grips with the agents from Anthropic and OpenAI, and I can genuinely see improvements in the speed and quality of my work. Where I used to need developers to build prototypes, it’s now much more straightforward to tackle that kind of challenge with Claude or Codex guiding me along.

That said, I’ve recently been noticing a strange heaviness in my eyes by the end of the working day. This weekend was rough, especially Saturday. It felt as though something was stopping my eyes from even moving properly, on top of a general dryness and fatigue.

I found out — credit to Gemini, actually — that this is a pretty common problem. Using AI tends to pull us into states of hyper-focus.

Having to think forces us to take breaks

The first thing worth noticing is that before, I had to take lots of breaks to think things through, look up tutorials, or browse various forums. Everything was slower, obviously, but that also meant natural breaks for my eyes and spending longer on the same block of text.

Now, though, working with an agent means receiving large chunks of text in quick succession. You have to skim through them fast to separate the useful parts from the hallucinated ones, and more often than not you fire off another question straight away — which brings you back to reading another big wall of text.

AI interfaces with dark mode, VS Code with light mode

I’ve moved to using VS Code to manage my agents, since I find it better for keeping an eye on token usage and for other perks like keyboard shortcuts and so on.

The thing is, AI interfaces generally use a dark background, whereas in VS Code I prefer a light one. So I’m constantly switching between the two, which puts extra strain on my eyes.

It seems that parsing text-heavy content like code also makes us blink around 60% less than normal. Medicine calls it Digital Eye Strain, and it’s an increasingly widespread issue.

I hope this post helps others identify the problem. The fix comes down to:

  1. Sync your fonts and sizes so everything is large enough to read comfortably
  2. Reduce contrast where possible, and avoid constantly ping-ponging between different windows
  3. When the AI gives you a long explanation, close your eyes and listen to it instead
  4. Use CLAUDE.md or instructions.md files rather than chatting back and forth with the agent, to cut down on the number of iterations

Testimonials for Freelancers

Published by Paolo Gambardella on 01/06/2026

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

In recent years I’ve watched talented, experienced colleagues — people with years under their belt — lose their jobs overnight. The game they were working on didn’t sell well enough, the studio shifted strategy, or the publisher pulled the funding. The games industry is hit-based.

In this context, the “classic” path — find a studio, work there, build a career — is less secure than it looks. It carries real risks that people often don’t factor in, because we’re conditioned to see a permanent contract as the gold standard of job security, especially here in Europe.

When you work for a company, you have a single client: that company.

If things go wrong for them, they go wrong for you too. When you work as a freelancer, you have multiple clients. Losing one is a problem, but it’s not the end. The risk is spread.

But freelancing isn’t something that just happens by itself. You have to build it deliberately, over time. You need a system: a way to find new clients, keep existing ones, and make yourself visible to people who don’t know you yet.

The crux of it is this: the right clients need to know you exist. Since you’re almost always under NDA, you can’t show the games you’ve been working on, you can’t mention the titles, sometimes you can’t even say who you’ve worked for. The portfolio — the main tool most creative professionals use to present themselves — becomes all but useless for us.

The simplest solution is the client testimonial.

When a project wraps up, before the collaboration closes for good, ask your client to write a few lines about you. Three sentences is enough: what you did, how it went, what they took away from it. What you get is the voice of someone who’s worked with you and can say, publicly, that you’re worth hiring.

It works because it lowers the perceived risk for a new client. Someone who doesn’t know you has no way to evaluate you directly. But if they can see that someone else has already done that evaluation for them — and had a positive experience — the leap of faith becomes much smaller.

The Difference Between Document and Documentation

Published by Paolo Gambardella on 21/05/2026

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

One of a game designer’s core responsibilities is writing design documentation. Anyone can write a document, but a designer commits to documentation — and that’s a different thing entirely.

A document holds thoughts, ideas, whatever comes to mind. Documentation, on the other hand, is a specific type of document about something concrete. Research on a competitor game. The results of a playtest. A feature we built and watched in action. A prototype that answered a precise question.

To understand why this distinction gets ignored so often, it helps to think about how knowledge accumulates during game development.

Concept DOCUMENTS

At the start of a project, almost everything is uncertain.

  • Constraints | There are things we already know: the target platform, the genre, maybe the budget.
  • Frontiers | There are questions we know we need to answer: how the core loop works, how long a typical session lasts.
  • Risks | There are the things we don’t yet know we don’t know. Design problems that only surface when a player has a controller in their hands. Interactions between systems that seemed obvious on paper and turn out to be a disaster in practice. Assumptions nobody ever questioned because they seemed too obvious to bother with.

A concept document lives almost entirely in that third layer. It isn’t documentation — it’s a snapshot of the team’s imagination at a specific moment in time.

Game Design DOCUMENTATION

Real documentation comes later. After we’ve prototyped and discovered that the mechanic we thought was brilliant doesn’t work the way we expected. After we’ve looked at how another game solved the same problem. After we’ve tested and observed. At that point, we actually have something worth documenting.

Documents and Documentation

A document serves a temporary purpose. Meeting notes are a document. A concept doc is a document. A list of ideas scribbled down before a brainstorming session is a document. These are valid, necessary working tools, and they have a natural lifespan: they’re useful now, then they become history.

Documentation, on the other hand, is built to last.

  • It must be clear to someone who wasn’t in that meeting.
  • It must be practical — a reference you can actually use, not just read.
  • It must inspire whoever reads it six months later, when the initial enthusiasm has cooled and people need something concrete to hold on to.
  • And it must be inviting: not as an aesthetic exercise, but because if nobody opens a document, that document might as well not exist. I follow this formula: 60% of the space should be taken up by visual elements (diagrams, images, video…). 30% by data and tables. 10% text. Documentation isn’t a treatise or a novel to be read cover to cover!

Not every document is documentation, and a project will call for various kinds of document. But your team needs documentation.

What real documentation looks like

Good design documentation answers a handful of questions unambiguously: what is this game? Why is it interesting? What’s the fantasy — the emotional promise it makes to the player? What are the core features — not all the features, just the ones that define the product’s identity? How exactly does this system work? And enough production context to make the document actionable.

There’s a principle I find particularly useful here: if a team can’t explain their game in a clear, compressed way, the design probably isn’t clear enough yet. The clarity of the documentation reflects the clarity of the thinking. A dense document, packed with sections and subsections trying to cover every eventuality, is often a signal that we don’t yet know enough to be documenting.

And that brings us back to rule number one. If you don’t yet have something concrete to document, maybe it’s not the right moment to write documentation. It’s the moment to do research. To build a prototype. To test. To answer the questions you don’t know you have yet. To learn and discover.

Does this document something that exists, or something we want to build?

Leveling up in Claude

Published by Paolo on 28/04/2026

Yesterday I was speaking with a design director about how I use Claude AI, and he made me discover a new method of using it, I was totally ignoring. In fact, all this AI hype makes me resistant to novelties, and I have to admit that I often lose opportunities because of that.

I think that it’s a very powerful tool, and my feelings are that I will save up lots of time from repetitive tasks such as creating subtasks in JIRA, setting up pages, summarize information that is already there, and so on. It’s definitely a level up in my career.

There is a reading crisis

Published by Paolo on 23/04/2026

Lately I had the opportunity to review a couple of junior profiles, tests and interviews. The main issue I see is that many of them are becoming good at posing but they are also losing reading skills. I am worried, reading is so important to our profession.

During my day I review documents, chat with teammates, receive emails… all those activities involve reading. If I send to a potential candidate concrete instructions in plain English, I can admit interpretation of course. But, if I notice that you simply are ignoring instructions, I deduce that you didn’t read them.

I believe that one of my advantages as a professional are the 5 languages I speak fluently. That open to me lots of doors, because I can show reliability. I can prove with my messages that I am reading you. This is very basic and critical, you shouldn’t (as a designer) improve your technical skills with engines and tools; writing skills are also not more important than listening and reading. If you fail at that, I cannot approve your test.

If you are reading this, congrats, you are a reader. So maybe you are not part of the problem, but you can become part of the solution.

Powered by