Los últimos pasos antes de publicar un juego en Steam
El día del lanzamiento es la parte más pequeña de terminar un juego. El trabajo de verdad es cerrar el contenido, añadir una última función que encaje, ordenar los errores por gravedad, repetir el QA después de cada arreglo, preparar la build final y, por fin, soltarlo.
Publicado el 2026-07-05 · Game design
Cerrar el contenido significa que el juego deja de crecer
El cierre de contenido es el momento en que aceptas que el juego no va a ganar nada más. Ni más mecánicas, ni puzles, ni sistemas, ni cinemáticas. Cada hora que queda va a mejorar lo que ya está hecho.
La regla es fácil de decir y difícil de mantener. Una idea sin terminar siempre parece la pieza que haría que todo encajara, y una esquina a medio pulir es una invitación abierta a inventar un sistema nuevo en lugar de arreglar el viejo.
Por qué una última función todavía puede ganarse su sitio
Una incorporación sobrevivió al cierre de contenido: un modo de comentarios del desarrollador. Portal y Left 4 Dead popularizaron el formato, repartiendo pequeños nodos de audio por los niveles para que el equipo explique cómo se montó una mecánica, una prueba o un puzle.
La regla es fácil de enunciar y difícil de mantener. Una idea sin terminar siempre parece la pieza que haría que todo encajara, y una esquina sin pulir es una invitación abierta a inventar un sistema nuevo en lugar de reparar el viejo.
Así que el juego de imanes salió con los comentarios desbloqueados tras los créditos. Termínalo una vez, vuelve a jugar y puedes acercarte a pequeños nodos con altavoz para oír notas breves sobre cómo se construyó cada parte.
Cazar errores es la última pieza de trabajo de verdad
Con la lista de funciones cerrada, encontrar errores se convirtió en todo el proyecto. Un grupo pequeño de testers jugó el juego de principio a fin con una sola instrucción: informar de todo, por pequeño que parezca.
Los comentarios son útiles porque muestran el diseño como oficio y no como magia. Los tutoriales se construyen a propósito. La distribución de los niveles dirige adónde mira quien juega. El playtesting reescribe cosas que parecían cerradas.
Con tantos informes, había que priorizar sí o sí. Todo fue a una hoja de cálculo con una puntuación de gravedad del uno al cinco, donde el uno eran fallos visuales inofensivos y el cinco cualquier cosa que rompiera el juego del todo.
Ordenarlos es lo que hizo soportable el montón. Los peores problemas recibieron atención primero, mientras quedaba energía y antes de que "seguramente irá bien" empezara a sonar razonable.
Cada arreglo hay que volver a probarlo
Un arreglo no es prueba de buena salud. Algunos errores llevaron minutos; otros, días para reproducirlos, entenderlos y repararlos. Los peores eran los que parecían resueltos hasta que la presión reaparecía en otra parte del juego.
Por eso el final de un proyecto necesita rondas repetidas de QA en lugar de una sola pasada. No compruebas que un error ha desaparecido, compruebas que la build entera sigue aguantando, y eso solo lo sabes jugándola.
Tras semanas, los informes se fueron espaciando. O los testers habían pillado los problemas graves, o nadie encontraba ya una forma nueva de romperlo. En cualquier caso, el proyecto se había ganado el derecho a preparar una build final.
Ordenarlos por prioridad es lo que hizo sobrevivible el montón. Los peores problemas recibieron atención primero, mientras aún quedaba energía y antes de que «seguramente irá bien» empezara a sonar razonable.
La logística del lanzamiento llega toda de golpe
Subir la build final por Steamworks es el momento en que el juego se convierte en un objeto. Es una tarea aburrida y rara a la vez: años de prototipos, demos, comentarios y reescrituras comprimidos en un paquete detrás de un botón.
Por eso el final de un proyecto necesita rondas de QA repetidas en lugar de una sola pasada. No estás comprobando que un bug ha desaparecido; estás comprobando que la build en conjunto sigue aguantando, y eso solo lo sabes jugándola.
Lo extraño es el silencio. Las críticas, las entrevistas y los reportajes pueden estar escritos y programados, pero todavía no son públicos. El juego está lo bastante terminado para venderse, y el veredicto sobre él todavía no existe.
Pulsar publicar cierra un ciclo de tres años
Publicar cambia lo que es el proyecto. Deja de ser un problema privado por resolver y se convierte en algo que desconocidos pueden comprar, jugar, terminar, recomendar, criticar o pasar de largo.
El papeleo también llega aquí. Hay que generar claves para amigos, familia, reseñistas, entrevistadores y contactos de prensa, y la página de la tienda, las builds, los depots y los ajustes de la plataforma tienen que cuadrar entre sí.
Lo raro es el silencio. Las reseñas, las entrevistas y los reportajes pueden estar escritos y programados, pero todavía no son públicos. El juego está lo bastante terminado para venderse, y el veredicto sobre él aún no existe.
Los créditos muestran quién más construyó el juego
Publicar hace visible el apoyo que rodea un proyecto. Música, arte promocional, trabajo legal, ayuda con animaciones, sugerencias de nombre, ayuda con el código, herramientas y notas de pruebas acaban todas dentro de lo que se pone a la venta.
Las fuentes varían. Parte es trabajo especializado. Parte viene de amigos y familia. Parte viene de desconocidos dispuestos a grabarse tropezando con una build a medio hacer. Y parte es un solo consejo de alguien con experiencia, dado en el momento justo.
También se había negado a quedarse quieto. El foco de género se movió. El estilo artístico cambió. Las mecánicas se afilaron. Lo que salió no fue la idea original pulida durante tres años; fue el resultado de descubrir, una y otra vez, lo que el juego quería ser.
Lo que el día del lanzamiento enseña y lo que no
El lanzamiento no es donde llegan las lecciones. Prepara el análisis posterior: cómo se vendió el juego, cómo reaccionó la gente, qué aguantó, qué no y qué hacer distinto en el siguiente.
Aun así, el tramo previo al lanzamiento enseña algo por sí mismo. Terminar no parece un momento de inspiración. Parece una última función que encaja, una hoja de cálculo de errores ordenados, otra pasada de pruebas, una build final, un lote de claves, una lista de créditos y un botón que alguien tiene que pulsar.
Tras años sin saber, ese botón es lo que importa. Es donde el juego deja de vivir en la cabeza de quien lo desarrolla y empieza a existir como algo real que otras personas pueden coger.
Lo que el día del lanzamiento enseña y lo que no
El lanzamiento no es donde llegan las lecciones. Prepara el postmortem que viene después: cómo vendió el juego, cómo reaccionaron los jugadores, qué aguantó, qué no y qué hacer distinto en el siguiente.
El tramo previo al lanzamiento enseña algo por sí mismo, eso sí. Terminar no parece un momento de inspiración. Parece una última función que encaja, una hoja de cálculo de bugs ordenados por prioridad, otra pasada de pruebas, una build de lanzamiento, un lote de claves, una lista de créditos y un botón que alguien tiene que pulsar.
Después de años sin saber, ese botón es lo que importa. Es donde el juego deja de vivir en la cabeza del desarrollador y empieza a existir como algo real que otras personas pueden coger.
Build it in Flockbay
En la app de Flockbay, juega la build y escribe la lista de lo que no vas a añadir antes de enseñársela a nadie. Luego cambia solo lo que esa partida dejó al descubierto. Si se te ocurre una mecánica nueva, apúntala para una versión posterior y no la construyas esta noche.
The page on making a Steam game is about the destination. A start-here template is small enough to lock.
Descarga Flockbay
El último tramo de un proyecto es donde chocan el control del alcance, las pruebas y saber cuándo parar.