Aravid

Tutoriales, Gamer Sense, opinión y más

Archivos en la Categoría: Documentación

Trabajo en grupo – Parte II

Continuando desde el artículo anterior de esta saga de Trabajo en grupo, toca hablar de las ventajas que tiene la realización de un proyecto en grupo. Algunas tiene, de verdad.

Y podría no parecer que las alegrías compensan a las penas de un trabajo así, porque en la primera parte, mi odio interior afloró, pero es que tratar con gente (what a bunch of bastards) no es fácil, y menos si en tu carrera, lo más parecido a un compañero de trabajo es cuadrado, te comunicas con él con teclado y ratón y lo puedes apagar si te molesta en exceso.

Uso de plataformas de trabajo colaborativo: No es una ventaja inherente al trabajo en grupo, porque se puede realizar un proyecto sin ellas, pero está bien que el grupo se obligue a utilizarlas. Muchas son las ventajas de estas herramientas, pero yo destacaría sobre las demás un control de versiones y un gestor de tareas, para saber en todo momento qué tareas tiene cada miembro del grupo asignadas y el tiempo que ha invertido en ellas (aunque en el momento de creación de la misma, se puede introducir una estimación del tiempo que consumirá). Esto servirá para más adelante estimar mejor los tiempos y poder realizar una planificación más exacta.

Reducción de tiempos de desarrollo: A más gente, más personas aporreando teclados, dibujando bocetos, modelando mallas y esas cosas que hacen falta para que un proyecto (un juego en este caso) se complete. Más manos no siempre significa ser más eficientes, porque dos personas no trabajan el doble, recordar que hay unos costes de comunicación asociados, que reducen la eficiencia del grupo, o puede que tu trabajo dependa de un trabajo previo de otra persona, por ejemplo.

Lo que para ti es un marrón irrealizable, para otro puede no serlo: Bajo este nombre tan estrambótico, reside la idea de que en un grupo, los conocimientos disponibles son siempre mayores que si uno trabaja solo, es por eso que si tienes que realizar algo que no sabes hacer, puede que alguien disponga de información útil que te ayude, o realizar un pequeño ajuste en la planificación para que esa tarea pueda realizarse con una inversión de tiempo menor y más eficazmente por otro.

Aprendizaje: Lo bueno de ser varios, es que, casi de forma transparente, se aprende de los otros miembros al igual que los otros miembros pueden aprender de ti. En un grupo, el conocimiento fluye y todos pueden aprovecharse de esto. Hay que tener cuidado porque hay personas que son muy recelosas de sus “descubrimientos” lo que hace que el conocimiento se detenga en seco y ese tiempo que ha dedicado en I+D para la finalización de esa tarea no se difunda al resto de miembros, lo que yo considero que es una pérdida.

Es como se trabaja: Nos guste o no, todos los proyectos del mundo real se hacen así. Esto no es una ventaja, pero sí una advertencia. Hay que cambiar el chip y aceptar que esto es nuestro futuro.

Estas son las ventajas que yo enumeraría sobre el trabajo en grupo. Seguro que hay muchas más, de hecho, si se hace una rápida búsqueda por Google, encontraremos largas listas de ventajas, pero yo hablo desde mi experiencia y punto de vista, y estas son las ventajas que yo he visto. Seguramente con el tiempo y más desarrollos en grupo, encuentre más ventajas, pero aún tengo mucho que aprender.

Seguro que dentro de un tiempo, cuando revise este artículo, me de cuenta de lo equivocado que estaba enumerando tan pocas ventajas y haciendo tanto hincapié en las desventajas de un grupo, aunque estoy intentando cambiar.

Anuncios

Trabajo en grupo – Parte I

Hoy quería hablar un poco sobre el trabajo en grupo, mis experiencias, por qué es importante y lo mal que nos han preparado para esto, y no precisamente en este orden.

Y es que la preparación que he recibido (hablo en mi caso, pero seguro que más de una persona se sentirá identificada) para trabajar en grupo ha sido, en el mejor de los casos, inexistente, digo en el mejor de los casos, porque si ha existido, lo más probable es que haya conseguido un sentimiento de rechazo brutal que te incita a escapar de él a la velocidad de la luz. Yo me incluía en este grupo, porque por experiencias pasadas, mi opinión del trabajo en grupo era tremendamente negativa y me había llevado a que durante la carrera, si se pedía un trabajo de estas características, aunque tuviera que realizar esfuerzos adicionales, intentar siempre realizarlo yo solo.

Aunque trabajar en grupo tiene sus cosas buenas, que comentaré más adelante, voy a comenzar con las cosas que consiguieron que me alejara de esta forma de trabajo durante tanto tiempo, hasta casi la actualidad, en la que he visto que no hay otra manera de conseguir realizar el desarrollo de un videojuego sin hipotecar tu vida. Existen casos de juegos excelentes realizados así, pero la inversión de tiempo ha sido realmente alta. Por poner un ejemplo, el tiempo de desarrollo de Braid fue de tres años.

Antes de desviarnos más, voy a hablar de los problemas que he encontrado en los trabajos en grupo, una vez más, en mi propia experiencia. Sobre todo, hablaré de este último desarrollo que he realizado, que ha sido el más grande y al que más tiempo he dedicado:

Comunicación: La comunicación en un grupo es un aspecto que tiene un coste asociado, de hecho, uno asombrosamente alto y que no te imaginas hasta que te sumerges en un proyecto real. Al igual que en los juegos hay ciertos atributos especiales que el jugador desconoce, pero afectan a todo, en las comunicaciones entre un grupo yo diría que existe un valor oculto que llamaré tasa de sincronía, que afecta a estos costes. Digamos que si entre los miembros del grupo hay una buena tasa de sincronía, puede reducirse ligeramente este coste de comunicación. Si vas a realizar un primer proyecto, lo más recomendable es buscar gente con la que tengas una buena tasa de sincronía. Lo peor es que no hay manera objetiva de manejar esto.

Democracia: Este siempre ha sido un aspecto que no he comprendido, quizá es que nadie quiere hacerse cargo del trabajo y así la responsabilidad se diluye en el grupo, otra razón que se me ocurre es que a nadie le gusta que le den órdenes, entonces, si eres el primero en sugerir lo que viene a continuación, pues remarcas su interés en no ser controlado.

El caso es que se comienza el proyecto y siempre hay una voz que dice “¡Vamos a votarlo TODO!”, una voz que debe de pensar que la democracia es el mejor invento del mundo, y que si todos votan sobre todo eso hará que la gente que votó por la opción que no salió seleccionada se sienta mejor. El principal problema con votar todo es que los costes asociados a la comunicación, que ya son bastante caros en un grupo, son elevados exponencialmente. Otro detalle importante es la coherencia, algo que se destruye si todo se vota y no hay una figura que se encargue de mantenerla a lo largo del desarrollo.

Interés: Este es un factor crítico y que es muy difícil de mantener a lo largo de un desarrollo. Como un miembro se desmotive, te saldrá con excusas, cada vez menos elaboradas (al principio suele ser realmente creativo para la creación de esas excusas) para trabajar menos o nada, porque no le gusta el rumbo que ha tomado el proyecto.

El que un miembro deje de ser productivo puede ser una bomba que destruya toda la planificación y la división de tareas, y en el peor de los casos puede tener salidas estrambóticas, como decir que abandona el grupo y dejar el proyecto temblando.

Posesión de la verdad absoluta: Este es el tipo de personas que más odio en un grupo. Como te caiga un elemento de éstos, estás jodido.

Una vez he mandado el mensaje alarmista, hablemos de ello. Las “estrellas del rock” (como me gusta llamarlos) son un tipo especial de gente que siempre cree estar en posesión de la verdad absoluta y que su opinión siempre es la mejor. Suele venir acompañado de no pegar un palo al agua porque ya te han iluminado con su sabiduría, así que consideran que ya es suficiente. Si realmente eres bueno, puede permitirse esta actitud, pero entonces, creo que no estás hecho para el trabajo en grupo.

Y ahora voy a compartir una pequeña cita de la página ¡Tenía que decirlo!:

Estudiantes, tenía que decir que en cualquier trabajo en grupo, siempre llega un momento en el que deseas asesinar al resto de compañeros, por bien que te caigan. Y si no te ha pasado, eso sólo quiere decir que alguien te quiere matar a ti. TQD

Es totalmente cierto. Aunque conozcas de toda la vida a los compañeros para la realización del proyecto, en algún momento vas a desear verlos muertos. Es normal, así que tranquilos, no estáis solos.

Pero no todo es malo en los grupos, algo bueno tiene que tener, pero viendo la longitud del artículo, voy a dejarlo para la próxima entrega.

Documentos de diseño

Aunque en la etapa de preproducción se realizan muchos documentos de diseño, voy a hablar de los tres que son más relevantes en esta fase y que sirven para describir la evolución de la idea del juego, por llamarlo de alguna manera.

Si alguien tiene dudas sobre el proceso de creación de un videojuego, les remito a Game Over, el primer programa satírico sobre videojuegos, programa de radio y podcast en el que fanatiko tiene una sección llamada “Destripando la industria” donde habló sobre Las fases de desarrollo de un videojuego.

Su artículo es especialmente interesante porque la mejor visión posible es la de alguien que trabaja ya en la industria, porque aunque yo intentara hablar sobre ello, no sería más que un enfoque teórico, porque aún no he participado en ningún desarrollo.

Comenzando con el meollo, los tres documentos a tratar son el

  1. Game Design Overview o One-sheet
  2. Ten-Pager
  3. Game Design Document o GDD
Todos tienen una serie de características comunes y es bueno tenerlas en cuenta a la hora de redactarlos:
  • Concreción. Sobre todo en las versiones “técnicas” de los mismos, es decir, los que van orientados a tu grupo de trabajo.
  • Precisión. Los documentos serán la información base con la que la gente trabajará y creará los contenidos. Cuanto más exacto mejor porque evitarás interpretaciones erróneas y eso ahorrará tiempo.
  • Ameno. Mucha gente va a leer el documento, y si es un ladrillo, será pesado para los que lo tienen que consultar. Intenta organizarlo lo mejor posible y utiliza las herramientas disponibles, como índices, enlaces y listas.
  • Bien escrito. Al igual que por la razón que el punto anterior, mucha gente terminará consultando tus documentos, y los fallos gramaticales o tipográficos pueden dar una sensación de dejadez o de falta de interés a la hora de redactar los documentos, así que revísalos.

One-Sheet

Como su nombre indica, es un documento que idealmente debe de ocupar una cara y tener la capacidad de ser atractivo, porque va a ser la carta de presentación de tu idea. ¡Y vas a tener solo una cara para expresar lo maravilloso que va a ser! Siempre va a ser insuficiente y hay una serie de datos que es más que recomendable que aparezcan, reduciendo aún más tu espacio. Tampoco es obligatorio hablar sobre los datos que comentaré a continuación, pero es una plantilla bastante buena.

  • Título del juego
  • Plataformas en las que estará disponible
  • Edad objetivo
  • Calificación por edades (PEGI y ESRB)
  • Resumen de la historia
  • Jugabilidad
  • Unique Selling Points o USP. Es decir, qué hace especial a tu juego
  • Competencia

Otra cosa importante sobre este documento es que, por lo general, no va a estar dirigido a una persona que juega habitualmente. Este documento, con el que pretender vender tu idea, estará leído por gente que tiene que invertir o por jefazos, así que intentar hacerlo lo más ameno posible será buena idea.

Ten-Pager

El Ten-Pager es la evolución del One-Sheet, si la cosa funciona como es debido, la idea debe de desarrollarse, en este caso, hasta que ocupe unas diez páginas, pero al igual que el documento anterior, si es posible que sea más escueto, es incluso beneficioso.

Como detalle y para posibles contingencias, no está de más que este documento tenga forma de presentación de diapositivas, porque si la idea gustó, probablemente la siguiente fase sea enseñar, en forma de pequeña presentación, por qué tu juego es el mejor en este momento prematuro y deben de invertir su dinero a lo loco en tí.

Pero un Ten-Pager más técnico para que tu grupo pueda comenzar a trabajar tampoco está de más, por lo que mi recomendación es hacer dos documentos (por suerte no son extensos) siendo uno más centrado a la venta de tu producto y otro más centrado a las características del juego.

Los apartados recomendados para este documento, y con una longitud de aproximadamente una página por cada uno son:

  • Página del título
  • Resumen del juego
  • Personajes
  • Jugabilidad
  • Mundo
  • Experiencia de juego
  • Mecánicas
  • Enemigos
  • Cutscenes
  • Material extra
Una regla que se aplica en este documento y en el siguiente es la regla de los tres ejemplos, porque los ejemplos son un gran aliado. Permiten explicar situaciones con todo lujo de detalles y la resolución de las mismas, permitiéndonos aclarar posibles puntos oscuros. Siguiendo con la regla de los ejemplos:
  • El primer ejemplo da una idea al lector sobre la situación, pero puede que no quede claro.
  • El segundo ejemplo nos permite comparar con el primer ejemplo.
  • El tercero anula el efecto binario, y complementa los ejemplos anteriores.

¿Quiere esto decir que cada vez que hay que poner un ejemplo, debemos de invertir el espacio y la capacidad de atención del lector con tres? Evidentemente no, hay que saber cuándo utilizar esta técnica.

Game Design Document

Este ladrillo de innumerables páginas será vuestra peor pesadilla por varias razones, pero para desarrollos grandes, mi opinión es que hace falta, ya que en él TODO debe de estar especificado, explicado y detallado para que cualquier desarrollador, en un momento dado, si tiene que consultarlo para saber cómo realizar algo, lo encuentre y no tenga que molestar a las personas que han dedicado su tiempo a la creación de este documento.

Por desgracia todos conocemos a la gente y lo vaga que es, y en más de una ocasión pasarán de buscar en el documento y preguntarán directamente. Esto es inevitable a menos que dispongas de un elemento disuasorio en una posición privilegiada y visible (como por ejemplo, un trofeo de caza con la cabeza del último desarrollador que preguntó demasiado), pero se puede mitigar siendo un documento ordenado, fácil de entender y ameno (cosa imposible para este documento).

Otro de los grandes problemas que traerá este documento, es que el proceso de desarrollo de un juego es un proceso vivo, y a lo largo del tiempo, ciertas cosas ya especificadas serán modificadas por alguna razón, y todos esos cambios deben de figurar en este documento, así que mantenerlo al día debería ser imperativo.

Nota: Si os habéis dado cuenta, estos documentos están enfocados a la entrega a un publisher y un desarrollo para un grupo grande. Esto no quiere decir que no os pueda servir para un desarrollo individual o para grupos pequeños. Mi experiencia es que estos documentos habrían sido de gran ayuda en el caso de haberlos realizado correctamente y habernos ceñido a ellos.

Aprovecho para agradecer a Victor Cerezo por la clase sobre Documentación, sin la que éste artículo no habría sido posible.