Skip to content

Tag: insight

How a Game Justifies Itself in 2026

Published by Paolo Gambardella on 26/05/2026

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

Eduard and I are working on an independent project, since we’re at a point where we can build our portfolios. If this is your first time here, I’m a game design consultant specialising in the ideation and pre-production phase of new casual mobile f2p games. Eduard is my assistant, who joined me recently through a bootcamp where I was teaching. The collaboration is going really well, but as always there are quieter periods where the workload drops off.

The new project is called RETROFP for now, and it’s an idea I’ve been turning over in my head for a while: take the Habby method (find a meta-game that works across several titles and only swap out the core) and bring it to Steam, applying it to the classics that shaped us.

We’ve defined and built a first prototype, learned from it, and now we’re on to the second. It’s also a way to train my collaborator, so we’re taking our time. Lately I keep asking myself: why this game, why now? I think that question is no longer optional, and it breaks down into three parts.

What are you promising the player?

It’s about fantasy and identity: who does the player become while playing?

  • In RETROFP, the first game is inspired by F-Zero, but it’s futuristic rally racing. The most radical choice we made is this: the car never crashes. You never lose. You just go faster or slower, and that’s it.
  • F-Zero is a game about speed you have to survive. Ours is a game about speed you inhabit. The fantasy isn’t “hold it together and win” — it’s “nothing can stop you, chase the peak”. Speed as expression, not as risk.

The idea is to give players the freedom to experiment with the physics. In our minds, it’ll be a game that’s satisfying to watch live in front of an audience of fans. We’re building a series of prototypes around this fantasy.

Where do you sit on the spectrum between familiar and new?

Players always want something new, and every game positions itself on a spectrum. On one end, too familiar: it disappears into the noise, nobody has a reason to pick it over what already exists. On the other, too new: nobody understands what they’re looking at, the cognitive cost of engaging is too high.

  • RETROFP has plenty of familiar elements: the racing, the unlock meta-game, the live events. The new elements are more specific: no crashes, a Habby-style framework applied to Steam (practically non-existent in that form), and a core that changes with each title under the same umbrella.
  • The pattern is recombination: a proven mechanic taken somewhere it’s never been.

The risk isn’t just in the design — it’s in the marketing and communication too. “You never crash” risks landing as “too easy”. One of the things we’re trying to work out through our prototypes is how to get ahead of potential objections from players and from the people who’ll spread the word (journalists, streamers, and so on).

Why you, why now?

A solid pitch answers two distinct questions that often get muddled together. The first is the commercial why: why would anyone buy it? What space does it occupy in the market? Why now? The second is the artistic why: why are you making this game? What do you want the player to feel that other games aren’t giving them?

  • For RETROFP, the commercial why is the empty space between Habby’s mobile engagement and Steam’s indie quality. That territory is almost unoccupied, as far as I can tell.
  • The artistic why is different: we want people to feel the F-Zero fantasy, but we want speed to be a gift rather than an added risk.

The question “why this game?” isn’t a question for publishers. It’s a question for you, first and foremost. And if you don’t have the answer yet, better to find that out now.

Wish us luck!

The present is cross-functional, the future is high-quality

Published by Paolo Gambardella on 25/05/2026

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

The stores are drowning in games. We can all see it, and it’s a direct consequence of something obvious: making a simple game has become quickly accessible. Godot, Unity, asset stores, AI for code, YouTube tutorials for absolutely anything. Development time has compressed brutally. So everyone’s doing it.

The result is a flood. Clones, games generated through semi-automated pipelines, products assembled rather than designed. Each of these games shares the same trait: made quickly, with a small team or solo, with little investment per unit.

When everyone does the easy thing, the hard thing gains value. Even Roblox is proving this, with its new strategy of focusing on HD games. If simple games become a commodity, then games that require something you can’t auto-generate become rare.

The thing that’s been living rent-free in my head

Teams in the near future have one new defining characteristic: they can be genuinely cross-functional. Not in the buzzword sense we’ve been hearing from companies for years. In a concrete, practical, radical way.

Some examples.

  • A designer no longer has to wait for a programmer to build a prototype. With today’s tools, they can build something functional in hours. They can test their game loop before the meeting with the tech team is even in the calendar.

  • An artist can implement directly in-engine without waiting for tech artist support. An artist who understands a bit of how the engine works is no longer an exotic exception — they’re just a normal asset to the team.

  • A writer can test their narrative in a working build without filing a ticket and waiting for the gameplay team to “find a slot in the next sprint”.

The roles don’t disappear. The excuse does.

To be clear: I’m not saying specialised roles will become useless. An experienced tech artist does things a shader-graph artist will never pull off. A senior programmer solves problems that a designer with an AI coding assistant can’t even properly articulate.

That’s not the point. The handoff barrier between roles gets lower. And with that barrier goes the industry’s most comfortable excuse: that’s not my responsibility.

If in the past you could sit in a cosy niche and wait for someone else to do their bit, today that’s changing. A team that sits around waiting for the “programmer bottleneck” when the designer could prototype, or the “tech artist bottleneck” when the artist could implement, is a team wasting time artificially.

Agility isn’t an abstract value. It’s the concrete ability to take an idea from your head to a working screen in as little time as possible, with the resources available. Today, those available resources have changed.

The thing that’s hard to copy

There’s an underlying question running through all of this: what can’t be automated or cloned?

The answer I’ve landed on is: a team that genuinely works well together, around a vision that’s actually worth building, with enough overlapping skills that no single bottleneck can hold everything up.

That combination can’t be copied. You can’t prompt your way to it.

And it’s exactly that combination you need to make the games that, in the coming years, will have the best shot. What does that mean in practice? That the smartest companies will be the ones capable of retaining talent — not working people into the ground and then laying everyone off the moment the title ships.

A Brief Survival Guide for Junior Designers

Published by Paolo Gambardella on 22/05/2026

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

Last night I was at BCN Gamedev Society, a monthly meetup for game developers in Barcelona. I spoke to a lot of people and caught up with old friends. I also got to chat with several juniors who want to break into the industry — concept artists and game designers. All of them dealing with the same problem: how do you get experience when nobody will hire you because you don’t have experience?

It’s not a new question. But today the answer looks very different from what it did ten years ago.

The code is being rewritten

I read a LinkedIn post that got me thinking. The core idea was this: money has always been the code society uses to translate human time into something its systems can read.

  • You have a skill → it becomes a salary.
  • You have a need → it becomes a price.
  • You have a future → it becomes credit.

The trouble is that money is a low-resolution system. It can measure output, not meaning. It can reward production, not direction.

And now AI is dismantling exactly that promise: if generating asset variants, doing QA on repetitive scenarios, or brokering information between teams are all things machines do better — what’s left for the junior who was learning by doing precisely those things?

The actual problem

Let’s take a concrete example. A junior concept artist wants to break into the industry. They’ve studied, they have a decent portfolio. But a studio will often choose a senior who, with ComfyUI and well-crafted prompts, produces in under a day what the junior would take a week to deliver.

You build experience by doing things — but if the entry-level work gets automated, where do you actually learn? How do you learn by osmosis in this new reality?

Survival tips

Here are some concrete ideas.

1. Stop competing where AI wins.

AI wins on production speed, consistency, and infinite variation. It doesn’t win on taste, art direction, or the intuition for what will land with that player, in that cultural context, with that emotional tone.

If your portfolio says “I can write a GDD quickly”, you’re on the wrong turf. If it says “I know how to choose, curate, direct, and explain why a decision works”, you’re in a much better position, in my view.

2. Ship small things, made with other people.

A junior game designer with five small games on itch.io, all made as part of a team, is worth more than someone with a portfolio full of unrealised concepts. What you’ve shipped shows you’ve been through the full cycle: idea → prototype → feedback → release.

That’s real experience, in a team context. And it doesn’t require anyone to hire you first.

  • Game jams to work directly with other people
  • Personal projects you then put in front of players and take notes on how they actually behave
  • Weekend experiments you publish on a public Discord to collect feedback

The goal is to build a track record of decisions made in response to real interactions — and real player behaviour you’ve observed yourself.

3. Look for a senior to work alongside, not a junior position.

The “senior + AI” dynamic that’s becoming the norm paradoxically creates room for informal collaborations. A senior with too much on their plate and too few reliable juniors is often open to accepting help in exchange for a small financial arrangement and some mentorship. It’s not ideal, but it’s how things work. And when you’re around someone with experience and judgement, you learn by osmosis. That’s always been true.

BCN Gamedev Society, online communities, indie studio Discords — those are the places where those conversations happen.

4. Use AI to develop your taste.

The trap for juniors is using AI to produce more stuff, and ending up just producing more mediocrity, faster.

  • Generate 50 variants with AI.
  • Then pick one.
  • Know why you picked it.
  • Then iterate.

Your ability to judge — what to keep, what to cut, and why — is the one thing that won’t be automated any time soon.

5. Short-term survival is a separate problem.

I’m not going to tell you universal basic income is just around the corner and everything will be fine. Maybe it arrives, maybe it doesn’t. In the meantime, there are bills to pay.

Some concrete options for keeping the lights on while you build your track record:
– Gamification freelance work for clients outside the industry (startups, corporate training, educational)
– Content creation: if you can explain game design in an interesting way, there’s an audience for it
– Tutoring, online courses, local workshops
– UX writing, product design, narrative design for non-game clients

None of these are the career you want, but they’re bridges.

Conclusion

The experience paradox isn’t new, but it’s getting sharper. And the answer is to build real experience in unconventional ways:

  1. make small things and use them as a way to connect with others
  2. stay close to people who know more than you
  3. develop taste, and learn to communicate it.

Money measures what the system can already read. What systems can’t read yet is taste. Intuition. A sense of what’s actually worth making.

For now, that’s still our territory.

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.

Freshness is safer in ideation stage

Published by Paolo on 27/04/2026

When two medics decided to make Baldur’s Gate, they didn’t have experience with CRPGs. When Mr. Myiamoto directed FZero on SNES he wasn’t a veteran in racing games. When a marketing guy from Ubisoft decided to make a realistic-style JRPG together with a programmer, he didn’t have previous experience in the genre.

Still, many companies publish job offers for specific positions requiring previous experience in the specific genre they are developing. It’s because of the belief that higher skill means faster results, and more important, less risks. This happens a lot on high-quality games and mobile F2P, because these business models became managed in a McKinsian way. And that, kids, is why they are in trouble.

Still, games like PRAGMATA are showing that there are audiences eager to new experiences, with unique blends of mechanics. I don’t know their stories, but I am playing the game and I wouldn’t be surprised if among their team there are designers with no previous experience with 3D action-adventure games. Video games like PRAGMATA are only possible when you are open to a completely different perspective, and when you let people work. I believe it’s hard to find this fit if your job offer filters opportunities out.

Experience within a genre is very important, don’t get me wrong. But the more I work, the more I realize I am full of biases. The more experience I get, the more I push for research and playtesting. New audiences are playing in ways often ignored by a big portion of developers, a sort of tunnel vision you have when you make always the same thing over and over.

read more: https://gamedesignskills.com/game-development/stages-of-game-development-process/

This is one of the reasons that led me to be a freelancer, also if it comes with a price as everything good in our life. Probably the worst one is when a client wants me to tell them the hour using their own clock. They close to proposal, because they don’t really understand (and they actively ignore) the opportunities of ideation stage.

A potential use case for Microsoft

Published by Paolo on 24/04/2026

I read the last email that the new CEO of XBox sent to her employees. It is honestly an inspiring take on what’s next for XBOX, I am positive about this person. Maybe the fact she is not a games veteran is good for her actual position. Or maybe I am just a dreamer, I don’t know.

There is one use case that I believe they can tackle pretty “easily”, and position themselves like the platform for everyone they want to become. There are successful f2p midcore titles that occupy too much space on the smartphone. Often they require the latest models to run at the higher quality. I believe that the f2p player doesn’t care of having a copy of what he is playing.

If XBOX manages to become the platform from which you can play the “Genshin Impacts” of the future in cloud on streaming, and maybe engage with mods and UGC for your fav games, there is the chance from them to become THE platform of the future. A sort of Roblox for Mobile f2p games. Of course, there are lots of limitation that may come from Apple and Google. Still, if they manage to do this right, they can really disrupt the market in my opinion.

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.

Game designing focusing on positioning

Published by Paolo on 13/04/2026

In this age of slop and significative increment of information and leisure that people receive, positioning will be always more critical. One of the mistakes clients make is to think in positioning like something belonging to the game. But positioning it’s in players’ minds, the game is just a medium.

If you see the recent successes you will notice how they well extremely clear in terms of positioning in the minds of people:

  • Resident Evil Requiem: the original and unique horror game
  • Crimson Desert: the open world for fun, not story or stat-oriented players
  • Pixel Flow: high intensity puzzle game, where you should master the speed of the belt

Game design should help in this. In fact, it’s impossible solely using marketing to identify the right patterns to spot a new genre where you position yourself. People in their mind have like 2-3 slots maximum per category. So what’s your?

How to help your team position the game

Every single time a new game starts, you discuss around its genre. The game genre is a shared language among everybody involved. You can say “I want to make a racing game” as a developer, but you can also declare “I don’t like souls-like games” as a player. The genre is a good point of start.

In mobile f2p a common philosophy (because it’s a service business) it to think like “let’s take the players from this other mobile game”. So you are playing to steal somehow players from your competitors. I think it has advantages and disadvantages. The positive thing is that you will become laser focused in offering a bigger/better game that already existed, basing on your own resources and expertise. The disadvantage is that you may ignore the context of your competitor and end up competing with a giant that will crush you. I think in all the companies that are trying to make a Brawl Stars but better. Good luck with that!

Another philosophy is to create your own genre. You spot motivations, study the use cases, determine possible gaps, and innovate accordingly. This is my favorite method, but it holds risks. Because you need real taste and true engagement with the community. You need to really will to also put out fast things that may not work. It’s not for everybody. As a consultant, for instance, I cannot propose that to all my clients.

Conclusions

There are no silver bullets, that’s clear. Otherwise they would have been already taken by others. You need to be really aware of your situation (or the situation of your employer), to decide the best path. Nobody said it was easy, but one thing is important: game design in the AI era is required to care about the game position. Otherwise it will be meaningless.

Management and direction

Published by Paolo on 08/04/2026

Last year I found a great client; good team, excellent leadership, profitable company. The project was (well, is) ambitious and novel. I felt part of the leadership team, I contributed to the development of their MVP. And then, a more expert designer joined and I was out. I had an interesting chat with my client, and he explained me exactly why the decision. It made sense, I learnt a lot. Still, it hurt because everything worth in life hurts a little.

Now that it’s one month since I joined GSC Game World, I already feel there is something very different in the way of managing high-quality projects compared with mobile f2p. Mobile needs pragmatism: you are chasing big numbers because you are investing huge amounts of money to give a highly technological product in the hand of distract people for free with the hope to engage their attention. High quality games, on the other end, are for people who decide to light a console up to be immersed into an experience they paid for.

And this leads to a fundamental difference: (product) management is what leads mobile, while creative direction is what leads high quality games. Of course, I am passionate and prepared designer and I can tackle any challenge, plus I have a certain age and experience so I can be a great leader. But mobile games are managed in a McKinsey-an style, and companies chase perfection. And the best way to avoid the risk of not having it is to hire people with a real pedigree (which I don’t have). On the other end, PC/Console single player high quality games (open world, FPS, survival) look for people capable of prototyping and realize the creative vision being away of design pillars, vision, and so on.

Two different worlds that I am sure can learn from each other. I know I will bring learnings from premium to mobile, and viceversa.

Powered by