Cómo es publicar un juego en Steam
Un repaso honesto de un lanzamiento en Steam: qué se vendió, qué se llevaron las comisiones, qué errores se arreglaron, qué dijeron las reseñas y qué errores de producción costaron más.
Publicado el 2026-06-30 · Game design
Por qué estas cifras de lanzamiento necesitan una advertencia
Un informe de lanzamiento solo es tan útil como la situación de la que sale, y este sale de una situación poco habitual. Un desarrollador con seguidores ya establecidos, una comunidad esperando, acceso fácil a gente para probar y una visibilidad que casi nadie tiene la primera vez no es un caso típico.
Desarrollar a la vista puede enseñar mucho por el camino. Aprender un motor, montar prototipos, hacer sesiones de opinión. Pelearse con problemas de diseño, contratar ayuda, publicar en Steam y luego mantener el juego cuando ya ha salido.
Pulsar publicar es donde el trabajo vuelve a empezar
El botón de publicar no termina el proyecto; empieza otro. El juego salió a las 5 de la tarde, y el primer reflejo fue mirar cómo el contador de jugadores simultáneos subía de una docena a cincuenta, luego a cien, luego a doscientos, y volvía a bajar.
Los jugadores simultáneos no son ventas. El contador solo dice cuánta gente está en el juego en ese momento. El panel de Steam, en cambio, informa de las ventas casi en tiempo real, y esa lectura convirtió el resto de la tarde en un borrón.
Nada de eso hace que las cifras no valgan nada. Significa que vienen con contexto. Cuando un pequeño plataformas de puzles 2D vende bien casi sin marketing externo, parte de ese resultado se debe a la confianza y la atención previas, no solo al juego.
Cuántas listas de deseados se convirtieron en compras
La conversión fue fuerte: unas 5.000 copias vendidas al final del día de lanzamiento, frente a 50.000 listas de deseados. Más o menos un comprador por cada diez personas que lo habían guardado.
A los siete días, el total rondaba las 10.000 copias, cerca del 20 % de las listas de deseados. Unas semanas después del lanzamiento, la cuenta estaba en 12.446 unidades.
Para un primer juego comercial pequeño, son resultados excelentes. También son resultados atípicos, y justo por eso la advertencia sobre el público sigue importando. Un lanzamiento puede ser bueno de verdad y aun así ser una mala referencia para un desarrollador al que nadie conoce.
Adónde va de verdad el dinero en Steam
Unidades por precio no es lo que se queda el desarrollador. Los ingresos de Steam pasan por varias fases antes de convertirse en dinero propio.
Empieza con 100 unidades de ingresos brutos. Los impuestos sobre las ventas, el procesamiento de pagos, las devoluciones de cargos y los reembolsos se llevan una parte de inmediato, que aquí fue de alrededor del 10 %.
Luego Valve se lleva su parte como plataforma, en torno al 30 % de lo que queda. Después vienen los costes de producción: colaboradores, banda sonora, arte promocional, recursos, herramientas y todo lo demás que necesitó el juego. Luego el impuesto sobre la renta. En ese modelo simple de 100 unidades, sobrevivieron unas 43 hasta el final.
Pon el precio pensando en los costes invisibles
El precio hay que planificarlo contra el dinero que nunca ves, no contra el dinero de la página de la tienda. La parte que quedó seguía siendo significativa, así que la cuestión no es que un buen lanzamiento no dé nada.
La cuestión es que un precio visible y una cifra de ventas visible describen casi nada del negocio. Los reembolsos, las comisiones de la plataforma, los impuestos, los colaboradores, las herramientas y el trabajo de localización o de cumplimiento normativo mueven el resultado real, y hay que contar desde el principio con un descuento de lanzamiento y las rebajas de temporada que vienen después.
Haz esa cuenta antes de decidir que una cifra de ventas llamativa cubrirá meses de gastos, el siguiente proyecto y unas vacaciones para celebrarlo.
El día del lanzamiento es la pasada de QA de verdad
Nada en un periodo de pruebas privado iguala la cobertura de un lanzamiento público. Llegan miles de personas a la vez con distintos ordenadores, mandos, sistemas operativos, estilos de juego y expectativas, y los informes empiezan a llegar en cuestión de horas.
Nada catastrófico se rompió para el conjunto de jugadores, pero la lista fue larga. Los logros fallaban en la versión de Mac. Unos veinte niveles tenían problemas, sobre todo soluciones tramposas, soluciones no previstas o pequeños errores de distribución. Un nivel se rediseñó por completo porque al volver a mirarlo apareció un puzle mejor debajo.
La detección de los iconos del mando también fallaba, así que se añadió un ajuste explícito para que cada cual eligiera qué avisos de botón veía. Una actualización posterior cambió la selección de mundos por una pantalla de selección de niveles al terminar el juego, para poder repetir cualquier nivel directamente.
Cuándo es mejor dejar un error en paz
Algunos errores merece la pena conservarlos, y la pregunta que decide es a quién pertenecen. Los speedrunners ya habían construido técnicas sobre varias rarezas de la física y trucos de movimiento.
No se rompió nada catastrófico en la base de jugadores, pero la lista era bastante larga. Los logros fallaban en el build de Mac. Unos veinte niveles tenían problemas, sobre todo cheese, soluciones no previstas o pequeños errores de distribución. Un nivel se rediseñó por completo porque, al mirarlo otra vez, apareció un puzle mejor debajo.
Las herramientas de ramas de Steam también ayudaron. Mantener disponible la build original del lanzamiento sirve a los speedrunners y conserva un registro de lo que salió exactamente el primer día.
A qué respondían las reseñas positivas
Las reseñas se asentaron en torno al 88 % positivas en unas 700, y los elogios se concentraron en lo fundamental. Era divertido, varios puzles producían un momento eureka de verdad y los controles se sentían bien.
Los jugadores normales nunca se los encontrarían, pero los speedrunners expertos los usaban para moverse más rápido, saltar más alto, saltarse puzles y secciones enteras. Parchearlos habría dejado el build más ordenado en un sentido técnico estrecho, a costa de hacer menos interesante el juego de una pequeña comunidad.
Elogios así merece la pena leerlos porque confirman el lado de quien juega. Un diseñador ve cada concesión; la gente responde al conjunto de una vez: la sensación, la claridad, la presentación, el ritmo, la música y si el puzle acaba encajando.
La duración y el precio recibieron las quejas más ruidosas
La duración fue la crítica más común. El juego duraba unas dos horas. Alguna gente quería más, y otra sentía que el precio no encajaba con la duración.
El pulido, la presentación, el diseño de sonido y la banda sonora hicieron mucho para que el proyecto se leyera como un juego comercial terminado y no como un build de aficionado. Un público ya existente probablemente ayudó a esa nota, y unas pocas personas decididas a que no les gustara el proyecto empujaron en sentido contrario.
Los juegos cortos están bien. Solo necesitan un precio pensado, unas expectativas honestas, un descuento de lanzamiento y margen para rebajas posteriores. El valor es subjetivo, así que las quejas sobre duración y precio merecen escucharse en serio sin tratarlas como una acusación de mala fe.
La dificultad y el ir a lo seguro fueron críticas justas
Dos críticas cayeron sobre el propio diseño: el juego era demasiado fácil y demasiado seguro. Ninguna fue una sorpresa. Construir un juego de puzles que funcione para un público amplio tira en contra de construir uno que ponga a prueba a quien vive para los puzles.
Una dificultad accesible tiene valor real. Un juego que mucha gente puede terminar de verdad, incluidos los más jóvenes y los más casuales, ha conseguido algo real. Aun así hay un coste cuando quien tiene experiencia nunca encuentra el contenido opcional más difícil que venía a buscar.
La segunda queja, sencillo, seguro, poco imaginativo, escuece más, y también puede ser acertada. Un primer lanzamiento comercial puede estar pulido y completo sin ser personalmente expresivo, estructuralmente novedoso ni memorable.
Publicar un juego cuyos defectos ya conoces
Lo más difícil del lanzamiento es estar de acuerdo con buena parte de las reseñas negativas antes de que se escriban. El desarrollador puede saber ya que el juego es corto, seguro, fácil y menos inventivo de lo que podría haber sido.
Lanzar significa entregar esa cosa imperfecta de todos modos. La gente la compra, la juega, la reseña, la devuelve, la elogia, la critica y la compara con el juego que el desarrollador tenía en la cabeza.
Es incómodo, y también es lo que se siente al terminar. Un juego no tiene que ser el mejor de la historia para merecer existir. A veces existir es el logro.
Lo que funcionó: construir primero las herramientas de niveles
Las herramientas internas fueron el acierto más claro. Todo lo que nunca aparece en el juego publicado pero hace más rápido construirlo suele devolver su coste varias veces.
Las mecánicas se podían arrastrar a una escena, ajustar a una cuadrícula y afinar con deslizadores y casillas. En la segunda mitad del desarrollo, montar y ajustar un nivel se había vuelto rápido, y rápido significaba que pasaba más a menudo.
Las herramientas no salieron gratis. Para un juego hecho de muchos niveles seguían siendo la inversión correcta, porque bajaron casi a cero el coste de cambiar un nivel.
Lo que funcionó: la sensación, las pruebas y la accesibilidad
Otras tres cosas compensaron: el pulido, las pruebas con jugadores y el trabajo de accesibilidad hecho pronto. La animación, los efectos de sonido, el juice, las transiciones y la sensación de juego en general pueden llevar un diseño modesto más lejos de lo que merece, porque cada interacción se vuelve más satisfactoria.
Las pruebas importaron todavía más. Casi todas las partes del juego mejoraron cuando otras personas las tocaron, y amigos, familia, desconocidos, eventos y pruebas públicas sacaron cada uno problemas invisibles desde dentro. La forma más rápida de juzgar cualquier cosa era poner una build en marcha y dársela a alguien.
La accesibilidad salió más barata por haberse construido a medida que aparecían las funciones y no pegado al final. El soporte para daltonismo, los controles reasignables, el soporte de teclado y ratón y de mando y una opción de fondo simplificado se mantuvieron manejables así.
Pistas que mantienen a quien juega dentro del juego
Un sistema de pistas funciona cuando devuelve el impulso sin gastar el momento eureka. Los buenos hacen pensar "espera, ahora lo veo" en lugar de imprimir la respuesta sin más.
En un juego de puzles esa distinción es todo el diseño. El trabajo es mantener a la gente en el juego y no en una pestaña del navegador buscando una guía, o atascada contra un muro hasta que lo deja.
También se podía saltar un nivel tras llevar unos minutos atascado. Eso protegía la forma de la experiencia: cualquier puzle podía ser difícil, pero ningún puzle podía terminar el juego.
Lo que falló: salir demasiado pronto de la preproducción
El error más caro fue salir con prisas de la preproducción. La preproducción es donde se resuelven las grandes preguntas: qué es el juego, qué hace quien juega, cómo es un nivel, cuál es el bucle central, cómo funciona el arte y cómo se estructura todo.
En un juego de puzles, esa distinción es todo el diseño. El trabajo consiste en mantener a los jugadores dentro del juego y no en una pestaña del navegador buscando una guía, o atascados contra un muro hasta que lo dejan.
Empieza la producción antes de tener esas respuestas y cada cambio cuesta dinero de verdad. El arte se rehace tarde porque la distancia de cámara nunca se decidió. La estructura de niveles se va a la deriva. Se tira trabajo porque una decisión de base se aplazó en lugar de tomarse.
Lo que falló: ningún plan para el juego terminado
El proyecto también funcionó sin una hoja de ruta real para el juego completo. Una imagen mental aproximada de lo terminado no es un plan de producción.
En esa fase las ideas son baratas. Un prototipo se puede tirar sin remordimientos, se pueden probar diez respuestas en el tiempo que lleva una funcionalidad terminada, y nada se ha vuelto caro todavía.
Ese trabajo es poco vistoso y decide si un proyecto llega a buen puerto. Incluso en solitario, un desarrollador necesita hitos, control del alcance y alguna forma de saber si el juego converge o solo acumula funciones.
Lo que falló: pulir las partes que nadie nota
Una cantidad considerable de tiempo de desarrollo se fue en detalles que no podían devolverlo. Un resaltado de menú que se comporta sin fallos con ratón y con mando está bien, pero un día entero dedicado a él es un día no dedicado a los puzles, los controles o la sensación de juego.
El avance hacia un final real solo empezó cuando las respuestas fueron concretas: cuántos mundos, cuántos niveles, qué momentos de la historia, qué quedaba por construir y qué se iba a recortar.
La reacción al lanzamiento dejó clara la prioridad. La gente recuerda si el juego central es interesante, legible y satisfactorio. No recuerda los casos límite de la interfaz.
Los juegos de plataformas y puzles esconden mucha dificultad
Un juego de plataformas y puzles en 2D parece un primer proyecto sensato y pide en silencio varios oficios distintos. Las plataformas necesitan un movimiento que responda, animación, controles y un buen sentido del espacio.
El diseño de puzles es una disciplina propia. Los buenos diseñadores de puzles pasan años aprendiendo a presentar una mecánica, explorar sus consecuencias, esconder una solución, provocar un momento eureka y evitar una ejecución tediosa. Hacer eso mientras construyes todas las demás partes del juego es muchísimo.
La física sube aún más la dificultad. Los puzles quieren control y legibilidad; la física aporta imprevisibilidad, casos límite y soluciones caóticas que el diseñador tiene que aceptar a propósito o vallar.
El intercambio que haces al trabajar en solitario
Desarrollar en solitario compra control creativo total, un calendario flexible y la satisfacción de haber tocado cada parte del juego. También reparte las habilidades limitadas de una persona entre arte, animación, sonido, programación, escritura, diseño de niveles, producción, marketing, accesibilidad, QA y soporte.
El diseño de puzles es una disciplina en sí misma. Los buenos diseñadores de puzles pasan años aprendiendo a introducir una mecánica, explorar sus consecuencias, esconder una solución, provocar un momento eureka y evitar una ejecución tediosa. Hacer eso mientras construyes también todas las demás partes del juego es una carga enorme.
Delegar más probablemente habría producido un juego mejor, antes, y unos años menos personales y menos disfrutados. La lección no es evitar trabajar en solitario. Es elegir a propósito qué partes siguen siendo tuyas y cuáles piden ayuda.
Un juego terminado es el resultado que cuenta
La medida honesta del proyecto es que se terminó y se publicó. Si vendrá algo más, game jams, pequeños experimentos interactivos, otro lanzamiento comercial, está sin decidir, y no cambia lo que ya pasó.
Alguien cuyo único trabajo es la música le presta toda su atención a la música. Un desarrollador en solitario casi nunca le da tanto a una sola disciplina, porque todos los problemas de la lista son suyos.
Los defectos, las oportunidades perdidas, los errores y las concesiones vinieron con él. El juego sigue siendo real, y para un primer gran lanzamiento eso no es poca cosa.
Un juego terminado es el resultado que cuenta
La medida honesta del proyecto es que se terminó y se publicó. Si vendrá algo más (game jams, pequeños experimentos interactivos, otro lanzamiento comercial) está sin decidir, y no cambia lo que ya ocurrió.
El juego pasó de idea a lanzamiento. Miles de personas lo jugaron. La mayoría se lo quedó. Ganó un dinero significativo. Recibió críticas que valía la pena atender y elogios que valía la pena creerse.
Los defectos, las oportunidades perdidas, los bugs y las concesiones vinieron con él. El juego sigue siendo real, y para un primer lanzamiento importante eso no es poca cosa.
Build it in Flockbay
En la app de Flockbay, juega tu build durante un minuto como si nunca hubieras oído el pitch, y apunta la primera confusión. Esa confusión es el lanzamiento. Arréglala antes de imaginarte una multitud. Una multitud que no tienes no te la va a explicar.
La página sobre cómo hacer un juego para Steam es el destino. Una plantilla para empezar es lo bastante pequeña como para que el primer minuto lo sea todo.
Descarga Flockbay
Un lanzamiento somete tu diseño, tu producción, tu precio, tu soporte y las expectativas de quien juega a una misma prueba muy pública a la vez.