🕹️ Desarrollador indie (solo dev)
Lo haces todo tú: código, arte, sonido, diseño, tienda y comunidad. La habilidad
que más te va a costar no es ninguna de esas. Es terminar.
Nivel de entrada: inicial · Foco: alcance y ejecución · Hito faro: un juego publicado y a la venta
🧭 Qué es y por qué importa
El desarrollador indie en solitario asume todos los roles de un estudio pequeño. No es un rol técnico: es un rol de decisiones. Cada hora que dedicas a un sistema de partículas propio es una hora que no dedicas a la página de tienda, y la página de tienda vende más copias que el sistema de partículas.
Importa porque es la vía por la que más gente entra de verdad al oficio. No hace falta que nadie te contrate, y un juego publicado es el mejor currículum que existe. También es la vía con más abandono: la enorme mayoría de proyectos indie no llega a publicarse, y casi nunca por falta de talento técnico.
Seamos claros: vivir de esto es difícil y la mediana de ingresos de un juego indie en Steam es baja. Se hace por querer hacerlo, con expectativas realistas y, casi siempre, empezando en paralelo a otro trabajo.
🗓️ Un día en el puesto
No hay jefe, así que el día lo estructuras tú — y esa es la trampa.
- Decidir qué NO se hace hoy. La lista de ideas crece más rápido que la de tareas hechas. Sin una columna «no incluye», el proyecto no termina.
- Producir: la tarea concreta del día, sea código, un tileset o mezclar un sonido.
- Cambiar de sombrero. Programar por la mañana y dibujar por la tarde tiene un coste de contexto real; agrupar tareas parecidas ayuda mucho.
- Jugar tu propio juego con ojos de jugador, no de autor. Es lo más difícil y lo más necesario.
- Enseñarlo. Una captura, un GIF, una devlog. La comunidad no aparece el día del lanzamiento.
- Tareas nada glamurosas: presupuesto, impuestos, la ficha de la tienda, las capturas, el tráiler. Se posponen y son las que deciden las ventas.
🧠 Qué necesitas saber
Conocimiento técnico
- Lo suficiente de programación de gameplay para construir tu juego y no más: motor, control, colisiones, guardado (Partes 0 y 1).
- Game design de verdad, no intuición: bucles de juego, economía, curvas de dificultad (Parte 8).
- Arte funcional. No hace falta ser buen artista: hace falta ser coherente y saber qué puedes producir en tu tiempo (Parte 9).
- Audio básico y UI usable, que es donde más barato se gana calidad percibida (Partes 6 y 10).
- Publicación: exportar, firmar, subir, describir y precio (Parte 16).
- Automatización mínima para no ahogarte: builds de un comando, copias de seguridad, versiones (Parte 15).
Herramientas del oficio
- Godot 4 (gratis, ligero, sin royalties) y Git + LFS desde el primer día.
- Aseprite o Krita para 2D; Blender si vas a 3D.
- Audacity o Reaper para sonido; Tiled para mapas si el motor no te basta.
- Una hoja de cálculo. El arma más subestimada del indie: balance, presupuesto y planificación viven ahí.
Habilidades no técnicas
- Control de alcance. La habilidad número uno, sin discusión. Todo lo demás se aprende; esto se practica.
- Constancia sin jefe. Dos horas al día durante un año superan a diez fines de semana heroicos.
- Comunicar tu juego. Un buen GIF vale más que un buen sistema de partículas.
- Encajar el silencio. Publicarás y no pasará casi nada. Es lo normal, y no significa que sea malo.
📚 Tu ruta en el programa
- 📚 Parte 0 (001–025) y 📚 Parte 1 (026–045), con el 🧪 lab de plataformas 2D.
- 📚 Parte 8 — Game design (156–171). Lo que hace que tu juego sea divertido, que no sale solo.
- 📚 Parte 9 — Arte (172–187). Lo justo para tener un juego coherente.
- 📚 Parte 6 — Audio (126–137) y 📚 Parte 10 — UI/UX (188–199).
- 📚 Parte 15 — Tooling (255–266). Automatiza para no ahogarte.
- 📚 Parte 16 — Producción y publicación (267–280). No te la saltes: aquí se vende.
- 🎯 Hito: juego publicado en itch.io o Steam · 📚 Parte 17 — Capstone y portfolio.
➡️ Cuando ya hayas publicado y el problema pase de «terminar» a «que aguante», continúa en Indie avanzado.
🎓 Qué te contrata (o te vende)
Aquí no te contrata nadie: te compra el jugador. Lo que importa cambia:
- Un juego publicado, por pequeño que sea. Es la línea que separa a quien hace juegos de quien quiere hacerlos.
- Una página de tienda decente: cápsula legible, tráiler de 45 segundos, cinco capturas que se entiendan en miniatura.
- Un devlog o presencia pública. El juego que nadie ha visto antes de salir, sale y no lo ve nadie.
- Y si en algún momento buscas empleo, ese mismo juego vale como portfolio en cualquiera de las otras rutas.
📈 Progresión y dinero
No hay escalafón; hay tamaños de proyecto:
- Jams y juegos de un mes. Terminar cinco cosas pequeñas enseña más que no terminar una grande.
- Un juego comercial pequeño (3–8 meses), publicado y con precio.
- Un proyecto de 1–2 años, idealmente ya con algo de comunidad y quizá financiación o publisher.
- Micro-estudio: contratas o colaboras, y pasas a coordinar tanto como a producir.
Realidad económica, sin adornos: la mediana de ingresos de un juego indie en Steam ronda unos pocos miles de dólares de por vida, y la distribución está brutalmente sesgada hacia arriba. Los ingresos dependen más del hueco de mercado, la presentación y la comunidad que de la calidad técnica. Planifica con la hipótesis de que tu primer juego no te dará de comer, y trátalo como lo que es: una inversión en aprendizaje y reputación.
⚠️ Mitos y errores comunes
- «Mi primer juego será un RPG grande.» No lo será. Será un proyecto abandonado. Empieza por algo que termines en un mes.
- «Cuando esté acabado empiezo a promocionar.» Demasiado tarde. La wishlist se construye durante el desarrollo.
- «Necesito assets propios para todo.» No. Los assets comprados o CC0 bien elegidos son una decisión profesional, no una trampa.
- «Los gráficos venden.» Vende la legibilidad de la propuesta en un GIF de tres segundos.
- «Si es bueno se venderá solo.» Steam publica decenas de juegos al día. Nada se vende solo.
- «Hacerlo todo yo es más rápido.» En algunas áreas sí; en música y en el tráiler casi nunca. Saber cuándo delegar es parte del oficio.
🚀 Siguientes pasos
- Elige un juego que puedas terminar en un mes, y escribe su columna «no incluye» antes de escribir código.
- Haz la Parte 1 con el 🧪 lab de plataformas 2D y conviértelo en tu juego, no en el del curso.
- Publícalo en itch.io aunque te dé vergüenza. La primera publicación es la más difícil y la que más enseña.
- Haz la Parte 16 entera antes de empezar tu segundo juego, no después.
- Abre un devlog público desde la semana uno del siguiente proyecto.
- Repite. La segunda vez terminarás antes y mejor: ese es todo el truco.