“La etapa de Planeación”: el aterrizaje forzoso de todo proyecto

19 11 2007

Saludos

Hace mucho que no posteaba algo… bueno, trabajo y estudio no dejan mucho tiempo para el desarrollo pero uno siempre se las arregla para hacer algo ;).

Bien el motivo de este post es para explicar algo teórico, que todo proyecto de desarrollo de videojuegos debe considerar y que si es tomado a la ligera se puede convertir en el mayor “Project Killer” como lo he escuchado nombrar en varios artículos. Se trata de la etapa de planeación inicial de un proyecto, que comienza desde el momento que el desarrollador dice “¡Quiero hacer un videojuego!”. Para este articulo me basaré en uno de los miles artículos que hay que te indican como NO hacer un videojuego, este ultimo me llamo la atención por que es el mas preciso de los que he visto (y créanme que he visto bastantes XD), este habla acerca de los 6 errores típicos de un desarrollador independiente… y para ponerle un poco de saborcito al tema, voy a relacionar cada punto a como estoy tratando yo el desarrollo de mi proyecto, para predicar con el ejemplo ;).

Los 6 errores típicos de un desarrollador independiente son los siguientes:

Voy a hacer un RPG con 3000 tipos de monstruos, 5000 ítems y armas distintas, combates en tiempo real, un modo en primera persona y un sistema de pesca… haaa y mucho baile


Bueno… por muchas ideas que uno tenga de hacer un juego que tenga todo lo que imaginemos y que brindará horas de diversión al jugador… debemos ser realistas, por lo general contamos con un equipo de 4 a 5 personas (o 1 solitario desarrollador como es mi caso :P) saquemos cuentas: tenemos 1 programador que le pega también al diseño, 1 diseñador que dibuja genial pero esta aprendiendo 3d, un músico que es un maestro en Fruityloops y Cool edit, 1 diseñador 3d y nuestra creadora mente… bien con esto tenemos suficiente personal para crear un hermoso buscaminas J. A menos que sepamos administrar muy bien nuestro tiempo, tengamos las herramientas adecuadas y nuestro personal sea muy disciplinado… este proyecto seguirá siendo eterno. Incluso para equipos profesionales conformados por más de 100 personas seria una labor titánica de más de uno o dos años de desarrollo para realizar un proyecto como el del enunciado. Así, lo más saludable para realizar esto es realizar una versión reducida del mismo… tal vez un RPG hecho en RPG Maker, con 3 personajes principales y 2 armas por personaje.. Talvez 5 enemigos distintos pero de distintos colores y con otros patrones de comportamiento. O sea algo adaptado a las habilidades de cada integrante…

Para mi caso (el solitario diseñador) la cosa se complica mas por que soy el que hace todo, así que en esta etapa gaste mucho tiempo, más de lo que gaste en desarrollar el Master Design Document, y fue el aterrizaje forzoso que se tiene que dar todo desarrollador. Mi juego tendrá solo 3 mapas, 2 personajes principales (con el resto se interactuará solo a nivel de textos y conversaciones breves… de texto obviamenteJ) y otros detalles extra… todo adaptado a las habilidades que poseo hasta el momento y las que posee el software que usareJ.

Tengo el diseño del juego en mi mente, ahora tengo que solo hacerlo

Bien, debo admitirlo, esta frase la dije demasiadas veces sin caer en el error que estaba cometiendo. Un desarrollador profesional no tiene el juego en su mente, el genera un documento con todos los puntos generales, personajes, armas, etapas, etc., sus detalles y luego fija “Milestones” o puntos de control. Algorítmicamente, uno debe hacer un índice (Master Design Document), a partir de este índice, tomar el primer punto y ponerle una fecha de término, ojo que este índice también debe estar dentro de la planificación. Y obviamente no comenzar el desarrollo del siguiente punto hasta terminar el que se esta desarrollando, así no se pierde la continuidad en el desarrollo y no se debe volver atrás a “parchar” algo que se nos olvido terminar en una etapa anterior. Todo esto DEBE tener fechas relativas… y en la mediada de lo posible tratar de respetarlas.

En mi caso… ya termine el Milestone del Master design document. Ahora estoy en el punto de control de la elección de las herramientas… este ultimo terminará el 30 de noviembre, de terminar antes con el, correré las fechas para aprovechar ese tiempo extraJ.

“Estará terminado cuando este terminado”

Generalmente la gente grande como Blizzard (creadores de las sagas de Diablo, Warcraft, Starcraft, etc.) dicen esto para mantener el hermetismo en el desarrollo de su proyecto, además lo hacen para aumentar las especulaciones acerca de su proyecto. Pero la mayoría de las ocasiones que hacen este comentario sus juegos dejan una marca en la historia de los juegos (Starcraft y World of Warcraft se me vienen a la mente en este momento). Pero si esta misma frase la dice un pequeño grupo independiente o un programador solitario como yo… solo significa que no se tiene idea del tamaño del proyecto o que no se sabe realmente lo que se esta haciendo. Peor aun, se podría tratar de que se empezó el proyecto con una idea base y no se sabe como terminara… o que solo nos hemos quedado con el “Voy a hacer un videojuego!!” y nos tiramos de cabeza al computador a diseñar y programar agregando las ideas que nazcan a medida que se esta programando. Esto es realmente malísimo, ya que se esta realizando mucho trabajo y lo mas probable es pasado el tiempo uno trate de ver como esta quedando el proyecto y se desilusione con los pocos avances que este tiene y termine desechándolo, debido a que siempre puede faltar eso que se nos acaba de ocurrir, además, uno puede tener un excelente diseño de personajes, una muy buena interfaz o una excelente música, pero al unir todo no esta ni cerca de lo que nosotros creamos.

Para apalear esto lo primero que se debe hacer es definir el objetivo final de ese juego… si será para venderlo, para ganar experiencia, para hacer una carta de presentación, para divertir a la gente, etc… ya que no tiene sentido hacer un juego que dure 100 horas para terminarlo si uno lo quiere mostrar como “currículum” ya que por lo general miraran el proyecto por unos minutos y dirán si les interesa o no, o componer una banda sonora enorme con 20 temas si nuestro juego tiene tan solo 3 etapas. Así analizando muy bien esto, más un objetivo final, sumarle un buen desarrollo del MDC y un buen calculo de MileStones (MS para los amigos) recién ahí podremos tener una idea del tamaño aproximado de nuestro proyecto y ver si podemos decir “Estará terminado cuando este terminado”.

No entiendo esto… bueno lo resolveré mientras avance en el proyecto

Algunas cosas son evidentes, o se ven muy evidentes, pero que a la larga no lo son. Por ejemplo puedes decir. “mi juego tendrá un sistema de aprendizaje donde el personaje podrá aprender distintas profesiones, las cuales sumadas a su rendimiento y los lugares que explore, harán que el personaje incluso pueda construir una casa, o inventar su propio baile!”. Si al oír eso te preguntan “y como funcionara?” tu respuesta es “no lo se pero lo resolveré mientras desarrolle” tu proyecto no esta listo para pasar a la etapa de desarrollo y esta atascado en la de planificación.

Es muy fácil crear gigantescos y completos mundos, completísimos y perfectos motores de juego llenos de detalles o personajes customizables a full. Pero si no sabemos como hacerlo, como implementarlo o peor aún no sabemos los procesos intermedios que realizan una función determinada (no hablo a nivel de código) estamos dando “palos de siego” en el desarrollo. Es tan simple como decir “incorporare un sistema de pesca” y describirlo como “primero haré que el pez en el agua, luego haré la función de la caña de pescar (funcionamiento y animación) y luego haré la función que muestra el pez capturado y lo guarda en un canasto” obviamente uno puede perfeccionar esto mismo con mas detalles. Concluyendo, lo que quiero decir es que si desean agregar una función o característica al proyecto… lo primero que tienen que hacer es saber es cuales son sus procesos principales y como funcionan estos mismos, ya que si tratan de hacer esto mismo mientras están programando, se darán cuenta que no era tan fácil ni rápido como lo pensaron.

En mi caso, la jugabilidad es bastante sencilla, y haré algo de reutilización de código 😉 les daré mas avances cuando les presente mi reporte del primer milestone de mi proyecto que acabo de terminar.

Tengo un capitulo de 500 paginas que explica como funcionaran las armas que se usaran en mi proyecto

Curiosamente, ser demasiado preciso o descriptivo puede llegar a ser algo contraproducente, debido a que se necesita de cierta flexibilidad en para cuando se este implementado lo que nosotros diseñamos. Decir por ejemplo “el héroe del juego es una polilla mutante asesina armada hasta los dientes” es mucho mejor que decir “el héroe del juego es una polilla mutante asesina súper desarrollada que dispara rayos láser por los ojos, sus alas emiten descargas eléctricas de 5000 Watts. Esta armada con una escopeta que tiene 3 disparos distintos, fuego, hielo y veneno cada bala pesa 500 gramos cada una y esta hecha de una resina especial que se destruye al contacto con un blanco, siempre y cuando este a 50mts de distancia de este ultimo, los proyectiles de hielo causan que el enemigo se desplace a 1/5 de su velocidad siempre y cuando este sea de un tamaño menor a 137.8cm y blablablabla….” Se nota una diferencia no es así? Una vez que tengan bien establecido como funcionara cada nivel, cuantos enemigos y cuan duros son recién podrán comenzar con el armamento, así se aseguran de que la jugabilidad será balanceada y no imposible o muy fácil. Ejemplos como este hay muchos, casi para cada cosa que deseen desarrollar.

En mi caso, “el héroe es una mujer de nombre Rayen que esta armada con una herramienta de soldar modificada y un cuchillo (se lo regalo el papi y es netamente ornamental) “. Mas detalles se los daré en el primer reporte de MS sobre el Master design document.

Yo hago el diseño, yo le programo, yo le compongo la música, yo le testeo yo le hago…

Embarcarse en proyectos grandes solo o con la gente adecuada es una de las mejores formas de matar un proyecto con futuro. Debido a que estando solo y realizando todo no se llegaría a una especialización en ningún área. Y con la gente incorrecta se perderá demasiado tiempo logrando una unificación de criterios tal que nos permita trabajar tranquilos sabiendo que lo que realicemos se complementara bien con lo que desarrolla mi compañero de equipo y no obstruirle el trabajo realizado.

La única forma de realizar un proyecto con poco personal o una sola persona (como es mi caso) es aterrizándolo bruscamente a piso y diseñar algo a la altura de nuestras habilidades al corto y mediano plazo. O realizando proyectos minimalistas, los cuales se perfeccionen con las sucesivas versiones como lo ha hecho nifflas en su proyecto Knytt Stories.

En mi caso, mi proyecto es solo de aprendizaje, y utilizare modelos prediseñados y un motor bastante amigable que he encontrado. No será largo, creo que podrán terminarlo en media hora aproximadamente. La idea mi proyecto es demostrar que si se puede crear algo a nivel nacional, de hecho tengo claras y definidas las etapas de desarrollo y las fechas relativas para darle la seriedad necesaria. Estimo el tiempo de desarrollo en 1 año aprox.

Bien, espero no haberlos lateado tanto, pero este pequeño documento es la recopilación de bastantes artículos relacionados y es algo que es necesario saber antes de comenzar con el desarrollo de cualquier proyecto. Créanme que ayuda bastante saber donde están parados y a donde llega el camino que estamos recorriendo.

 

Un saludo

Anuncios

Acciones

Information

4 responses

19 11 2007
Roberto

Wow no pense encontrarme con un blog asi, gracias por los consejos!

20 11 2007
nuitei

Y las voces? van?

Buen documento. Espero ver avances pronto!

20 11 2007
Brandimer

Saludos

las voces si van, pero no programadas en OpenAl como queria, me consumirian mucho time, seran ejecutadas desde mpr o wavs en formas puras, tal vez le de mas pulido pero eso esta fuera de lo que esta planeado para el desarrollo del proyecto actual.

esop

21 11 2007
Quieres crear un juego? Primero lee esto « Nuut@Games

[…] nuitei Categorías: desarrollo Nuestro amigo Brandimer nos trae una buena reflexión sobre percances que pueden aparecer al intentar crear un juego por primera vez y que puede destruir un buen […]

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s




A %d blogueros les gusta esto: