Skip to content

Tag: professional

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.

Three loops of Expedition 33

Published by Paolo on 22/04/2026

These days I am playing Clair Obscur: Expedition 33 pretty intensively (when other 40y-old-man-duties permit) these days. And I am also completing my bootcamp on videogames design and conceptualization. A class I gave was based on the 3 main loops of a game, and today I want to apply this knowledge to the 2025 GOTY.

Moment-to-moment (second-to-second)

This first loop is the central one, and it describes what the player does the most. You can say it describes the core dynamic, somehow. In case of Expedition33:

  • Action: Reactive turn-base combat
  • Challenge: groups of nevrons (enemies)
  • Reward: skill points, loot

WHY to repeat this loot: the game is divided in zones within an open world, the Player wants to complete the zone to unlock the next.

Core loop

The core loop is what the Player does the most during the game and gives meaning to the moment-to-moment loop. We can say that it considers the game session as a whole.

  • Action: Improve team stats
  • Challenge: complete zone sections
  • Reward: Advance with the story

WHY to repeat this loot: as any good JRPG it’s about the map! You want to play to unlock new venues and discover new places into the map.

Metagame loop

This loop describes what keeps the Players engaged, what makes them think “I need to return back into the game because I want to…”. Describes the features and mechanics that make me think into the game when I am not playing it. In the case of Expedition33:

  • Action: defeat bosses
  • Challenge: what will happen in the story?
  • Reward: plot twists and secrets discoveries

WHY to repeat this loot: the game is one great adventure story!

Design docs are about builds

Published by Paolo on 21/04/2026

A good way of thinking in GDD is to write down more details of what’s already in a build of some sort. With this I mean that if you design pages and pages of documentation regarding something not concrete, you are at risk of delivering something disconnected from reality.

Frame the problem, develop prototypes, align, and only after write down specs. That’s the way. You need less talk and more rock.

Give the best of your “more or less”

Published by Paolo on 14/04/2026

Many years ago, I lost my job ad a dream company and I decided to become the best game designer I could possibly be. Part of this is still within me, also if many things changed. One for all, I understood that teams/clients do not need, nor want, the best in class.

If you are reliable, honest, candid, and humble, generally speaking you will be better welcomed into games teams. I notice, especially among junior game designers, the will to be better than others or more knowledgeable. You can easily end up being perceived as superb, like that.

The best way to do your job is to give the best of your “more or less”, without delivering too much. You will lose less energies and your job will be recognized in any case.

Unreal Engine and Claude: advantages and headaches

Published by Paolo on 10/04/2026

I use Claude to make my prototypes within Unreal Engine. I don’t have anything embedded in the engine itself, I have the program installed and go back and forth to implement what the LLM suggests me.

It works pretty good, I have to say. On one end, it forces me to structure well the problem to solve; Claude helps with everything, from research to properly framing. I am faster in creating my own JIRA tasks and message my colleagues in a proper and clear way. Then, I use blueprint and I have to say that the results (from a prototype perspective) are pretty satisfying. Also, at the end of each chat I tell it to create a report for its knowledge base, so that in future should be better and better. At least, I hope so.

There is a challenge though: switching back and forth from Claude to the engine to implement what the LLM says is tiring and I end up my days with headache. It’s like having someone giving you suggestions constantly. I know there is a way to integrate everything into the engine, but it’s still experimental and I don’t want to risk on a shared code.

Powered by