Creación de videojuegos/Producción/Solo o en equipo

Un método para desarrollo en equipo sin contrato laboral

Este método es muy útil para dirigir aquellos equipos de desarrollo de videojuegos que se forman por afición, más que por una actividad económica donde habría un contrato legal de trabajo y una jerarquía administrativa. Generalmente los miembros de estos equipos corren con sus gastos por cuenta propia, y se acuerda que las ganancias del proyecto serán repartidas en partes equitativas entre todos. En este tipo de equipos es importante crear un ambiente democrático, muy similar a como funcionaban los barcos piratas en el Caribe (entiéndase Piratas en el sentido de la aventura). Aunque se eligirán líderes, estos no tienen un papel principalmente autoritario, sino que serán los encargados de mantener el orden del proyecto, vigilar las metas, y por sobre todo resolver los problemas que se presenten para que el proyecto siga adelante y se complete.

Elección de "solucionadores de problemas" ó líderes

Al iniciar el proyecto se debe elegir un líder general, y sublíderes para programación, artes, y mercadeo/ventas en caso de que se quiera mercadear y vender el vjuego, y tal vez hasta uno de producción si se va a empacar el juego en discos compactos con cajas impresas y su manual, etc.

Los líderes tendrán que resignarse a que, posiblemente, al comienzo del desarrollo no podrán trabajar directamente en este, sino que estarán encargados de administrar. El inicio de todo proyecto es la parte más difícil y requiere de toda la concentración de sus líderes para sentar las bases y dirigir al equipo en la dirección correcta. Todo es un caos en un comienzo y hay que darle forma.

Diseño del proyecto, y revisión de alcances y limitaciones

El líder general debe discutir junto con el diseñador, y los que estén dispuestos a aportar buenas ideas, cuales son los elementos que se necesitan en el juego. Es necesario llevar el diseño muy muy lejos, pensando incluso cosas que no se realizarían hasta futuras versiones, pero que igual es bueno tenerlas en mente ya que el desarrollo debe dejar un espacio para que estos elementos se integren más adelante. Fallar en ver el diseño en toda su extensión y posibilidades, podría provocar que las ideas sin explorar salgan de pronto durante el desarrollo y entonces se desviaría el curso del diseño, porque estamos hablando de un diseño dinámico.

Mientras se discute el super-diseño, en paralelo se deben ver qué elementos del diseño se pueden realizar. No hay que descartar ningún elemento, simplemente se está midiendo qué tan posible es realizarlos, y así determinar cuales son más prioritarios, y de qué manera se puede hacer para integrar el mayor número. Después de revisar a conciencia todas las posibilidades del juego y la forma como se pueden desarrollar, debe salir un diseño que por fin contendrá todos los elementos del juego que el equipo realmente puede crear, y que seguramente dejará satisfechos a todos los integrantes.

Plan de desarrollo

A partir de ese momento, el siguiente paso de los líderes es hacer un plan de desarrollo que armonice el trabajo de los demás. El líder de programación debe elegir no solamente las herramientas que se van a utilizar, también debe definir los más pequeños detalles como la forma en que se escribirán los programas, por ejemplo, variables globales y funciones con la primera letra de cada palabra en mayúscula y con prefijos del módulo donde se encuentran, y cosas así. Eso hace homogéneo el código, lo cual acelera mucho la integración de nuevas rutinas y módulos al proyecto. Hay que tomar en cuenta que el que hace un módulo o biblioteca no necesariamente es el único que va a utilizarlo, seguramente otros van a necesitarlo, así que con un estandar de escritura de código pueden leerlo y entenderlo más fácil. Al principio es un poco díficil adaptarse al estándar, y seguramente el líder tendrá que revisar el código de los compañeros, pero luego todo se hace más claro y es casi como si una misma persona hiciera todo el código... eso es armonizar el equipo de programación. Nuevos programadores que se unan al grupo no tendrán muchos problemas para entender el código, y cualquiera podrá explicarles las reglas pues todos las están usando. Y eso del método de programación tiene que ir más allá de solamente la forma como se escribe, también la estructura como se resuelven los problemas, por ejemplo todos los objetos usando un método que realice un trabajo coceptualmente similar a los demás, etc. Lo mismo va para los artistas en su campo, deben armonizar su trabajo con el de todos.

La vida en altamar

Ahora viene el trabajo que mejor distingue a un buen líder: resolver los problemas. El líder es el que tiene que detectar los problemas generales, y da las soluciones para que todos puedan seguirlas. Montones de problemas se van a presentar durante el desarrollo, y es increíble que muchas veces los peores problemas no son con el código o con los gráficos, sino factores externos que incluyen hasta problemas personales. Los líderes tienen que enfrentarse a todas esas cosas y resolverlas, por eso hay que escojer bien desde un principio. Si el líder es perezoso, todos van a volverse perezosos, si en cambio es trabajador y pone rápidamente en práctica buenas soluciones, entonces va a impulsar a los demás y así al proyecto. Que el líder sea autoritario o no, no tiene relevancia. Los que no quieren trabajar simplemente no lo van a hacer, y los que están aflijidos por la presión del trabajo solo se van a poner peor con un líder que presiona. Por eso el resolver problemas es lo que hace al buen líder, y no que sea autoritario.

De lo anterior viene el último punto que caracteriza a este método, y es que el líder de cada área debe desglozar en el diseño dinámico todas las tareas que deben realizarse, y la elección de las tareas debería ser un derecho de los miembros del grupo. Cada uno sabe qué tarea le entusiasma, y de esa forma puede trabajar más rápido. No se le deben dar a elegir a los miembros tareas muy generales, como por ejemplo: "hacer el motor". En cambio se debe desglosar al máximo, por ejemplo: hacer el motor requiere hacer los efectos de partículas, que requieren como subtarea, hacer el efecto de fuego. Entonces el efecto de fuego de este motor es una de tantas tareas que alguien puede tomar y sacar en alrededor de una semana sin tanta presión. Ya de por sí, meses y meses de trabajo van a golpear a los miembros, no hay razón para atragantarse de trabajo cuando se puede ir con calma pero avanzando animadamente. Terminar tareas concretas además da un sentido de que se está llegando a algo. Y si un líder no puede desglosar bien las tareas es porque no está entendiendo el problema, o no le interesa... si no puede hacer ni siquiera eso, entonces no puede esperar que los demás hagan su trabajo. El líder debe proporcionarle al equipo una lista de tareas para escoger, y así los miembros pueden concentrarse en resolverlas de la mejor manera. Esta lista, como parte del diseño, también es dinámica.

--Cronodragon 18:17 4 sep, 2005 (UTC)

Enlaces

Volver a Creación de videojuegos