Stratos: Punto de Encuentro de Desarrolladores

¡Bienvenido a Stratos!

Acceder

Foros





Uml Y Use Cases

Iniciado por tiutiu, 04 de Diciembre de 2005, 11:02:25 PM

« anterior - próximo »

tiutiu

 He estado leyendo unos apuntes de Ingenieria del Software y he pensado que podria utilizar UML y la metodologia que se expone para diseñar un juego.
Segun lo que he visto y leido por ahi, muchas de estas metodologias se aplican principalmente a software orientado a negocios, con un flujo de acciones bastante marcado y que para videojuegos quizas aun no le ha llegado el momento.
Por otro lado no deja de ser una herramienta, la usas cuando es necesaria, no es un dogma que seguir al pie de la letra para obtener resultados.

Bueno, al grano. Estas son mis preguntas:
¿Cuales serian los actores? En principio seria el usuario y el reloj del juego, pero si separamos cada subsistema y sacamos sus casos de uso, pueden aparecer los otros subsistemas como actores.
¿Que casos de uso podriamos tener en un juego? Algo asi como esto
QUOTE (Post en GameDev.net)

Title: Using environment items as weapons.
Description: A character can pick items and use it as weapons to hit enemies.
Actors: Main Character (MC), Enemy Character (EC), item (weapon).
Principal flow:
- MC approaches an item he wants to pick.
- Item gets added to MC's inventory.
- MC activates item as principal weapon.
- MC hits EC with his principal weapon.
[/quote]
¿Deberian ser todos los casos de uso sobre el juego o habria que clasificarlos entre juego y motor? ¿Y si separamos por subsistemas?

Me gustaria saber vuestras opiniones al respecto, tanto para las preguntas que he hecho como del tema en general: utilidad de UML y de Use Cases para diseñar un motor/juego. ¿Alguno de aqui lo usais?


PD: para el que le interese, he hecho un thread mas o menos igual para conocer mas opinones (a ver si tiene exito :huh: ).
b>:: Pandora's Box project ::
Notas e ideas sobre desarrollo de engines para juegos

zupervaca

 cualquier analisis previo a un proyecto es un paso importante, se llame uml o grijanderml, mientras mas graficos hagas sobre el motor mas claro lo tendras tu y todos aquellos que lo quieran usar, por ejemplo si mal no recuerdo el dia que mira la web de ogre tenian varias graficas con las clases, forma de trabajar el motor y otras cosas

nunca me habia puesto a mirar un programa para ello, pero nada mas poner uml en google para ver si existia alguno me salio este

zupervaca

 perdona el segundo post seguido, pero es que no me deja editar el anterior

me he puesto a buscar el uml del ogre que era lo que te comentaba en el anterior post, espero que te ayude, http://www.ogre3d.org/docs/manual/manual_4.html#SEC4

tiutiu

 Ya no me acordaba que el OGRE tenia diagramas UML en la documentacion, gracias por refrescarme la url :D

En GD.net me han contestado con un par de ejemplos de casos de uso para un juego.
Me parece mejor idea pensar en casos de uso antes que en una descripcion completa de cada subsistema, puesto que de los casos de uso puedes sacar escenarios y de ahi las caractersiticas, clases y partes de todo el sistema. Ademas, enfoca mejor la relacion usuario-diseñador centrandose en lo que va a hacer el usuario con el sistema.

De todos modos, supongo que no hay que abusar y ponerte a diseñar todo en UML con todos los tipos de diagramas existentes. Estaria bien hacer un articulillo sobre la aplicacion de esta metodologia para diseñar juegos.

zupervaca, claro que siempre es mejor hacer cuantos mas graficos y diagramas mejor, pero me referia a si sale a cuenta usar metodologias estandarizadas como estas en desarrollo de juegos, ya que no estan tan enfocadas a este tipo de software (segun lo que he leido, claro).
b>:: Pandora's Box project ::
Notas e ideas sobre desarrollo de engines para juegos

nostromo

 
Te recomiendo uno de los mejores libros sobre analisis y desarrollo orientado a objetos utilizando UML:

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition

Tan solo comentar que UML es solo una especificación de diversos tipos de diagramas que nos sirven para construir(analisis y diseño) programas. Esto es, UML es una forma estandar de dibujar diagramas. No es un metodo para construir programas.

En particular el tipo de diagrama que a posteado zupervaca de ogre es muy util , es el diagrama de clases donde vemos el tipo de asociación(como se relacionan) de las clases de nuestro programa.
Luego hay otros tipos de diagramas como el de secuencia y el de colaboración que sirven para ver como interactuan los objetos para conseguir "algo"(ej. mover un jugador). Estos son casi el codigo del programa.

Los casos de uso son para capturar requerimientos de nuestro programa, es decir, que demonios debe hacer. Los "actores" del caso de uso normalmente son usuarios(recepcionista, dependiente, servicio tecnico etc) del programa y el sistema/subsistema. El titulo es siempre un objetivo a realizar por el actor principal; ejemplos: "Comprar productos","Inicio del programa"(actor el sistema) etc..

Utilidades:
- los casos de uso son buenos para tener un saco donde poner las cosas que se pueden hacer en el juego. Sobre todo las importantes. Además siempre hay casos de uso más dificiles por lo que se debe empezar a desarrollar estos al principio y asi sabrás si se puede hacer o no(si es viable vamos).
- los otros diagramas como el de clases te ofrecen una vista general y otras más en detalle(d.colaboración/secuencia) utiles para visualizar la estructura de lo que se va a programar.
- lo mejor es escoger los diagramas que mejor te sirvan para lo que vayas a hacer.

Sobre un metodo o proceso a seguir para construir con estos diagramas lo mejor es mirar el libro que te he puesto. Ahora bien, como tu dices realmente es muy usado en gestion pero en juegos estamos aún algo verdes.

Como herramientas la famosa es de Rational ahora de IBM.
Y más novedosa es la de borland: Borland Together, no la he tocado mucho pero me ha sorprendido, sobre todo por que otras herramientas siempre tienen una manera de generar codigo a partir de los diagramas y obtener diagramas a partir de codigo pero esto solo es util al final de un desarrollo o al principio de un desarrollo viejo respectivamente. Es decir el codigo y los diagramas van cada uno por su lado y todos sabemos que esto de diseñar software es iterativo no se hace de golpe y listo.
Lo que me sorprendio de Together fue que modificaba el codigo(c++ fue lo que probé) mientras cambiabas los diagramas y cambiaba los diagramas mientras editaba el codigo. Y esto es genial ya que de otra forma los diagramas al final son algo que no esta conectado con el codigo y al final puede(lo más seguro)  que esten desincronizados del codigo por pereza a la hora de mantenerlos. No soy un experto en el tema pero no he visto ninguna herramienta que haga esto.



Un saludo


seryu

 Respondiendo rapido..

¿UML util para hacer un juego? puede.

¿UML para hacer un engine? puede.

Al final llamalo X, mientras hagas un esquema, diagrama o texto con el que tengas una idea clara de lo que quieras hacer, funciona.

Es bueno tener documentacion y hacer un analisis previo, el sistema y herramientas que utilices.. dependen de tus gustos.






Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad.
Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante.
Muchísimas gracias.