Diseño De Vuestro Framework

[tiutiu]

 Bueno, hacia mucho que no posteaba en stratos :cry:

Llevaba tiempo sin tocar el engine y ahora he vuelto a pensar en el y me he decidido a terminar de plantear el diseño sobre papel.
Supongo que la primera pregunta cuando queremos diseñar un programa es: ¿Que es lo que quiero? Pues lo que quiero es un framework para construir un engine(s) sobre el. A parte de comunicar con el SO, necesito toda una serie de entidades para manejar recursos; tales como texturas, sonidos, mallas, bufferes, nodos, terrenos, etc...

Mi pregunta es: a la hora de hacer el diseño, que pensais? como definis que es lo que hace cada entidad, cual depende de cual, quien controla a quien, etc... Si por ejemplo una textura debe saber dibujarse o es el renderer el que lo sabe? o una mezcla de ambas? y si es asi, hasta que punto?
La respuesta facil es decir que se sabe con la experiencia, pero me gustaria ir mas alla y comparar diseños de la gente del foro, seguro que se puede reunir informacion y elaborar una especie de FAQ.

[Buffon]

Mi pregunta es: a la hora de hacer el diseño, que pensais? como definis que es lo que hace cada entidad, cual depende de cual, quien controla a quien, etc... Si por ejemplo una textura debe saber dibujarse o es el renderer el que lo sabe? o una mezcla de ambas? y si es asi, hasta que punto?
La respuesta facil es decir que se sabe con la experiencia, pero me gustaria ir mas alla y comparar diseños de la gente del foro, seguro que se puede reunir informacion y elaborar una especie de FAQ.

Todo depende de con que API vas a programar, por lo general DirectX y OPENGL tienen un Buffer donde almacenan las texturas, en Direct2D se llaman surfaces, y el COMO se dibujan, no lo saben las texturas en si, sino el propio render.

en opengl, tu creas una textura, y luego a la hora de pintar "render" la situas en los puntos de cada extremo de un cuadrado, pero el COMO se dibuja lo sabe el render en si.

el controlador, lo que se puede encargar es de recoger bien los datos, de comprobar que están correctos, y de pasarlos bien a las funciones.

hacer un engine es muy complicado, pide mucho trabajo, y hay cosas que las puedes especificar en "folio" llamalo UML usando ArgoUML o RATIONAL ROSE. pero luego, una vez estés programando, verás que hay cosas que las harás a "ojo" y que no pudiste predecir a la hora de planificarlo.

Así que suerte en la ardua tarea que llevas encima, y que te salga bien ;)

[Buffon]

 NOTA:

en Direct2D todos los sprites, sean texturas o no, se guardan en surfaces, y se muestran de la misma manera por pantalla, usando un valor keying :)

es que antes he puesto que eran solo las texturas :S

[[EX3]]

 Direct2D? No estaras hablando de DirectDraw, Buffon?  ;)

Generalmente el almacenamiento de graficos lo llevan ya programado las APIs como DirectX, OpenGL, SDL, etc... el motor en si solo deberia conocer el IDs de los graficos almacenados por la API. Luego, una textura en si solo seria un contenedor, yo no lo calificaria de entidad como tal, y por lo tanto no deberia saber si se ha dibujado o no por realmente tu dibujas una copia de ese grafico no el grafico original. De saber si se ha dibujado o no ya se encarga la funcion de dibujo para dibujar la textura o el propio renderizador del motor o la API.

Antes de nada deberias ver que necesidades requiere tu motor y a raiz de ello plantear el "FrameWork" para su desarrollo.

Salu2...

[tiutiu]

 Para mi el api grafico que uses es lo de menos (uso OpenGL). Lo abstraes mediante un proxy y todos llaman a sus funciones. El resto es lo que me interesa, que es lo que he expuesto en mi primer post.

[Thenend]

 Yo es que soy un ignorante en materia de motores gráficos, cuando tengo dudas miro el Ogre, pero la verdad es que para lo que estoy haciendo tengo un sistema cutre de render y me sobra. El objeto que se quiere dibujar manda al renderer sus grupos, que son estructuras con la informacion necesaria para dibujar una malla (punteros a VB, IB, textura, parametros de blending, matriz, etc) y él se encarga de ordenarlos y dibujarlos. Los objetos que se pueden querer dibujar, o están en el "mundo" y entonces éste es el que se encarga de decirles si están visibles o no, o están en el GUI. Otra cosa es que tengo dos listas de renderizado, en una los grupos opacos y en otra los transparentes, estos últimos se ordenan un número fijo de veces por segundo, ahora mismo 20 pero creo que con 5 o 10 no hay diferencia.

Otra cosa es la estructura del juego entero, con su estado de juego, su lógica, su entrada, su red, sus menus... ¿A nadie le interesa discutir eso? Siempre se habla del motor gráfico pero hay muchas otras cosas.

Sobre esto solo he encontrado el enginuity y poco más. Lo que estoy usando ahora es un objeto MessageManager al que tienen acceso algunas clases "coordinadoras" como pueden ser el Input, World, Logic... Estas postean mensajes para comunicarse y miran la cola a ver si tienen alguno para ellas. De esta manera me evito lios de punteros o de inclusión de cabeceras si usara un objeto que accediera a todos y fuera accedido por todos (aunque este igual es también un buen sistema). De paso también me sirven estos mensajes para el código de red, para guardar replays, etc. También tengo una especie de model-view-controller, es decir, la entrada, ya sea de red, de IA, del jugador local o lo que sea manda mensajes a la lógica de juego que los procesa y altera el estado de juego, éste manda mensajes al mundo (el objeto que representa el juego en pantalla, que en realidad pueden ser varios) para que se actualice en función de los nuevos datos. Y... bueno, ya me cayo, que me da la impresión que esto no le interesa a nadie   :P  

[tiutiu]

 Bueno, he comenzado a diseñar mi framework separandolo todo en subsistemas o modulos. Luego los diseñare uno a uno y al final se hara la codificacion. Voy a usar este thread para poner lo que vaya haciendo, asi podeis criticarlo.

He optado por hacerme preguntas e ir escribiendo las respuestas en mi pizarra. Algo asi como un bombardeo de ideas. Ademas puedo ir añadiendo cosas sin tener que llenar folios de tachones (uoh)

¿Que necesito para un juego? (Requerimientos principales)
-Timer, teclado, raton, menu, GUI, terreno, entidades (actores), ficheros configuracion, consola, sonido, particulas, triggers, memoria, recursos en general, video, ficheros, matematicas, fisica

A partir de ahi, he hecho un diagrama de como dependen esos requerimientos los unos de los otros para saber que modulos formaran el Base Layer. Me han quedado los siguientes modulos:
-Timer, memoria, ficheros, input, video, sonido, matematicas

El modulo de matematicas maneja vectores, matrices y datos basicos que muchas aplicaciones comparten y que rara vez cambian. No se si meter ahi los bounding volumes, ¿sugerencias?

Sobre esta capa se construye el gestor de recursos y la consola, que me servira para cargar ficheros de configuracion y modificar las variables de entorno que use el programa (mediante cvars). Quizas tambien seria conveniente meter aqui el modulo de fisica, aunque aun no lo he pensado mucho.


Bueno, esto es todo por ahora. Mi objetivo es diseñar un sistema modularizado, inspirado en la serie de articulos Code on the Cob, para aprender a separar un diseño grande (como es un juego) en 'cajas' de Pandora.