Ligeras dudas en la programacion de la logica de un juego

[[EX3]]

Wenas, gente.

Hoy estaba hablando con un compañero que es tecnico programador con muchos años de experiencia a sus espaldas y, como no, como en el fondo tambien le gusta el mundillo este pues ha salido el tema de los juegos :lol:

Nunca ha tocado el tema en cuestiones de diseño o programacion de juegos y habiamos empezado hablando por encima de la teorica estructuracion de un juego sencillo, sus supuestas clases y forma de organizar los objetos, etc... hasta ahi bien, tuvimos algunas discrepancias en cuanto le hable de la mecanica bucle principal, de lo de dividir logica por un lado y lo grafico por otro (yo al menos suelo hacerlo asi) y el tema es que me ha despertado dudas justo en la programacion de la parte logica del juego. Os explico.

En mi proyecto por ejemplo, el TLSA, tengo pensado o bien crear una coleccion de objetos o clases generica que representan las entidades (jugador, enemigos, items, triggers...), objetos con metodos y propiedades comunes pero con diferencias internas, y o bien clasificar quizas cuales estan activos en la escena a ejecutar (mi juego seria como un flashback, escenas sin scroll, "pantallazos" dicho coloquialmente) para luego recorrer dicha coleccion y llamar a sus metodos Update() por ejemplo.

La otra forma que me planteo como alternativa seria crear una coleccion de objetos por escena, con los objetos que esten asociados a dicha escena (cajas, barriles y objetos que reaccionen a explosiones o disparos o cualquier otro evento, enemigos fijos...), y solo ejecutar las entidades de la escena que se ve en pantalla, siendo asi menos el numero de elementos a leer en el bucle principal y solo un numero reducido de entidades a ejecutar permanentemente (player, npc's, enemigos moviles, elevadores... )

Mi compañero aun asi, basandose en su experiencia programando, no cree que actualmente los juegos ejecuten secuencialmente las entidades en el bucle, sino que cada entidad se lanza en un hilo independiente para ejecutarlos en paralelo, cosa que yo al menos tengo entendido que no se hace aunque en verdad no lo tengo del todo claro (quizas si sea asi como se haga actualmente en ciertos juegos donde se mueven gran cantidad de entidades y yo no lo sepa todavia). Segun el, si ejecutara secuencialmente las entidades, como sabria en que orden deberia hacerlo para hacer una ejecucion "coherente"?

Aqui esta mi duda que hasta hoy no me habia planteado ya que no he llegado todavia a dicho punto en el desarrollo del juego. Me gustaria saber de mano de los que ya llevais unos cuantos juegos a vuestras espaldas como implementais o diseñais la parte logica del juego para asi poder aclararme un poco el tema y no hacer una posible chapuza que no rinda en condiciones luego.

Salu2...

[bnl]

Yo lo hago como tu, no utilizo un hilo para cada entidad. Y no se hasta que punto eso seria viable o positivo. No creo que tuviera un mejor rendimiento tener muchos hilos ejecutandose en paralelo. Supongo que para gran cantidad de entidades el rendimiento bajaria ya que gestion de cada hilo implica un coste adicional.

Yo los hilos los he utilizado para realizar tareas asincronas que requieran bastante tiempo, por ej operaciones de IO.

[Zaelsius]

Un hilo para cada entidad!? Nah. Aun pudiendo, las desventajas y problemas de la gestión de los hilos son mayores que las de las posibles "ventajas". Al menos, en los lenguajes estructurados de hoy en día. Otra cosa es usar un lenguaje de script que simule el comportamiento de un hilo para cada entidad.. pero esto ya es otra historia.

Volviendo al tema, deberías procesar todo desde el bucle principal. Está claro que es mejor si sólo actualizas los objetos activos o que pertenezcan a la escena actual, pero dada la estructura de tu juego(a pantallazos), esto debería ser algo trivial.

Quizá por ello deberías plantearte el diseño interno a partir del nivel más elevado, que sería una escena o "pantalla", y entonces ir descendiendo hasta las entidades(objetos, como trampas, puertas,etc). Si partes diseñando desde abajo luego tendrás más dificultades para ordenar, clasificar y establecer conexiones lógicas entre todas estas entidades dentro de tu mundo virtual.

[TheAzazel]

Desde luego el futuro ira hacia usar varios hilos pero para un juego normal y corriente es un poco locura... porque? porque sincronizar todos los hilos puede llegar a ser un trabajo de locos, evitar deadlocks y demas... puff... demasiado, creeme :)

[[EX3]]

Un hilo para cada entidad!? Nah. Aun pudiendo, las desventajas y problemas de la gestión de los hilos son mayores que las de las posibles "ventajas". Al menos, en los lenguajes estructurados de hoy en día.

Desde luego el futuro ira hacia usar varios hilos pero para un juego normal y corriente es un poco locura... porque? porque sincronizar todos los hilos puede llegar a ser un trabajo de locos, evitar deadlocks y demas... puff... demasiado, creeme :)

Algo asi me suponia y mas o menos trate de explicarle, pero el se empeña que en teoria deberia ser asi, supongo que por el que vera mas logico la ejecucion simultanea de las entidades, mas o menos como la vida real, que en secuencia por un orden.

Volviendo al tema, deberías procesar todo desde el bucle principal. Está claro que es mejor si sólo actualizas los objetos activos o que pertenezcan a la escena actual, pero dada la estructura de tu juego(a pantallazos), esto debería ser algo trivial.

Quizá por ello deberías plantearte el diseño interno a partir del nivel más elevado, que sería una escena o "pantalla", y entonces ir descendiendo hasta las entidades(objetos, como trampas, puertas,etc). Si partes diseñando desde abajo luego tendrás más dificultades para ordenar, clasificar y establecer conexiones lógicas entre todas estas entidades dentro de tu mundo virtual.

Tal y como tengo diseñado ahora mismo, el motor maneja una clase (o trata de simular una superclase en VB 6.0) que es la que gestiona recursos como las colecciones de texturas y sus texturas, y procesa las escenas y su contenido (de momento solo los tiles que forman las diferentes capas). Digamos que este esquema definiria un poco el como esta funcionando el motor:

Código [Seleccionar] Expand

// Resumido:
Bucle principal
{
   Motor.Update() // Gestiona toda la logica: actualiza valores, ejecuta entidades, etc...
   Motor.Draw() // Gestiona todo lo grafico: dibuja todos los elementos de la escena actual
}

// Detallado:
Bucle principal
{
   Motor.Update()
   {
       Input() // Lectura del teclado, raton, gamepad...
       Ejecutar entidades (sin implementar)
       {
           Bucle #i lista Entidades
           {
               World.Entity(#i).Update() // Ejecuta cada entidad de la lista global (player, enemigos persistentes, ...)
           }
           World.Room(#actual).Update() // Ejecuta las entidades fijas de la escena (cajas, enemigos fijos...)
           {
               Bucle #i lista Entidades de la escena
               {
                   World.Room(#actual).Entity(#i).Update()
               }
           }
       }
   }
   Motor.Render()
   {
       World.Room(#actual).Draw() // Dibuja la escena actual
       {
           World.Room(#actual).DrawBackground() // Pinta el grafico de fondo de la escena si esta tiene asociado uno
           Bucle #i lista Tiles
           {
               World.Room(#actual).Tile(#i).Draw() // Pinta la textura asociada al tile
           }
           Bucle #i lista Entidades de la escena
           {
               World.Room(#actual).Entity(#i).Draw() // Dibuja cada entidad fija de la escena que son visibles o fisicas (triggers y similares se omiten)
           }
           World.Entity(#i).Draw() // Dibuja todas las entidades persistentes que son visibles o fisicas
       }
       Mensajes en pantalla() // Textos y mensajes
       Graphics.Present() // Envia la informacion a la tarjeta
   }
}
Seria una gestion jerarquizada del motor (un bonito intento de POO en VB 6.0) y todo tirando desde el bucle principal de la forma que comente, logica por un lado y graficos por otro.

Yo los hilos los he utilizado para realizar tareas asincronas que requieran bastante tiempo, por ej operaciones de IO.

En realidad, para lo unico que tenia pensado usar hilos (mejor dicho, Timers desde el API de Windows ya que los threads desestabiliza mucho a VB 6.0) es para poder crear una pantalla de carga fluida graficamente, osea un hilo en cliclo cerrado gestionando la carga de recursos y otro independiente ejecutando una animacion o efecto en la pantalla acorde al porcentaje de carga por ejemplo.

Sobre el orden de ejecucion de la lista de entidades, aplicais alguna prioridad en alguna entidad concreta como podria ser el player o no seria realmente necesario?

Salu2...

[Lex]

...

[[EX3]]

Respecto el orden de ejecución de las entidades, eso ya es un tema de cada uno y la situación. En un juego de estilo Flashback o Prince of Persia clásico, tienes que ver si vas a permitir que un enemigo, una vez te vea y se encabrone contigo, se ponga a perseguirte por el mundo del juego. Porque en el caso de, esta es mi pantalla y de aquí no salgo, pues sería fácil controlar las entidades, para no mirar todas las del juego. Pero eso sería un poco forzado, lo suyo sería coger y plantear que en circunstancias normales, sin ningún enemigo en alerta, solo actualices los que estén en la pantalla actual. Pero, cuando un enemigo se ponga en modo de alerta, pasarlo a una lista especial, igual que los disparos, para que pueda avanzar por todo el mundo persiguiendo al jugador.

Entoces no iba tan mal encaminado con la idea utilizar listas locales para cada escena y una lista global para las entidades persistentes :)

Salu2...

[TheAzazel]

Aprovechando la cobertura... un adelanto de los juegos futuros:

http://www.anandtech.com/tradeshows/showdoc.aspx?i=2841&p=2

sinceramente, si conseguen hacer ese engine... yo se lo compro y me dedico a programar solo juegos y paso de librerias/engines porque eso ya es un trabajo de mucha gente :)

Saludos