Coincido de lleno con AxelStone.
Saludos. Soy Rod Mérida, el que ha hecho la música del juego y la programación del motor de Retro Wars, no de esta versión, sino de una versión experimental que se prevé saldrá en breve, y no se pudo terminar aún. Si algo he aprendido durante el desarrollo de este juego, es que no se puede comparar casi con nada la cantidad ingente de carga de trabajo que tiene encima el programador a la hora de desarrollar un juego, cuando es programador único y tiene que desarrollar un motor adaptado a ese juego prácticamente de cero, en términos de la cantidad de tiempo, de varios meses incluso como mínimo, que hay que invertir para poder ver el juego más o menos planteado y presentable. Y así y con todo todavía habrá que pulirlo de varios bugs, y errores hasta hacer que quede como un juego decente y bien elaborado, eso si el juego es mínimamente ambiocoso.
Pondré un ejemplo y hablo por mí. Además de estar en la programación del motor de este juego, he tenido la suerte de hacer las veces también de compositor de la música. Pues bien, para esta primera versión del juego, la música, que ha sido una tarea bastante ardua de hacer, ha tardado en componerse y programarse entre 1 y 2 semanas, aproximadamente, día para arriba, día para abajo.
Pues bien, el motor propio de Retro Wars ha requerido más de cuatro meses. Cuatro meses que han ido planteando una serie de problemas añadidos a medida que se iban resolviendo los más básicos, de complejidad creciente, y así y con todo, aún tiene fallos y cosillas por ir puliendo; algún huevo de pascua por meter; alguna ruta o colisión por revisar, etc. Además, he tenido que aprender las características del dialecto de Basic empleado, cómo trabajar a partir de él con gráficos y del hardware del Amiga prácticamente de cero a medida que lo iba haciendo. ¿Qué es lo que pasa? Que como llegó la fecha del examen para mis oposiciones, me tuve que poner en cuerpo y alma a estudiar y tuve que dejar el tema de la programación en stand-by, y por ese motivo, tras reunirnos y hablar el equipo, llegamos a la conclusión de que urgía sacar una primera versión como fuera, para quitárnoslo de encima, y que Jojo y Kikems pudieran pasar a nuevos proyectos que ya tenían entre manos (también yo tengo algo planteado por ahí), y luego, si se quería, ya con más tiempo, yo podría ir elaborando una versión más ambiciosa con ese motor hecho de cero.
La solución fue clara: usar, para la primera versión un motor de aventura gráfica ya hecho, denominado Grac (como se especifica al comienzo del juego), y adaptar o reprogramar el tema de las variables, gestión y distribución de memoria, buscar formas de ahorrar para que cupiera en Amiga 500 y algunos aspectos técnicos añadidos, labor de la que se encargó Kikems, en un par de semanas, un tiempo prácticamente récord.
Así, de aquí surge que hay una primera versión inicial de Retro Wars con un motor genérico de aventura gráfica amiguera adaptado al desarrollo de la historia y características de Retro Wars.
Y hay planteada una segunda versión, que está aún en desarrollo, que ha estado en stand-by el último par de meses por motivos personales, como comenté, y que contará con un motor completamente reprogramado desde cero, diseñado y pensado específicamente para las necesidades y características concretas de Retro Wars desde un principio (y del que por cierto ya se ha ido viendo alguna demostración técnica a lo largo de los últimos meses en youtube). De hecho, lo de la existencia de estas dos versiones no es ningún secreto, lo hicimos público en un capítulo de AmigaWave el día que anunciamos el lanzamiento de la primera versión de Retro Wars. Es algo que se sabe ya.
Y bueno, que sí. Que el tema de coordinar a varias personas en el desarrollo de un juego suele ser delicado o complejizarse a medida que pasa el tiempo justo por ese tema que has planteado, AxelStone: que programar un juego desde cero, puede llegar a ser una tarea titánica, a poco vayan surgiendo y sumándose problemas técnicos como los que han surgido, y eso el que mejor lo sabe es el que tiene que comerse el majado. Por eso en muchos juegos hay más de un programador y por eso, creo como tú has dicho, totalmente necesario que la carga de trabajo del resto de miembros en temas de dibujo / diseño y guión sea proporcional a la carga del trabajo del programador, para que todos estén "a tope" y nadie tenga tiempo de aburrirse esperando a uno de los miembros, que es algo que exaspera, y debe frustrar al más pinta'o (sobre todo cuando hay presiones de fechas de lanzamiento o la gente está esperando que salga a la luz el producto).