SoloCodigo

Hola.

Francamente, creo que es erróneo enfocar la planificación de un videojuego con una metodología clásica, del estilo Métrica 3 o Merise. Incluso no me acaba de gustar para esa aplicación concreta Unified Process. Demasiado trabajo antes de llegar a ver algo funcionar, que está muy bien para muchos casos, ya que ayuda a organizar todo de manera que se asegure el éxito de un proyecto. Sin embargo un videojuego es, claramente, una pieza software que se ha de ver funcionar desde el principio y hay que ir construyendo sobre prototipo inicial.

Prueba de esto es el desarrollo de los videojuegos de las grandes compañías: al poco de empezar ya hay screenshots del juego funcionando, aunque aún falten años para acabarlo.

Cierto es que se ha de tener claro el juego antes de empezar, definir una serie de requisitos funcionales. Pero no realizar todos los diagramas detallados en UML, o cualquier otra notación, módulo por módulo y clase por clase. En mi opinión esto le quita diversión a la realización del juego en sí, además de flexibilidad (si realizas algún cambio que se te ocurra a mitad de escribir el código tendrás que actualizar diagramas y, dependiendo de lo fielmente que sigas la metodología, hacer estudios de viabilidad del cambio, gestión de la configuración, etc. Esto se puede hacer muy pesado).

Lo esencial de un videojuego es su jugabilidad, el estilo de juego, que esté bien balanceado, que sea divertido. Y eso no lo vas a conseguir con diagramas de flujo de datos, de módulos, de clases, de colaboración, o del tipo que sean.

Te recomiendo que le eches un vistazo a esta página, con una cantidad enorme de recursos sobre el diseño de juegos (incluido un documento de diseño oficial de empresas del sector, bastante interesante ver cómo se centra en describir el juego y cómo funciona, en vez de cómo programarlo):
General Game Design

Un saludo.

Ruben3d

Saludos Ruben3D!

Entiendo tu punto de vista (ya que al parecer te dedicas a la parte gráfica) pero
un buen análisis y un diseño robusto, si que puede ayudar a la hora de implementar el juego.

Los grandes desarrolladores generan "screenshots" rápidamente porque adoptan un modelo de proceso en "espiral", esto es, se van generando incrementos del proyecto por medio de iteraciones, pero cada iteración cuenta con su etapa de planificación, análisis, diseño y obiamente la implementación de un prototipo (desechable o no), es decir: codigo + imágenes.

La realización de un modelo (UML, estructurado, o los que sea) tiene como objetivo servir de guía a los programadores, no importa que posteriormente se realicen cambios en las clases o se agregen más elementos.

Con los diagramas (y no sólo estos, sino otros documentos "hablados" que también son parte del análisis y el diseño) no se pretende construir un juego, pero si puede aportar mucho a la hora de implementarlo.

Al contrario de una "aplicación de escritorio", un videojuego no requiere de unas etapas de analisis y diseño tan complejas, ya que por lo general el cliente es el mismo desarrollador y CLARO! nada mejor que ver funcionando algo en la pantalla.

Visité tu página y me gusto el trabajo de la <Nave de transporte>, felicitaciones.

jajaja  

me corchaste!!!!
sino estoy mal es Rational Unified Procces

En palabras globales UML es una 'herramienta' o 'lenguaje' (lenguaje ... no creo pero asi lo he visto por ahi) y el RUP es la guia de como usarla.

Mi contestación a este post

UML cómo se usa?

explica un poco la relación entre UML y UP.

Un saludo.

Ruben3d

Está claro que la determinación de la adopción de fases de análisis y diseño son circunstanciales, es decir, depende de la situación específica del proyecto.

PERO:

Lo que realmente quiero saber, es si existe un interés por obtener un ejemplo real, práctico y aplicado de estas fases en el desarrollo de un videojuego, ya que en la red existen pocos ejemplos de esto (por lo menos en nuestro idioma), o si alguien conoce alguno, por favor citarlo. Lo que pretendo es realizar un modelado de todo el sistema (juego) y no tanto la creación de un juego exitoso.

Hola que tal.

En verdad creo que esta muy bien la fase de planificacion, no solo para la parte de la programacion, sino tambien para los otros tipos relacionados en el videojuegos (historia, graficos, sonido), de esta manera, se llevan unos procesos concordantes de scripting, programacion,modelado,etc.

Aun así, hace poco un amigo me hizo entender que hacer un juego es un proceso creativo, aun la parte de programacion, que para algunos es la mas cuadrada.

De todos modos seria bueno que publicaras los esquemas a ver que tal salió, pero yo no trataría de encapsular la programacion de videojuegos en esquemas tan formales como el UML, le quitan lo divertido cuando terminas el juego (ya verás).

Bueno,
yo solo digo una cosa..

Un juego se hace para divertir a los demas y generalmente para obteber utilidad de eso. Para obtener utilidad debemos diseñar algo que cualquier persona del ramo lo pueda entender y que nosotros mismo lo podamos hacer si queremos que nuestro codigo sea reutilizable y nos ahorre mucho trabajo en el futuro.

No dudo que hay, y habemos muchos gomozos de la programacion y que pensemos que deberiamos hacer un juego pensado en divertirnos..
eso no esta mal..

Pero es un mal enfoque hacer un juego pensando en divertirnos haciendolo, ya que sin lugar a dudas esa 'necesidad' de diversion por patrte de los creadores va en contraparte con lo que es el desarrollo de un producto de calidad, que sijn lugar a dudas para lograr ese objetivo de 'calidad' requerira mucho esfuerzo y tiempo dedicado al diseño.

Los procesos de dieño no prentenden ser la ultima palabra en el desarrallo y creacion de un videojuego ni de ningun tipo de software, el objeto del diseño es el de minimizar los fallos y todos los problemas en el futuro y desde luego crear una aplicacion cuyos componentes faciliten su reutilizacion y disminuyan el tiempo de desarrollo y de depuracion del software una vez este terminado.

Los diseños nunca contemplan todo, siempre quedan vaches, pero sino fuera por el diseño esos vaches estarian presentes un un porcentaje mucho mayor.

Tras realizar correcciones o desarrollos que se alejan del diseño debido a una necesidad o problema que no pudo ser previsto en la fase de diseño es necesario actualizar los documentos de diseño ya que el fin de estos mismos es el de dar soporte, documentacion y el de servir de almacenes de experiencia para eventos futuros.

En resumen el diseño y el mantenimiento del mismo es muy importante, el objeto de crear un juego puede variar segun las nececidades de cada quien,
los que quieren hacer juegos solo para tener un trabajo divertido... no necesitaran mucho de diseño porque su trabajo a la larga solo sera visto por ellos y por unos pocos y luego estara en la papelera de reciclaje o en alguna carpeta que nunca miren, y luego tal vez comiencen otro juego para divertirce, o tal ves no vuelvan a hacer ninguno nunca.
Las personas que pretendan o que tengan una vision empresarial y contemplenla creacion de videojuegos  como algo que no solamente debe ser divertido sino que debe ser un producto que cumpla estandares de calidad deberian pensar en procesos no tan divertidos como solo hacer un juego y ya, sino pensar en los diferentes procesos de modelamiento de software, en especial lo que se acomoden a los estandare internacionales, y si no logran por alguna razon adoptar un estandart existente, deberioan ponerse en la tarea de diselñar su propia metodologia de diseño siempre y cuando esta este en favor de la calidad en todos sus aspectos.

Infortunadamente o afortunadamente, segun sea el caso, en paises como colombia que son de escasos recursos, patrocinar empresas que quieran surgir en el campo de la multimedia y de los videojuego puede ser un riesgo muy alto que muy, pero muy pocos o ningun inversionista esta dispuesto a hacer... la razon...
No existen propuestas serias que cumplan con estandares ya establecidos, que cuenten con proyecciones basadas en datos reales y que adopten metodologias que incrementen la probabilidad de exito en la elaboracion de dichos proyectos.. los inversionistas necesitan saber que su inversion va a ser recuperada y que mas aun va a producir utilidades...
No podemos pretender convencer a alguien de que un producto va a ser bueno porque para nosotros es divertido hacerlo y somos muy buenos programando y haciendo animaciones...
se necesita vision empresarial y de negocios...

Dudo que empresas como Nintendo, Acclaim, Sega, SquareSoft o cualquiera bien conocida no utilice una metodologia determinada de diseño y desarrollo de software, aunque seguro que esto implica para ellos una mayor inversion de dinero y de tiempo para sus proyectos , pero de igual forma esta inversion se retribuira en resultados inmediatos en forma de ganancias y en resultados en mediano plazo mejorando sus procesos de desarrolo a travez de la reutilizacion y facil depuracion de los codigos ya escritos...

Sinceramente.. alguien cree que  el motor que ha logrado hacer SquareSoft no conto con un fuerte diseño desde sus primeras y posiblemente simples versiones?

Yo estoy convencido de que si hubo mucho diseño y de que seguramente pasaron muchos meses elaborando papeles poco divertidos....
Lo mismo pienso de juegos como Luigis Mansion para el NGC o los juegos de deportes de EA.

Tal ves en los tiempos del primer donkey Kong, o de la famosa ranita que saltava troncos en el atari 2600 o en los tiempos de juegos como el primer Goal! no se usaba mucho o nada de diseño pero hoy en dia...???
No se cuantos participantes sean ingenieros o cuantos estan estudiando.. pero lo cierto es que un ingeniero se caracteriza por llevar procesos a travez de metodologias propias o innovadoras, trabajos que no requieran diseñlo y que esten en elgun modo mas enfocados a la programacion o al hobby son más caractreristicos de personas que han optado por seguir ramas tecnicas o tecnologicas, lo cual no esta mal porque hacen lo que les gusta y estudiaron lo que les gusta.... en lo personal estudie ingenieria de sistemas por que me GUSTA la parte tecnica, la tecnologica pero mucho mas me gusta la parte de innovar y hacer las cosas bien siguiendo estandares de calidad y promoviendo siempre la eficiencia y economia de los procesos.. asi que he dado una respuesta pensando como Ingeniero.

Bueno.....

Para finalizar quiero decir que un buen diseño es la antesala a la garantía de calidad del software (incluyendo videojuegos).

He visto que hay interés en el tema, así que próximamente publicaré el primero de una serie de documentos que he escrito: El documento conceptual, que tiene como proposito, presentar la idea del juego de una forma resumida. Quiero aclarar que la idea original fue tomada de un curso de programación de juegos en http://www.geocities.com/agnasg/ . Lo que hice fue ampliarla un poco y cambiar algunos detalles.

Espero que les sea útil, y más adelante publicaré el argumento del juego (una historia pequeña pero interesante) y el documento de planificación.

Nota: Ya está listo:
         - Planificación y estimaciones (en LDC y PF)
         - Especificaciones
         - Análisis de sistemas
         - Análisis estructurado de los sistemas

         Falta hacer una revisión de este material.

(Yo creo que mañana estará listo el sitio web en: http://www.fireoff.tk)