Bueno, ya que la mayoría de los grupos estaréis empezando a pensar en el proyecto que vayáis a hacer, y ante las dudas de algunos grupos, voy a poneros una pequeña lista de consejos para dar estos primeros pasos con mayor seguridad. Obviamente, esto queda abierto para cualquiera del foro que quiera añadir o corregir cualquier cosa:
CONSEJOS DE PLANIFICACIÓN:
- El primer paso sería hacer una lista con todas las tareas que tendréis que completar para dejar perfectamente cerrado el juego. Al ser proyectos sencillos, no hace falta que lleguéis hasta niveles de detalle demasiado grandes; simplemente hacer una lista un poco por encima, pero intentando no dejarse nada sin listar... Seguro que os llevaréis una sorpresa cuando veais cuanto trabajo requiere la cosa más sencilla.
- Ordenar las tareas de la lista según el momento en que deben ser realizadas (por ejemplo, en un plataformas, necesitaréis los sprites de la animación del personaje antes de programar los movimientos del mismo).
- Una vez estén ordenadas, agrupadlas en conjuntos que os lleven más o menos una semana y repartirlas entre vosotros. De esta forma, cada semana habréis completado ciertas tareas y veréis avanzar el proyecto de forma constante. Además, así podréis estimar cuanto os va a llevar terminar el juego.
- A la hora de decidir cuanto tiempo os va a llevar cada tarea, yo lo haría con el mayor pesimismo posible; siempre os váis a dejar tareas sin listar y siempre os surgirán problemas inesperados... Si sois pesimistas, lo único que pasaría por equivocaros es que acabaríais el juego antes de tiempo.
CONSEJOS DE DISEÑO:
- Aún en el más sencillo de los proyectos, yo recomendaría la elaboración de un pequeño documento de diseño para que todos sepan exactamente como va a ser el juego desde el principio. No hay ninguna metodología estándar para hacerlo (como si la hay en el cine, por ejemplo), pero yo os diría que el documento está bien cuando se lo podáis dar a cualquier persona y que ésta entienda inmediatamente como va a ser el juego sin necesidad de explicaciones adicionales.
- No tratéis de ser excesivamente exhaustivos al realizar el documento de diseño. Es mejor una lista de características que un largo párrafo explicándolas y es mejor un pequeño conjunto de apartados cortos e independientes que un largo apartado que explique todo a la vez.
- Las características (o features) no se meten porque queden bonitos, ni porque las tengan otros juegos ni porque "queden bonitos". Cada detalle del juego, cada acción del personaje cada característica del control debe tener una justificación orientada a mejorar la sensación final de juego.
- Otra cosa extremadamente importante para el diseño de un juego, es tener en cuenta las posibilidades del equipo que lo va a realizar: Sois grupos de tres o cuatro personas que en muchos casos no tenéis gran experiencia. Por mucho que os esforcéis, tenéis un límite y os aconsejo no acercaros demasiado. Por favor, id poco a poco... Yo para empezar no elegiría un juego que me llevase más de cuatro, cinco o seis semanas; después podréis hacer algo más complejo, pero al menos ya sabréis que sois capaces de terminar algo.
- Todas las personas pensamos de forma muy parecida, y a todos se nos ocurren constantemente ideas para realizar el MMORPG definitivo el FPS de la historia. El gran problema es que una idea no vale nada, en serio. No vale nada. Lo realmente importante es la realización de esa idea; la forma de hacerla real y efectiva... Ahí es donde aparecen las dificultades y donde el talento de la gente sale a la luz. Por tanto, no pretendáis haceros los grandes genios por una idea; desarrollarla, hacerla real, y entonces sí habréis hecho algo importante.
Nada más, insisto en que esto queda abierto para que cualquiera añada o corrija cosas de estos consejos.[/list]
Muchas gracias por estos consejos, nos van a ser bastante utiles a todos seguramente.
Me sumo al post con algunas ideillas o pautas que seguimos por mi grupo y que tal vez puedan ser útiles a algunos o dar pie a más ideas de cara a la organización...
- Uso de una "intranet". La comunicación entre el grupo es importante.... en un principio nosotros tb nos comunicabamos mucho por email... pero esa forma no resulta nada efectiva. La info debe estar disponible siempre en un lugar para ser consultada y modificada. Se puede buscar un servicio de foros gratuitos y usar ese medio para debatir las ideas, colgar los avances del grupo... el log de cambios de los archivos.... Para subir archivos... se puede mirar algún server gratuito... siempre será más comodo bajar y subir los archivos tocados que andar enviando mails a diestro y siniestro con cada update o idea....
- Respecto a lo último, nosotros llevamos un fichero donde vamos apuntando la fecha, los cambios (y quién los ha hecho) de cada archivo modificado o creado. Así vemos los progresos que va llevando el proyecto y nos sirve como referencia para no machacar código ajeno a la hora de subir los cambios al servidor. (Igual parece algo chorra, pero al menos a nosotros si nos es útil saber cuándo ha sido modificado algo y qué para estar al loro de por donde se ha de seguir y cosas así). También apuntamos los cambios de "filosofía", quiero decir, cambios necesarios en la forma de hacer las cosas que se iban a hacer de una forma y por factores que se nos habían pasado hemos tenido que hacer de otra.. o añadir alguna cosilla no prevista... eso viene bien para saber cómo de refinado a sido el plan inicial e intentar mejorar ese paso en proyectos sucesivos...
- Llevar una documentación... aparte del documento de diseño, llevar una documentación sobre la filosofía seguida y demás. Se agradecerá un recordatorio de qué es lo que se hace en el programa si lo retomais pasado un tiempo para añadir mejoras y demás... o mismamente si alguien causa baja y otro se tiene que hacer cargo....
No se me ocurre nada más.... insistir en la idea de ese "foro interno"... de verdad que viene genial para coordinar... ;) :)
Totalmente de acuerdo con Sipox: como ya os dije a muchos por el messenger, tener un foro privado es algo fundamental; en Red Room empezamos a usarlo hace unos meses y desde entonces hemos ahorrado mucho tiempo en temas de comunicación.
Además, siguiendo en esa linea, también usamos un servidor de subversion (un servidor que almacena y gestiona todo el material del juego para que trabajemos siempre sobre la última versión) y el mantis para el tema de bugs. Aunque también entiendo que un grupo pequeño como es este caso puede resultar difícil montar un servidor de subversion.