Skip to content

Paolo's Blog Posts

Comment justifier un jeu en 2026

Published by Paolo Gambardella on 26/05/2026

Cet article a été écrit à l’origine en italien par Paolo Gambardella. Il a été traduit par un agent d’intelligence artificielle et peut contenir des inexactitudes.

Eduard et moi travaillons sur un projet indépendant, profitant d’une période où on peut étoffer notre portfolio. Si c’est la première fois que tu tombes sur ces lignes : je suis consultant en game design, spécialisé dans la phase d’idéation et de pré-production de nouveaux jeux mobile casual f2p. Eduard est mon assistant, arrivé récemment grâce à un bootcamp où j’enseignais. La collaboration tourne à plein régime, mais comme toujours, il y a des moments où la charge de travail est plus légère.

Le nouveau projet s’appelle RETROFP pour l’instant, et c’est une idée qui me trotte dans la tête depuis un moment : prendre la méthode Habby (trouver un méta-jeu commun à plusieurs titres et ne changer que le core) et la porter sur Steam en l’appliquant aux classiques qui nous ont forgés.

On a défini et réalisé un premier prototype dont on a tiré des leçons, et on est maintenant sur le deuxième. C’est aussi une façon de former mon collaborateur, donc on prend le temps qu’il faut. Ces derniers jours, je me pose la question : pourquoi ce jeu, maintenant ?. Je pense aujourd’hui que cette question n’est plus optionnelle, et qu’elle se décompose en trois parties.

Qu’est-ce que tu promets au joueur ?

Il s’agit de fantasme et d’identité : qui devient le joueur en jouant ?

  • Sur RETROFP, le premier jeu s’inspire de F-Zero, mais c’est du rally futuriste. Le choix le plus radical qu’on ait fait, c’est celui-ci : la voiture ne percute jamais rien. On ne perd pas. On va juste plus ou moins vite, c’est tout.
  • F-Zero est un jeu sur une vitesse qu’il faut survivre. Le nôtre est un jeu sur une vitesse qu’il faut habiter. Le fantasme n’est pas « tiens la pression et gagne », mais « rien ne peut t’arrêter, cherche le sommet ». La vitesse comme expression, pas comme risque.

L’idée est donc de laisser les joueurs libres d’expérimenter avec les physiques. Dans notre imaginaire, ce sera un jeu agréable à regarder en live devant un public de fans. On enchaîne une série de prototypes autour de ce fantasme.

Où tu te situes sur le spectre entre familier et nouveau ?

Les joueurs veulent toujours de la nouveauté, et chaque jeu se positionne sur un spectre. D’un côté, trop familier : il se noie dans la masse, personne n’a de raison de le choisir plutôt que ce qui existe déjà. De l’autre, trop nouveau : personne ne comprend ce qu’il regarde, le coût cognitif pour s’y approcher est trop élevé.

  • RETROFP compte beaucoup d’éléments familiers : le racing, le méta-jeu de déblocage, les événements live. Les éléments nouveaux sont plus ciblés : aucun crash, un framework style Habby appliqué à Steam (pratiquement inexistant sous cette forme), un core qui change à chaque titre au sein du même ensemble.
  • Le pattern, c’est la recombinaison : un mécanisme éprouvé amené là où il n’est jamais allé.

Le risque n’est pas seulement dans le design, mais aussi dans le marketing et la communication. « Tu ne percutes jamais rien » risque d’être perçu comme « trop facile ». L’une des réponses qu’on cherche dans nos prototypes, c’est aussi d’anticiper les objections potentielles de nos futurs joueurs et de ceux qui relaient le jeu (journalistes, streamers, etc.).

Pourquoi vous, pourquoi maintenant ?

Une bonne proposition répond à deux questions distinctes qu’on confond souvent. La première, c’est le pourquoi commercial : pourquoi quelqu’un l’achèterait ? Quelle place occupe-t-il sur le marché ? Pourquoi maintenant ? La seconde, c’est le pourquoi artistique : pourquoi vous faites ce jeu ? Qu’est-ce que vous voulez que le joueur ressente, que les autres jeux ne lui donnent pas ?

  • Pour RETROFP, le pourquoi commercial, c’est l’espace vide entre l’engagement mobile d’Habby et la qualité indie de Steam. Ce territoire est quasi désert, d’après ce que j’observe.
  • Le pourquoi artistique est différent : on veut que les gens ressentent le fantasme de F-Zero, mais on veut que la vitesse soit un cadeau, pas un risque supplémentaire.

La question « pourquoi ce jeu ? » n’est pas une question pour les éditeurs. C’est une question pour toi, avant tout. Et si tu n’as pas encore la réponse, autant le découvrir maintenant.

Souhaitez-nous bonne chance !

Le présent est cross-functional, l’avenir high-quality

Published by Paolo Gambardella on 25/05/2026

Cet article a été écrit à l’origine en italien par Paolo Gambardella. Il a été traduit par un agent d’intelligence artificielle et peut contenir des inexactitudes.

Les stores sont submergées de jeux. On le voit tous, et c’est une conséquence directe de quelque chose d’évident : faire un jeu simple est devenu rapidement accessible. Godot, Unity, asset stores, IA pour le code, tutoriels YouTube pour n’importe quoi. Le temps de développement s’est compressé de manière brutale. Et du coup, tout le monde s’y met.

Le résultat, c’est un déluge. Des clones, des jeux générés avec des pipelines semi-automatisées, des produits assemblés plutôt que conçus. Chacun de ces jeux a la même caractéristique : il est fait vite, avec une petite équipe ou en solo, avec peu d’investissement par unité.

Quand tout le monde fait la chose facile, la chose difficile prend de la valeur. Même Roblox le démontre, avec sa nouvelle stratégie de miser sur les jeux HD. Si les jeux simples deviennent une commodité, alors les jeux qui exigent quelque chose qu’on ne génère pas automatiquement deviennent rares.

Ce qui me trotte dans la tête

Les équipes du futur proche ont une caractéristique nouvelle : elles peuvent être vraiment cross-fonctionnelles. Pas dans le sens galvaudé qu’on entend en entreprise depuis des années. De façon concrète, pratique, radicale.

Des exemples.

  • Un designer n’a plus besoin d’attendre un programmeur pour construire un prototype. Avec les outils d’aujourd’hui, il peut construire quelque chose de fonctionnel en quelques heures. Il peut tester sa boucle de jeu avant même que la réunion avec la tech team soit mise au calendrier.

  • Un artiste peut implémenter directement dans le moteur sans attendre le support des tech artists. L’artiste qui comprend un peu comment fonctionne le moteur n’est plus une exception exotique, c’est une ressource normale.

  • Un writer peut tester sa narration dans une build fonctionnelle sans ouvrir un ticket et attendre que l’équipe gameplay lui « trouve un créneau dans le prochain sprint ».

Les rôles ne disparaissent pas. C’est la bonne excuse qui disparaît.

Attention : je ne dis pas que les rôles spécialisés vont devenir inutiles. Un tech artist expérimenté fait des choses qu’un artiste avec shader graph ne fera jamais. Un programmeur senior résout des problèmes qu’un designer avec un assistant IA ne sait même pas formuler.

Le point est ailleurs. La barrière de transfert entre les rôles s’abaisse. Et avec elle disparaît aussi l’excuse la plus confortable de l’industrie : ce n’est pas mon problème.

Si avant tu pouvais rester dans ta niche confortable et attendre que quelqu’un d’autre fasse sa part, aujourd’hui le contexte est en train de changer. L’équipe qui s’assoit et attend le « blocage du programmeur » quand le designer pourrait prototyper, ou le « blocage du tech artist » quand l’artiste pourrait implémenter, c’est une équipe qui gaspille du temps de façon artificielle.

L’agilité n’est pas une valeur abstraite. C’est la capacité concrète de faire passer une idée du cerveau à un écran fonctionnel dans le moins de temps possible, avec les ressources disponibles. Aujourd’hui, ces ressources ont changé.

Ce qui est difficile à copier

Il y a une question sous-jacente à tout ça : qu’est-ce qu’on ne peut pas automatiser ou cloner ?

La réponse que je me suis donnée : une équipe qui fonctionne vraiment bien ensemble, sur une vision qui vaut vraiment la peine d’être développée, avec suffisamment de compétences qui se recoupent pour ne dépendre d’aucun goulot d’étranglement unique.

Cette combinaison-là, on ne peut pas la copier. Impossible à générer avec un prompt.

Et c’est exactement cette combinaison qui est nécessaire pour faire les jeux qui, dans les prochaines années, auront le plus de chances de s’en sortir. Qu’est-ce que ça veut dire concrètement ? Que les boîtes les plus intelligentes seront capables de garder leurs talents, plutôt que de les traiter comme des bêtes de somme pour ensuite tout licencier une fois le titre sorti.

Bref guide de survie pour les designers juniors

Published by Paolo Gambardella on 22/05/2026

Cet article a été écrit à l’origine en italien par Paolo Gambardella. Il a été traduit par un agent d’intelligence artificielle et peut contenir des inexactitudes.

Hier soir j’étais au BCN Gamedev Society, un meetup mensuel de développeurs de jeux à Barcelone. J’ai parlé avec beaucoup de monde et retrouvé de vieilles têtes connues. J’ai aussi eu l’occasion d’échanger avec plusieurs juniors qui veulent entrer dans l’industrie — concept artists et game designers. Tous avec le même problème : comment acquérir de l’expérience quand personne ne t’embauche précisément parce que tu n’en as pas ?

Ce n’est pas une question nouvelle. Mais aujourd’hui, la réponse est différente de ce qu’elle était il y a dix ans.

Le code se réécrit

J’ai lu un post LinkedIn qui m’a fait réfléchir. L’idée centrale était la suivante : l’argent a toujours été le code par lequel la société transformait le temps humain en quelque chose de lisible par les systèmes.

  • Tu as une compétence → elle devient un salaire.
  • Tu as un besoin → il devient un prix.
  • Tu as un avenir → il devient du crédit.

Le problème, c’est que l’argent est un système en “basse résolution”. Il peut mesurer le rendement, pas le sens. Il peut récompenser l’output, pas l’orientation.

Et maintenant l’IA est en train de démonter exactement cette promesse : si créer des variantes d’assets graphiques, faire de la QA sur des scénarios répétitifs, ou faire circuler l’information entre des équipes sont des choses que les machines font mieux — qu’est-ce qu’il reste au junior qui apprenait en faisant exactement tout ça ?

Le problème concret

Prenons un exemple réel. Un junior concept artist veut entrer dans l’industrie. Il a étudié, il a un portfolio correct. Mais un studio choisit souvent un senior qui, avec ComfyUI et des prompts bien construits, produit en moins d’une journée ce que le junior ferait en une semaine.

L’expérience s’accumule en faisant, mais si les postes d’entrée sont automatisés, où est-ce qu’on apprend ? Comment apprendre par osmose dans cette nouvelle réalité ?

Conseils de survie

J’ai quelques idées concrètes.

1. Arrête de te battre là où l’IA gagne.

L’IA gagne sur la vitesse de production, la cohérence, la variation à l’infini. Elle ne gagne pas sur le goût, la direction artistique, l’intuition de ce qui fonctionnera avec ce joueur, dans ce contexte culturel, avec ce ton émotionnel.

Si ton portfolio dit “je sais rédiger un GDD rapidement”, tu es sur le mauvais terrain. S’il dit “je sais choisir, curer, diriger et j’explique pourquoi un choix fonctionne”, tu as beaucoup plus de chances à mon avis.

2. Publie des petites choses faites avec d’autres personnes.

Un game designer junior avec cinq petits jeux sur itch.io réalisés en équipe vaut plus qu’un autre avec un portfolio de concepts jamais concrétisés. Tes réalisations prouvent que tu as traversé le cycle complet : idée → prototype → feedback → publication.

C’est de l’expérience réelle, en équipe. Et ça ne nécessite pas que quelqu’un t’embauche.

  • Des game jams pour travailler directement avec d’autres personnes,
  • des projets perso qu’on fera ensuite tester à des gens en prenant des notes sur leur comportement,
  • des expériences de week-end qu’on publiera sur un Discord public pour récolter des retours.

L’objectif, c’est de construire un track record de décisions prises à partir de l’interaction avec d’autres personnes et de comportements observés chez ses joueurs.

3. Cherche un senior à qui te coller, pas un poste junior.

La dynamique “senior + IA” qui devient dominante crée paradoxalement de la place pour des collaborations informelles. Un senior débordé avec peu de juniors fiables est souvent prêt à accepter de l’aide en échange d’une petite contribution financière et de la mentorship. C’est loin d’être idéal, mais c’est comme ça que ça marche. Et quand tu es à côté de quelqu’un qui a de l’expérience et du jugement, tu apprends par osmose. Ça a toujours été comme ça.

BCN Gamedev Society, communautés en ligne, Discords de studios indé : c’est là que ces conversations se passent.

4. Utilise l’IA pour développer ton goût.

Le piège pour les juniors, c’est d’utiliser l’IA pour produire plus de choses — et de finir par produire plus de médiocrité, plus vite !

  • Génère 50 variantes avec l’IA.
  • Puis choisis-en une.
  • Sache expliquer pourquoi.
  • Puis itère.

Ta capacité de jugement — ce qu’on garde, ce qu’on jette, pourquoi — c’est la seule chose qui ne s’automatise pas de sitôt.

5. La survie à court terme, c’est un problème à part.

Je ne vais pas te dire que le revenu universel de base débarque demain pour te sauver. Peut-être que ça arrive, peut-être pas. En attendant, les factures ne s’arrêtent pas.

Quelques options concrètes pour payer les factures pendant que tu construis ton track record :
– Freelance en gamification pour des clients hors industrie (startups, formation en entreprise, éducation)
– Création de contenu : si tu arrives à expliquer le game design de façon intéressante, il y a un public pour ça
– Tutorat, cours en ligne, ateliers locaux
– UX writing, product design, narrative design pour des clients hors jeu vidéo

Aucune de ces options n’est la carrière que tu veux, mais ce sont des ponts.

Conclusion

Le paradoxe de l’expérience n’est pas nouveau, mais il s’aggrave. Et la réponse, c’est d’accumuler une expérience réelle de façon non conventionnelle :

  1. faire de petites choses et s’en servir comme levier pour se connecter à d’autres,
  2. rester proche de ceux qui en savent plus que toi,
  3. développer son goût et savoir le transmettre aux autres.

L’argent mesure ce qui est déjà lisible par le système. Ce que les systèmes ne savent pas encore lire, c’est le goût. L’intuition. Le sens de ce qui vaut la peine d’être fait.

Pour l’instant, ça reste encore notre territoire.

La différence entre document et documentation

Published by Paolo Gambardella on 21/05/2026

Cet article a été écrit à l’origine en italien par Paolo Gambardella. Il a été traduit par un agent d’intelligence artificielle et peut contenir des inexactitudes.

L’une des responsabilités principales d’un game designer, c’est d’écrire de la documentation de design. N’importe qui peut écrire des documents, mais un designer, lui, produit de la documentation — et c’est une tout autre affaire.

Un document, ça contient des pensées, des idées, n’importe quoi. La documentation, en revanche, est un type de document spécifique sur quelque chose de concret. Une analyse d’un jeu concurrent. Le résultat d’un playtest. Une feature qu’on a construite et observée en action. Un prototype qui a répondu à une question précise.

Pour comprendre pourquoi cette règle est si souvent bafouée, il est utile de réfléchir à comment la connaissance s’accumule au fil du développement d’un jeu.

Concept DOCUMENTS

Au début d’un projet, presque tout est incertain.

  • Constraints | Il y a des choses qu’on sait déjà : la plateforme cible, le genre, peut-être le budget.
  • Frontiers | Il y a des questions auxquelles on sait qu’on doit répondre : comment fonctionne le core loop, quelle est la durée d’une session type.
  • Risks | Il y a les choses qu’on ne sait pas qu’on ne sait pas encore. Les problèmes de design qui n’émergent que quand le joueur a la manette en main. Les interactions entre systèmes qui semblaient évidentes sur le papier et se révèlent catastrophiques en pratique. Les hypothèses que personne n’a jamais remises en question parce qu’elles paraissaient tellement évidentes qu’elles ne méritaient pas qu’on s’y attarde.

Un concept document vit presque entièrement dans cette troisième couche. Ce n’est pas de la documentation, c’est un instantané de l’imaginaire de l’équipe à un moment précis.

Game Design DOCUMENTATION

La vraie documentation émerge après. Après qu’on a prototypé et découvert que la mécanique qui semblait brillante ne fonctionne pas comme on le pensait. Après qu’on a analysé comment un autre jeu a résolu le même problème. Après qu’on a testé et observé. À ce stade, on a quelque chose à documenter pour de bon.

Documents et Documentation

Un document sert un objectif temporaire. Les notes d’une réunion sont un document. Un concept doc est un document. Une liste d’idées griffonnées avant une session de brainstorming est un document. Ce sont des outils de travail valables, nécessaires, et ils ont une durée de vie naturelle : ils servent maintenant, puis ils passent aux oubliettes.

La documentation, en revanche, est pensée pour durer.

  • Elle doit être claire pour quelqu’un qui n’était pas dans cette réunion.
  • Elle doit être pratique, une référence qu’on peut vraiment utiliser, pas seulement lire.
  • Elle doit inspirer celui qui la lit six mois plus tard, quand l’enthousiasme des débuts est retombé et qu’on a besoin d’appuis concrets.
  • Et elle doit être attrayante : pas comme exercice esthétique, mais parce que si personne n’ouvre un document, ce document n’existe pas. J’applique cette formule : 60 % de l’espace doit être occupé par des éléments visuels (diagrammes, images, vidéos…). 30 % par des données et des tableaux. 10 % de texte. La documentation, ce n’est pas un traité ou un roman à lire !

Tous les documents ne sont pas de la documentation, et le projet nécessitera différents types de documents. Votre équipe, elle, a besoin de documentation.

À quoi ressemble une vraie documentation

Une bonne documentation de design répond à quelques questions de façon univoque : c’est quoi ce jeu ? Pourquoi c’est intéressant ? Quelle est la fantasy, la promesse émotionnelle faite au joueur ? Quelles sont les features core — pas toutes les features, seulement celles qui définissent l’identité du produit ? Comment fonctionne exactement ce système ? Et suffisamment de contexte de production pour rendre le document actionnable.

Il y a un principe que je trouve particulièrement utile dans ce sens : si une équipe n’arrive pas à expliquer son jeu de façon claire et concise, c’est probablement que le design n’est pas encore assez clair. La clarté de la documentation reflète la clarté de la pensée. Un document dense, bourré de sections et de sous-sections qui cherchent à couvrir tous les cas de figure, c’est souvent le signe qu’on ne sait pas encore assez pour documenter.

Et ça nous ramène à la règle numéro 1. Si vous n’avez pas encore quelque chose de concret à documenter, ce n’est peut-être pas le moment d’écrire de la documentation. C’est le moment de faire de la recherche. De construire un prototype. De tester. De répondre aux questions qu’on ne sait pas encore qu’on a. D’apprendre et de découvrir.

Est-ce que ça documente quelque chose qui existe, ou quelque chose qu’on veut construire ?

Prototypes pour apprendre

Published by Paolo Gambardella on 20/05/2026

Cet article a été écrit à l’origine en italien par Paolo Gambardella. Il a été traduit par un agent d’intelligence artificielle et peut contenir des inexactitudes.

Les prototypes sont l’un des domaines où le game design a énormément évolué ces derniers mois. Les nouveaux algorithmes de machine learning et d’automatisation permettent à tout le monde d’aller beaucoup plus vite pour produire les artefacts dont on a besoin pour apprendre et faire apprendre à son équipe. C’est une vraie avancée, mais ça peut exacerber une tendance que j’ai observée dans certaines équipes : créer un prototype trop sophistiqué qui finit par se transformer en démo.

Le prototype sert à apprendre, à répondre à des questions. La démo sert à convaincre, à obtenir le feu vert, à vendre. Le problème apparaît quand on crée un prototype trop léché pour sembler convaincant, mais trop ambigu pour qu’on puisse vraiment dire qu’on était en train d’apprendre. On finit par n’apprendre grand-chose et ne convaincre personne.

Un exemple concret. Si c’est la première fois que vous me lisez, sachez que je suis consultant en game design spécialisé dans l’idéation et la pré-production de nouveaux jeux vidéo, principalement free-to-play. J’ai un petit studio, et avec mes collaborateurs la semaine dernière, nous avons créé ce prototype sous Godot :

  • Le projet a démarré lundi avec une vision que je mûris depuis un moment, et que j’ai concrétisée dans un document de vision
  • Mon assistant Eduard a recherché d’autres jeux et m’a remis un concept document mercredi
  • Le jeudi, j’ai donné ce document à Claude Code en lui demandant de me générer un prototype de base
  • Du vendredi au dimanche, j’ai fait de courtes interventions en fonction des idées qui me venaient pendant que je faisais autre chose.

Après avoir livré le résultat à mon assistant, il l’a testé pendant une journée entière et m’a donné son point de vue. La discussion a rapidement dérivé vers des problèmes du type « le circuit généré est monotone » ou « on n’arrive pas à percuter les voitures ». Des choses qui comptent à partir de la démo, mais pas à ce stade. À deux, en discutant, on a réussi à identifier le vrai apprentissage, ce qu’on aime dans ce prototype. On le met de côté, on le documente, et on passe à la prochaine phase d’apprentissage.

Si on n’avait pas été à deux, si on avait été dans une entreprise plus grande, on aurait probablement dû préparer une présentation avec les learnings pour aligner tout le monde. C’est comme ça que j’aime avancer — mais je vous le dis : la tentation de vouloir régler les problèmes techniques ou améliorer les « intelligences » artificielles des adversaires virtuels a été forte. Pourquoi ? Parce que maintenant c’est facile, c’est rapide.

Vous pouvez le faire, mais votre concurrent aussi. Pour moi, ce qui fait la différence, c’est de se concentrer sur les bonnes choses au bon moment. Aujourd’hui plus que jamais, le discernement est indispensable — un contact m’a dit que les délais de validation sur l’App Store s’allongent considérablement vu le volume d’apps « vibe-codées » qui arrivent aux modérateurs. Si on doit attendre plus longtemps pour nos validations, autant que ce soit pour quelque chose qui en vaille vraiment la peine.

AI Slop vs. Creative Power: A Love-Hate Relationship

Published by Paolo on 15/05/2026

I have mixed feelings about the integration of artificial intelligence into our digital spaces. On one hand, public platforms are deteriorating. From YouTube recommendations to mobile game ads, our feeds are flooded with low-quality “AI slop”—clickbait thumbnails and content engineered purely around anger and hyperbole. The internet has become a frantic, exhausting battle for our attention.

Yet, as a creator, generative AI has completely revolutionized my workflow by automating the tedious parts of development:

  • Game Design Documents (GDD): I can instantly generate a robust structural base for 15 GDDs a month without redoing the groundwork every time.
  • Workflow Automation: Converting a massive document into actionable JIRA tasks used to take days; now, it takes an hour of high-level planning and bulk creation.

Beyond productivity, experimenting with these tools has brought back a sense of community. Sharing new AI discoveries in private chats feels exactly like the early days of the internet—reminiscent of finding an old IRC channel or a niche forum.

While the public internet grows increasingly dull due to algorithmic noise, the backend world of AI innovation has unlocked a frontier that is just as exciting as the internet itself once was.

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.

Powered by