Gestor de escenas

[adrigm]

Crearemos un Gestor de escenas o estados que se fácil de intercambiar para representar diferentes estados de una aplicación como un menu, un mapa o una pantalla de puntuaciones.

[ficion]

Bueno, dado que va a ser un motor de juegos para 2D en general, se me es un poco complicado idealizar cómo será. Primero, ¿cómo son las Escenas? ¿va a haber un objeto Scene y el SceneManager se encargará de controlarlos? ¿O el mismo SceneManager agrupará objetos para crear la esencia de una Escena (que no un objeto)?

Aquí una pequeña (y bien rápida y mala) idea:

Una Scene está hecha de varios elementos: Fondo, Primer Plano (son dos elementos distintos), TileMap (cómo va a ir organizado un mapa el TileSet), Entidades (creo que se sabe bien qué son a estas alturas), Efectos (partículas, luces, etc), Sonido (música de fondo, efectos especiales globales y de un lugar en específico) y quizá más (¿GUI?, ¿Físicas?). He incluido un Canvas, porque en algún lugar las cosas tienen que ser dibujadas, pero no sé bien cómo lo haremos aún.

Podríamos hacer ficheros para los mapas, así cada uno de esos objetos ya mencionados, se cargarán desde un archivo, el cual contiene los datos (¿podría ser el formato de TiledMapEditor?: (La extensión .mst, viene de "MapSeT"; es sólo para ejemplificar)

Pero para eso también tendríamos que hacer un parseador de archivos, pero creo que es buena idea que todo lo que es tiles, variables, texto y vayan dentro dentro del mismo archivo, mientras que el sonido y gráficos (tilesets, sprites) vayan en otro directorio, de modo que en el archivo del mapa se le pase una referencia al nombre del archivo que se quiere usar.

Quiero aclarar que tengo poco o nada de experiencia en C++, así que tengo poca conciencia sobre un modelo de objetos, por lo que mi idea parece algo trucha, es normal. Pero también quiero tratar de revivir este tema, así que aquí doy mi idea.

[adrigm]

A ver, explico un poco como va este tema. Lo que tu propones es algo parecido a lo que esta ideado para la milestone 0.2.

En esta primera versión, las diferentes escenas tienen principalmente 3 métodos (tienen más, pero estos tres son los más significativos) que se ejecutan en el Game Loop: update(), event(sf:: Event e), draw(). El primero se usa para actualizar la lógica de la escena, el segundo recibe todos los eventos de SFML que no se manejen desde otro lado y el último se usa para dibujar la escena.

En la siguiente versión empezaremos a pensar en el modelo de Game Objects que vamos a implementar, siguiendo quizás una herencia de nodos donde a cada GameObject se le puedan enchufar nodos hijos.

Se eliminará el método draw en favor de métodos hide() show() en los objetos y pasando el engine la decisión de que se debe dibujar y que no. Así el engine optimiza evitando dibujar cosas que no están en pantalla y liberando de esto al usuario.

En cuanto a juegos basados en tilesets está claro que TiledMapEditor debe ser nuestro editor de mapas ya que es libre y crea un formato de mapa muy amigable. Se integrará un nuevo recurso para leer los .tmx de Tiled y clases para el dibujado de mapas, manejo de cámaras, etc.

Tambien sería conveniente integrar/hacer una biblioteca de Tweeners para el manejo de acciones fácilmente. Clases para facilitar el uso de Sprite y SpriteSheets, etc.

Cosas como la GUI o la física serán módulos independientes que se abordarán llegado el caso.

Como vemos hay muchas cosas que se pueden añadir, pero mejor ir paso a paso.

[ficion]

Ya veo. Me preocupaba lo del draw(), porque, tarde o temprano terminaríamos con un método que dibujara todo, indistintamente si se iba a mostrar o no. Definitivamente va a ser mucho trabajo, pero ya veremos.

Qué lástima que no sepa C++. :/

[RdlP]

Toma, te dejo unos apuntes de mi Universidad. Ahora los han cambiado con esto del grado, pero cuando yo hice el plan antiguo estaban bastante bien.

Cada tema tiene 2 partes (java y C++, antes dabamos C# también xD) deberías centrarte como es lógico en la parte de C++

http://dis.um.es/docencia/poo/wiki/doku.php?id=curso2010:grado:teoria

[ficion]

@RdlP ¡Muchas gracias!

[angelnavarro]

Gracias por el apunte @RdlP

[InExtremaRes]

Este es un tema muy interesante, al menos para mi. Yo estaba confeccionando (en C++11 eso sí) una máquina de estados finita que emitiera signals cuando se activaba una transición las cuales se podían conectar a un slot (función o método) compatible. Mi intensión era usarla tanto en las escenas, como en los distintos estados de un personaje (quieto, saltando, corriendo, etc), en los estados de un autómata controlado por IA, etc etc. Por supuesto, un sistema tan general se hace complejo rápidamente, pero creo que iba por buen camino. Solo tenía dudas con al sintáxis (quería que fuera sencillo, eficiente y a la vez de fuertemente tipado). Estaba incluso desarrollando un "parser/compilador" que traducía un archivo con sitáxis del tipo state1 -> (transition) -> state2 a código fuente en C++ que creaba una matriz de incidencia para implementar la máquina. Quizás ya hasta me estaba obsesionando un poco XD

Luego comencé a leer el libro SFML Game Development http://www.packtpub.com/sfml-game-development/book y ahí sugieren un modelo de máquina de estados basado en una pila. Es decir, en vez de tener un típico diagrama de transiciones, los estados se iban apilando y desapilando, y aunque lo normal era tener solo un estado en la pila a la vez (estado activo), permitía tener varios estados superpuestos y simultáneos, como el estado/escena "en pausa". Es un enfoque interesante, pero no sé si adapte completamente a este proyecto.

Además, creo que es un libro bastante recomendable (aunque en inglés). Uno de sus autores es el creador de la librería Thor que sirve como extensión a C++, seguro que muchos la conocen http://www.bromeon.ch/libraries/thor/

[rickyah]

Si por emitir signals te refieres a eventos a los que otros componentes pueden suscribirse, no es mala idea.

Sin embargo opino que ponerse a hacer hacer un Domain Language para una máquina de estados, implementando un parser y un compilador es matar moscas con bombas atómicas. Sería mucho más sencillo y útil integrar un lenguaje ya existente, que hay para aburrir (LUA, Javascript, ruby, python) y mucho mejor de cara a un posible aprendizaje. Pero aún así me parece una pasada para una máquina de estados.

El modelo de máquina de estados basada en una pila es lo usa cocoa Touch para gestionar las vistas y la navegación de las mismas y es fácil de implementar y sencillo de entender.

[Socrattes2099]

Una consulta, que notación se está utilizando para modelar el engine. A simple vista pareciese que fuese UML, pero veo que la flecha Scene (->) apunta a Canvas representa una relacion de herencia y no una asociación.

Sugiero utilizar una notación común y estándarizada como UML. Por otra parte en cuanto a herramientas he utilizado Visual Paradigm pero es comercial, teniendo por otra parte soluciones de codigo abierto multiplataforma como ArgoUML - http://argouml.tigris.org/ -, Papyrus UML para Eclipse - http://www.eclipse.org/papyrus/ - o no sé que otras recomiendan ustedes.

[rickyah]

No se está usando ninguna notación en principio. UML se va de madre para un proyecto como este, y en general para todos (hablo como opinión personal y después de haberlo usado, mucho, mucho. Para algo más detallado -> http://littletutorials.com/2008/05/15/13-reasons-for-umls-descent-into-darkness/) Para explicaciones si puede ser útil, pero para cosas muy básicas en general.

[ficion]

No usé ninguna notación en específica, lo siento, fue un ejemplo bastante desorganizado. Pero sí, deberíamos utilizar UML (recientemente descubrí qué es) y sería perfecto para que otros aprendieran más de esta notación. :)