Skip to content

Paolo's Blog Posts

Cómo se justifica un videojuego en 2026

Esta entrada fue escrita originalmente en italiano por Paolo Gambardella. Ha sido traducida por un agente de inteligencia artificial y puede contener imprecisiones.

Eduard y yo estamos trabajando en un proyecto independiente, ya que estamos en un momento en el que podemos construir portfolio. Si es la primera vez que lees esto, soy consultor de game design especializado en la fase de ideación y preproducción de nuevos juegos mobile casual f2p. Eduard es mi asistente, que llegó hace poco a través de un bootcamp en el que yo daba clases. La colaboración está yendo viento en popa, pero como siempre hay momentos en los que la carga de trabajo es menor.

El nuevo proyecto se llama RETROFP por el momento, y es una idea que llevo un tiempo dándole vueltas: coger el método Habby (encontrar un metagame común a varios títulos y cambiar solo el core) y llevarlo a Steam aplicándolo a los clásicos que nos han formado.

Hemos definido y construido un primer prototipo del que hemos aprendido, y ahora estamos en el segundo. Es también una forma de formar a mi colaborador, así que nos lo tomamos con calma. Estos días me estoy preguntando: ¿por qué este juego, ahora?. Hoy creo que esta pregunta ya no es opcional y se puede descomponer en tres partes.

¿Qué le prometes al jugador?

Se trata de fantasía e identidad: ¿en quién se convierte el jugador mientras juega?

  • En RETROFP, el primer juego está inspirado en F-Zero, pero es rally futurista. La decisión más radical que hemos tomado es esta: el coche nunca choca. No se pierde. Solo vas más o menos rápido, y punto.
  • F-Zero es un juego sobre una velocidad que hay que sobrevivir. El nuestro es un juego sobre una velocidad en la que habitar. La fantasía no es “aguanta la presión y gana”, sino “nada puede detenerte, busca la cima”. Velocidad como expresión, no como riesgo.

La idea es, por tanto, dejar a los jugadores libres de experimentar con las físicas. En nuestra cabeza, será un juego agradable de ver en directo para un público de fans. Estamos haciendo una serie de prototipos alrededor de esta fantasía.

¿Dónde estás en el espectro entre familiar y nuevo?

Los jugadores siempre quieren novedades, y cada juego se posiciona en un espectro. Por un lado, demasiado familiar: desaparece entre el ruido, nadie tiene un motivo para elegirlo frente a lo que ya existe. Por el otro, demasiado nuevo: nadie entiende lo que está viendo, el coste cognitivo de acercarse es demasiado alto.

  • RETROFP tiene muchos elementos familiares: el racing, el metagame de desbloqueo, los eventos en directo. Los elementos nuevos son más precisos: sin crashes, un framework estilo Habby aplicado a Steam (prácticamente inexistente en esa forma), un core que cambia en cada título dentro del mismo paraguas.
  • El patrón es recombinación: un mecanismo probado llevado donde nunca había llegado.

El riesgo no está solo en el diseño, sino también en el marketing y la comunicación. “Nunca chocas” corre el riesgo de acabar siendo percibido como “demasiado fácil”. Una de las respuestas que buscamos en nuestros prototipos es también la de anticipar posibles objeciones por parte de nuestros potenciales jugadores y difusores del juego (periodistas, streamers, etc).

¿Por qué vosotros, por qué ahora?

Una buena propuesta responde a dos preguntas distintas que a menudo se confunden. La primera es el por qué comercial: ¿por qué alguien debería comprarlo? ¿Qué espacio ocupa en el mercado? ¿Por qué ahora? La segunda es el por qué artístico: ¿por qué hacéis vosotros este juego? ¿Qué queréis que sienta el jugador que otros juegos no le están dando?

  • Para RETROFP, el por qué comercial es el espacio vacío entre el engagement mobile de Habby y la calidad indie de Steam. Ese territorio está casi desierto según lo que he podido observar.
  • El por qué artístico es distinto: queremos que la gente sienta la fantasía de F-Zero pero queremos que la velocidad sea un regalo y no un riesgo añadido.

La pregunta “¿por qué este juego?” no es una pregunta para los publishers. Es una pregunta para ti, antes que para nadie. Y si todavía no tienes la respuesta, mejor descubrirlo ahora.

¡Deseadnos suerte!

El presente es cross-functional, el futuro high-quality

Esta entrada fue escrita originalmente en italiano por Paolo Gambardella. Ha sido traducida por un agente de inteligencia artificial y puede contener imprecisiones.

Le tiendas están inundadas de juegos. Lo vemos todos, y es una consecuencia directa de algo obvio: hacer un juego sencillo se ha vuelto rápidamente accesible. Godot, Unity, asset stores, IA para el código, tutoriales en YouTube para cualquier cosa. El tiempo de desarrollo se ha comprimido de forma brutal. Y entonces lo hace todo el mundo.

El resultado es un diluvio. Clones, juegos generados con pipelines semi-automatizadas, productos ensamblados más que diseñados. Cada uno de estos juegos tiene la misma característica: está hecho con prisas, con un equipo pequeño o en solitario, con poca inversión por unidad.

Cuando todo el mundo hace lo fácil, lo difícil gana valor. Lo está demostrando incluso Roblox, con su nueva estrategia de apostar por los juegos HD. Si los juegos sencillos se convierten en commodity, entonces los juegos que requieren algo que no se genera automáticamente se vuelven escasos.

El asunto que no me deja en paz

Los equipos del futuro próximo tienen una característica nueva: pueden ser realmente cross-functional. No en el sentido de palabra de moda que llevamos años escuchando en las empresas. De forma concreta, práctica, radical.

Pongamos ejemplos.

  • Un diseñador ya no tiene que esperar a un programador para construir un prototipo. Con las herramientas de hoy, puede construir algo funcional en horas. Puede testear su loop de juego antes de que la reunión con el equipo técnico esté siquiera en el calendario.

  • Un artista puede implementar directamente en el engine sin esperar el apoyo de los tech artists. El artista que entiende un poco cómo funciona el motor ya no es una rareza exótica, es un recurso normal.

  • Un writer puede testear su narrativa en una build funcional sin abrir un ticket y esperar a que el equipo de gameplay “le busque un hueco en el próximo sprint”.

Los roles no desaparecen. Desaparece la excusa.

Ojo: no estoy diciendo que los roles especializados vayan a volverse inútiles. Un tech artist con experiencia hace cosas que un artista con shader graph nunca hará. Un programador senior resuelve problemas que un diseñador con un asistente de IA ni siquiera sabe cómo plantear.

La cuestión es otra. La barrera de transferencia entre roles baja. Y con esa barrera desaparece también la excusa más cómoda de la industria: eso no es cosa mía.

Si antes podías quedarte en tu nicho tranquilo y esperar a que otro hiciera su parte, hoy el contexto está cambiando. El equipo que se sienta a esperar el “bloqueo del programador” cuando el diseñador podría prototipar, o el “bloqueo del tech artist” cuando el artista podría implementar, es un equipo que está desperdiciando el tiempo de forma artificial.

La agilidad no es un valor abstracto. Es la capacidad concreta de llevar una idea desde la cabeza a una pantalla funcional en el menor tiempo posible, con los recursos disponibles. Hoy esos recursos han cambiado.

Lo que es difícil de copiar

Hay una pregunta que subyace a todo esto: ¿qué es lo que no se puede automatizar ni clonar?

La respuesta que me he dado es: un equipo que funciona realmente bien junto, con una visión que de verdad merece la pena desarrollar, y con suficientes competencias solapadas como para no depender de ningún cuello de botella concreto.

Esa combinación no se puede copiar. Imposible de generar con un prompt.

Y es exactamente esa combinación la que hace falta para crear los juegos que, en los próximos años, tendrán más posibilidades. ¿Qué significa eso? Que las empresas más listas serán capaces de retener talento, en lugar de tratarlo como carne de cañón para luego despedir a todo el mundo con el título publicado.

Breve guía de supervivencia para diseñadores junior

Esta entrada fue escrita originalmente en italiano por Paolo Gambardella. Ha sido traducida por un agente de inteligencia artificial y puede contener imprecisiones.

Ayer por la noche estuve en BCN Gamedev Society, un encuentro mensual de desarrolladores de juegos de Barcelona. Hablé con mucha gente y reencontré a viejos amigos. También tuve ocasión de charlar con varios juniors que quieren entrar en la industria: concept artists y game designers. Todos con el mismo problema: ¿cómo consigues experiencia si nadie te contrata porque no tienes experiencia?

No es una pregunta nueva. Pero hoy tiene una respuesta distinta a la de hace diez años.

El código se está reescribiendo

Leí un post en LinkedIn que me hizo reflexionar. La idea de fondo era esta: el dinero siempre ha sido el código con el que la sociedad convertía el tiempo humano en algo legible para los sistemas.

  • Tienes una habilidad → se convierte en un salario.
  • Tienes una necesidad → se convierte en un precio.
  • Tienes un futuro → se convierte en crédito.

El problema es que el dinero es un sistema de “baja resolución”. Puede medir el rendimiento, no el sentido. Puede premiar el output, no la orientación.

Y ahora la IA está desmontando exactamente esa promesa: si crear variantes de assets gráficos, hacer QA sobre escenarios repetitivos, o mediar información entre equipos son cosas que las máquinas hacen mejor, ¿qué le queda al junior que estaba aprendiendo haciendo exactamente esas cosas?

El problema concreto

Pongamos un ejemplo real. Un junior concept artist quiere entrar en la industria. Ha estudiado, tiene un portfolio decente. Pero un estudio elige con frecuencia a un senior que, con ComfyUI y prompts bien construidos, produce en menos de un día lo que el junior tardaría una semana.

La experiencia se acumula haciendo, pero si los trabajos de “entrada” se automatizan, ¿dónde se aprende? ¿Cómo aprender por ósmosis en esta nueva realidad?

Consejos de supervivencia

Tengo algunas ideas concretas.

1. Deja de competir donde la IA gana.

La IA gana en velocidad de producción, en consistencia, en variación infinita. No gana en gusto, en dirección artística, en la intuición de qué va a funcionar con ese jugador, en ese contexto cultural, con ese tono emocional.

Si tu portfolio dice “sé redactar un GDD rápido”, estás en el terreno equivocado. Si dice “sé elegir, curar, dirigir y sé explicar por qué una decisión funciona”, tienes muchas más papeletas, en mi opinión.

2. Publica cosas pequeñas hechas con otras personas.

Un game designer junior con cinco juegos pequeños en itch.io hechos en equipo vale más que uno con un portfolio lleno de conceptos sin realizar. Tus resultados demuestran que has atravesado el ciclo completo: idea → prototipo → feedback → publicación.

Eso es experiencia real, en equipo. Y no requiere que nadie te contrate.

  • Game jams para trabajar directamente con otras personas,
  • proyectos personales que luego haremos probar a otros y sobre los que tomaremos notas de su comportamiento,
  • experimentos de fin de semana que publicaremos en un Discord público para recoger feedback.

El objetivo es construir un historial de decisiones tomadas a partir de la interacción con otras personas y de comportamientos observados en nuestros jugadores.

3. Busca a un senior al que arrimarte, no una posición junior.

La dinámica “senior + IA” que se está volviendo dominante crea paradójicamente espacio para colaboraciones informales. Un senior con demasiado trabajo y pocos juniors de confianza suele estar dispuesto a aceptar ayuda a cambio de una pequeña compensación económica y mentorship. No es lo ideal, pero así funciona esto. Y si estás cerca de alguien con experiencia y criterio, aprendes por ósmosis. Siempre ha sido así.

BCN Gamedev Society, comunidades online, Discords de estudios indie: esos son los sitios donde esas conversaciones ocurren.

4. Usa la IA para desarrollar tu gusto.

La trampa para los juniors es usar la IA para producir más cosas, y acabar produciendo más mediocridad más deprisa.

  • Genera 50 variantes con la IA.
  • Luego elige una.
  • Sabe explicar por qué.
  • Luego itera.

Tu capacidad de juicio —qué quedarte, qué descartar, por qué— es lo único que no se automatiza a corto plazo.

5. La supervivencia a corto plazo es un problema aparte.

No te voy a decir que la renta básica universal llegará mañana a salvarte. Igual llega, igual no. Mientras tanto, hay facturas que pagar.

Algunas opciones concretas para pagar las facturas mientras construyes tu historial:
– Freelance de gamificación para clientes fuera de la industria (startups, formación corporativa, educación)
– Creación de contenido: si consigues explicar game design de forma interesante, hay audiencia
– Tutorías, cursos online, talleres locales
– UX writing, product design, narrative design para clientes fuera del mundo del videojuego

Ninguna de estas es la carrera que quieres, pero son puentes.

Conclusión

La paradoja de la experiencia no es nueva, pero se está agudizando. Y la respuesta es acumular experiencia real de forma no convencional:

  1. hacer cosas pequeñas y usarlas como herramienta para conectar con otros
  2. estar cerca de quien sabe más que tú
  3. desarrollar gusto y saber transmitírselo a los demás.

El dinero mide lo que ya es legible para el sistema. Lo que los sistemas todavía no saben leer es el gusto. La intuición. El sentido de qué merece la pena hacer.

Por ahora, ese terreno sigue siendo nuestro.

La diferencia entre documento y documentación

Esta entrada fue escrita originalmente en italiano por Paolo Gambardella. Ha sido traducida por un agente de inteligencia artificial y puede contener imprecisiones.

Una de las responsabilidades principales de un game designer es escribir documentación de diseño. Cualquiera es capaz de escribir documentos, pero un designer se dedica a la documentación, que es algo diferente.

Un documento contiene pensamientos, ideas, lo que sea. La documentación, en cambio, es un tipo de documento específico sobre algo concreto. Una investigación sobre un juego de la competencia. El resultado de un playtest. Una feature que hemos construido y observado en acción. Un prototipo que ha respondido a una pregunta concreta.

Para entender por qué esta regla se viola tan a menudo, conviene pensar en cómo se acumula el conocimiento durante el desarrollo de un juego.

Concept DOCUMENTS

Al principio de un proyecto, casi todo es incierto.

  • Constraints | Hay cosas que ya sabemos: la plataforma objetivo, el género, quizás el presupuesto.
  • Frontiers | Hay preguntas que sabemos que tenemos que responder: cómo funciona el core loop, cuánto dura una sesión típica.
  • Risks | Hay cosas que aún no sabemos que no sabemos. Los problemas de diseño que solo emergen cuando el jugador tiene el mando en la mano. Las interacciones entre sistemas que parecían obvias sobre el papel y resultan un desastre en la práctica. Las suposiciones que nadie ha cuestionado nunca porque parecían tan evidentes que no merecían atención.

Un concept document vive casi por completo en esa tercera capa. No es documentación, es una instantánea de la imaginación del equipo en un momento concreto.

Game Design DOCUMENTATION

La documentación de verdad llega después. Después de haber prototipado y descubierto que la mecánica que parecía brillante no funciona como pensábamos. Después de haber analizado cómo otro juego ha resuelto el mismo problema. Después de haber testeado y observado. En ese momento sí tenemos algo que documentar de verdad.

Documentos y Documentación

Un documento sirve a un objetivo temporal. Las notas de una reunión son un documento. Un concept doc es un documento. Una lista de ideas apuntadas antes de una sesión de brainstorming es un documento. Son herramientas de trabajo válidas, necesarias, y tienen una vida útil natural: sirven ahora, luego pasan a la historia.

La documentación, en cambio, está pensada para durar.

  • Debe ser clara para alguien que no estuvo en esa reunión.
  • Debe ser práctica, una referencia que se pueda usar de verdad, no solo leer.
  • Debe inspirar a quien la lea seis meses después, cuando el entusiasmo inicial se ha enfriado y hacen falta puntos de apoyo concretos.
  • Y debe ser atractiva: no como ejercicio estético, sino porque si nadie abre un documento, ese documento no existe. Yo aplico esta fórmula: el 60% del espacio debe estar ocupado por elementos visuales (diagramas, imágenes, vídeos…). El 30% por datos y tablas. El 10% por texto. ¡La documentación no es un tratado ni una novela para leer!

No todos los documentos son documentación; el proyecto requerirá distintos tipos de documento. Tu equipo, en cambio, necesita documentación.

Cómo es una documentación de verdad

Una buena documentación de diseño responde a pocas preguntas de forma inequívoca: ¿qué es este juego? ¿Por qué es interesante? ¿Cuál es la fantasy, la promesa emocional que le hace al jugador? ¿Cuáles son las features core —no todas las features, solo las que definen la identidad del producto—? ¿Cómo funciona exactamente este sistema? Y suficiente contexto de producción como para que el documento sea accionable.

Hay un principio que me resulta especialmente útil en este sentido: si un equipo no es capaz de explicar su juego de forma clara y concisa, probablemente el diseño todavía no está suficientemente claro. La claridad de la documentación refleja la claridad del pensamiento. Un documento denso, lleno de secciones y subsecciones que intentan cubrir cada eventualidad, es a menudo la señal de que aún no sabemos lo suficiente para documentar.

Y esto nos devuelve a la regla número 1. Si todavía no tienes algo concreto que documentar, quizás no es el momento de escribir documentación. Es el momento de investigar. De construir un prototipo. De testear. De responder a las preguntas que aún no sabes que tienes. De aprender y descubrir.

¿Esto documenta algo que existe, o algo que queremos construir?

Prototipos para aprender

Esta entrada fue escrita originalmente en italiano por Paolo Gambardella. Ha sido traducida por un agente de inteligencia artificial y puede contener imprecisiones.

Los prototipos son uno de los campos en los que el game design ha evolucionado muchísimo en los últimos meses. Los nuevos algoritmos de machine learning y automatización permiten a todo el mundo ser mucho más rápido a la hora de desarrollar artefactos que necesitamos para aprender y para que nuestro equipo aprenda. Esto es un gran avance, pero puede agudizar una tendencia que he visto en algunos equipos: crear un prototipo demasiado sofisticado que acaba convirtiéndose en una demo.

El prototipo sirve para aprender, para responder preguntas. Una demo sirve para convencer, para conseguir el greenlight, para vender. El problema surge cuando creas un prototipo tan pulido que parece convincente, pero tan ambiguo que no puedes decir que estabas aprendiendo nada. Al final no aprendes nada y no convences a nadie.

Pongo un ejemplo práctico. Si es la primera vez que lees esto, debes saber que soy consultor de game design especializado en ideación y preproducción de nuevos videojuegos, sobre todo free-to-play. Tengo un pequeño estudio y la semana pasada, junto con mis colaboradores, creamos este prototipo usando Godot:

  • El proyecto arrancó el lunes con una visión que llevo tiempo madurando y que plasmé en un documento de visión
  • Mi ayudante Eduard investigó otros juegos y el miércoles me entregó un concept document
  • El jueves le pasé ese documento a Claude Code y le pedí que me generara un prototipo base
  • Del viernes al domingo fui haciendo pequeños ajustes según las ideas que me iban surgiendo mientras me dedicaba a otras cosas.

Después de entregarle el resultado a mi ayudante, lo estuvo probando durante un día entero y me dio su punto de vista. La conversación derivó mucho hacia problemas del tipo “el track generado es monótono” o “no consigues chocar con los coches”. Todo eso tiene sentido a partir de la demo, pero no en esta fase. Entre los dos, discutiendo, conseguimos identificar el aprendizaje real, qué es lo que nos gusta de este prototipo. Lo dejamos apartado, lo documentamos y pasamos a la siguiente fase de aprendizaje.

Si no hubiéramos sido dos, si hubiéramos estado en una empresa más grande, probablemente también habríamos tenido que preparar una presentación con los learnings para alinear al equipo. Así es como a mí me gusta trabajar, pero os digo una cosa: la tentación de querer resolver los problemas técnicos o mejorar las “inteligencias” artificiales de los rivales virtuales fue muy grande. ¿Por qué? Porque ahora es fácil, es rápido.

Tú puedes hacerlo, pero tu competidor también. Para mí gana quien se centra en las cosas correctas en el momento adecuado. Hoy más que nunca hace falta criterio. Un contacto mío me comentó que en la App Store los tiempos de aprobación se están alargando muchísimo debido a la cantidad de apps “vibe-coded” que les están llegando a los moderadores. Si vamos a esperar más para nuestras aprobaciones, al menos que sea por algo que realmente merezca la pena.

Una buena época para el diseño de juegos

Esta entrada fue escrita originalmente en italiano por Paolo Gambardella. Ha sido traducida por un agente de inteligencia artificial y puede contener imprecisiones.

Durante los años del boom del free-to-play en móviles, esta parte de la industria del videojuego fue rápidamente dominada por el product management. En cierto modo se entiende, dado que el negocio del free-to-play gira en torno a la adquisición de jugadores, es decir, el performance marketing. Si el coste de adquirir un jugador es inferior a lo que ese jugador invierte de media en el propio juego, tienes un negocio que funciona.

Así, trabajar como game designer en esas empresas se convertía muy a menudo en una conversación basada puramente en datos. Yo mismo me encontré en más de una ocasión discutiendo con mis jefes sobre cuestiones que podríamos resumir como: mi criterio VS la realidad actual del mercado. Pongo un ejemplo concreto: si yo, como diseñador, consideraba que cierta fantasía tenía que expresarse mediante mecánicas específicas porque tenía el presentimiento de que funcionaría, la respuesta habitual era: “de acuerdo, ¿y dónde has visto eso? ¿En qué otros juegos?” Muy a menudo era algo que venía más bien de una experiencia personal, o de otra cosa. Quizás una aplicación, una película o una exposición que había visitado me daba una idea. Nada, tenía que encontrar sí o sí la manera de explicarlo con datos.

Y en efecto, los diseñadores que luego han hecho más carrera en ese sector muy a menudo se autodefinen como data-driven. Son capaces de investigar lo que ya existe en los juegos de éxito y reaplicarlo como una fórmula matemática al juego en el que trabajan. Todo el respeto — es una buena habilidad. Pero para mí un diseñador debe tener tanto un sentido del contexto de negocio como buen gusto. Porque, ya que estamos poniendo tanta energía, bien vale la pena crear algo nuevo, poner algo de uno mismo. A la gente le gusta cuando tienes algo que decir.

Creo que este es nuestro momento, ahora. El momento de los diseñadores que quieren expresar su propio criterio. En mi opinión, el diseño puramente basado en datos ha muerto. En realidad siempre fue un trabajo repetitivo y poco creativo, pero creo que en la era de la IA — donde un agente hace todo eso en mucho menos tiempo y a una fracción del coste — es mejor cultivar nuestro propio gusto. Mejor ver películas, estudiar otro tipo de aplicaciones, ir a exposiciones. Mejor, en definitiva, buscar de verdad nuestra propia voz.

Lo que creo, y en lo que siempre he creído, es en el diseño informado por datos. Todo diseñador que se precie debe intentar siempre empatizar con los jugadores, y no hay mejor manera de hacerlo que recopilando datos. Pero esto no debe condicionar nuestro gusto, o siempre estaremos ofreciendo caballos a quien necesita algo nuevo — como vender carruajes en tiempos de Henry Ford. Un diseñador no puede ir a ciegas.

Pero un game designer debe tener la posibilidad de crear, de aportar algo nuevo al mundo. Es absurdo contratar a personas para que repitan fórmulas, y creo que eso está condenado a desaparecer, porque ahora tenemos el algoritmo adecuado. Un algoritmo que nos permite concentrarnos en lo que realmente importa.

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

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

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

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

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.