Más consejos para colaboraciones y proyectos en grupo

Después de un merecido descanso vacacional y de charlar con los implicados en un par de proyectillos (pequeños) en los que ando metido ahora, para aclarar que debemos hacer para terminarlos, he ido dándole vueltas a algunos consejillos más que se me quedaron sin comentar sobre cómo trabajar mejor en equipo cuando se trata de colaboraciones, y es que aunque ya escribí un post llamado “Experiencia en fracasos: Consejos para terminar proyectos en grupo” con el tiempo he aprendido nuevas cosas (y también he fracasado en muchos más proyectos)

Colaboraciones

A veces no se puede hablar de un proyecto en grupo, sino simplemente de una petición de alguien que ha planteado un juego, necesita ayuda para una parte del mismo, y nos pide participar para resolverla. Por ejemplo un programador que necesita un grafista para los gráficos de su actual idea, que ha oído que nosotros dibujamos bien, y nos pide que nos ocupemos de lo visual.

Respetar el proyecto original: En estos casos es muy importante ir a lo que nos piden y no meternos excesivamente en el trabajo del creador. Cada uno tiene la imagen final de su juego en la cabeza (aunque sabemos que luego no quedará exactamente como lo imaginamos) y no conviene que tratemos de “insertar” la imagen que nosotros tenemos del juego en la cabeza del otro. No es malo hacer sugerencias, pero si nos gusta por ejemplo el estilo Manga pero la persona que nos pidió la colaboración ya tenía claro un estilo realista y no lo acepta, no es buena idea insistir por que empezaran las discusiones y todo puede acabar con el juego a medias (Aquí somo unos "mandados", no nos pasemos de creativos).

Conocer el trabajo del otro: Primero, en el sentido de informarnos bien de la seriedad y forma de trabajar de la persona que nos ha pedido ayuda, para saber que nos va a exigir y que vamos a obtener de él/ella. Por ejemplo si sabemos que es una persona que tiene prisa por acabar el proyecto y le dedica todo su tiempo, pero nosotros solo podemos colaborar a tiempo parcial en nuestros ratos libres, es mejor dejarlo claro o no hacer la colaboración, porque no podremos dar todo lo que se nos vaya exigir.

Segundo también es bueno, aunque no imprescindible, conocer por ejemplo, si somos grafistas, la forma en que trabaja un programador para ver que va a necesitar y poder proporcionárselo con rapidez. No hablo de saberlo todo pero ahorra tiempo si, por ejemplo, nos hemos mirado un poco tanto unos como otros que motor usaremos para el juego y como funciona, los formatos que maneja, etc. También tenemos que saber en qué dispositivo o dispositivos finales se va a ejecutar y que limitaciones nos va a imponer de tamaño de archivos, colores, resolución...

Archivos temporales: Para acelerar el proceso, ayuda tener archivos temporales de lo que va a ser el proyecto final, tanto en documentos de diseño, como gráficos o incluso versiones del código. Con archivos temporales me refiero a algo así como prototipos. Por ejemplo el programador hace una versión del juego con cuadraditos para calcular donde tiene que situar cada cosa y, cuando tenga los gráficos definitivos hechos por el grafista, solo tiene que sustituir los cuadraditos por dichos gráficos.

Esto es aplicable también a otras tareas como la música, escenarios, etc.

Proyectos en grupo

Normas: Establecer normas de cara al grupo es muy importante para que ninguno meta la pata. Por ejemplo suele ser buena idea advertir a la gente que no comente o publique información del proyecto hasta que no haya terminado para no recibir presiones o influencias externas al equipo. Igualmente resulta útil dejar claro que ocurrirá con el material creador por las personas que dejen el juego en mitad de desarrollo.

Jefes: Esto ya lo comenté en el otro post, pero es importante dejarlo claro. Si hay una persona todoterreno (que domine varios roles como desarrollador) es el ideal para llevar el liderazgo del equipo, ya que va a entender que tareas están haciendo los grafistas, va a poder elegir con los programadores que motor usar (o trabajar desde cero) o incluso asesorar y organizar a músicos, guionistas, betatesters… Por otro lado si la idea de juego la ha tenido otra persona distinta a este “diseñador nato” conviene que compartan esa tarea para que haya buena organización, pero el proyecto no se aparte demasiado de la idea inicial. Suele ser un poco difícil trabajar en estos casos por que, si por ejemplo la idea original viene de un guionista sin muchos conocimientos técnicos, no le va a gustar nada cualquier limitación impuesta por parte del equipo de desarrollo.

Preproducción: Muy importante dedicar un tiempo a organizarse y decidir cómo se va a trabajar y con qué objetivos. Al contrario de lo que pueda parecer, una buena planificación acelera el proceso de desarrollo y nos evita problemas como podrían ser: Que un modelador use un programa y formato diferentes a otro, que haya dos guiones distintos moviéndose entre los miembros del grupo o que no estén claras algunas partes del gameplay y los programadores acaben teniendo que rehacer código.

Reuniones: Tampoco es ninguna pérdida de tiempo reunirse de vez en cuando, a través del medio que sea, para discutir cómo va el desarrollo, posibles cambios, ideas, problemas, etc. Como en los equipos a distancia entra y sale gente constantemente es muy probable que haya que reasignar tareas cada poco tiempo. Es, además, un buen momento para plantearse recortes si el tiempo requerido para finalizar el juego se está alargando demasiado y parece no tener fin. Es mejor tener un juego con menos niveles, armas o vehículos pero terminado, que uno con 500 armas, 90 niveles y 70 vehículos diferentes pero al que no se puede jugar porque está incompleto.

Paso a paso: Desde que la descubrí siempre voy a recomendar esta forma de trabajo. ¿Para qué vamos a pensar en un juego de 70 niveles, con una historia larga y un montón de características definidas desde un principio si no sabemos si vamos a terminar el primer nivel? Lo mejor suele ser dividir los objetivos e ir cumpliéndolos poco a poco, es decir: Vamos a hacer un juego de un nivel, con muy pocos personajes y unas acciones base, cuando esté terminado, nos reunimos y vemos como está el ánimo para añadir un segundo nivel. Algo así como hacer un juego por capítulos con su historia y detalles cerrados e ir cumpliendo metas. Ya veremos si al terminar fuimos capaces de hacer un minijuego, un megaproyecto o tres pequeños pero diferentes.