Programacion orientada a objetos par juegos

[pablo9891]

Basicamente como ya habia comentado en otros threads estoy por comenzar un nuevo juego, por lo que me interesaria que me den alguna sugerencia sobre el diseño orientado a objetos que deberia adoptar, por ejemplo tengo la idea de generar subsistemas de audio, video, eventos,etc. si me pudiesen dar alguna sugerencia o comentario sobre como diseñarlo me encantaria

[shackra]

lamentablemente nadie podrá ayudarte, ya que el diseño de las distintas partes que llevara tu juego solo podrás hacerlo tu, ya que tu escribes el código según tus necesidades. Lo que podrías hacer seria ir escribiendo en papel esbozos de ideas para tu juego y a partir de eso ir dividiendo los problemas a nivel de programación que te podría ir presentando tu juego y a partir de eso escribir el código que deseas.

[carlostex]

Hola, en términos particulares la arquitectura que tendrá tu programa depende mucho de tus conocimientos y habilidades, mas que nada la experiencia, también como dicen de lo que tu quieras hacer, en forma general te podría dar una orientación, es decir la forma en la que se constituyen las capas superiores de tu juego.
lo que dices esta bien, lo de los subsistemas es buena idea, una cosa que acostumbro hacer es crear clases altamente especializadas, es decir, tengo una clase actor, una clase actor pues es básicamente la información de un actor, posición, vidas, puntos,etc. He visto en algunos códigos que en el actor le ponen la imagen que debe representar, en lo personal no lo hago, por que considero que eso debe ser parte de un sistema de gráficos, lo que pongo en el actor es solo la referencia y se podría pensar que es lo mismo, pues en esos códigos que he visto también usan apuntadores para la imagen, la diferencia está en quien se hace cargo de procesar el gráfico, si lo hace el actor, es probable que por cada actor que tengas que cargar un gráfico, y si hay dos actores iguales ya duplicaste un gráfico, mientras que con el sistema de gráficos independiente hago que se cargue una imagen y la asocio a un actor, así cuando el actor se dibuja solo toma la referencia. Esto te lo digo por que quisas vega otra persona y te diga que no le gusta así, y lo haga de otra forma, pero al final el juego funciona. Entonces mucho depende de tus gustos y con lo que te sientas mas cómodo. Una forma de hacerte mas la idea de como poder crear tu arquitectura es viendo otros códigos, tanto de programadores noveles, como de juegos mas profesionales. Si lo deseas te puedo dar el link para descargar lo que tengo hecho y te des unas ideas de como lo podrías hacer. Esta en C++

[pablo9891]

dale, me encantaria,. particularmente estaba pensando algun diseño lo suficientemente comodo como para poder utilizar las funciones de los sistemas de graficos, audio, etc en el momento en que necesite

[carlostex]

ok, pues este es el comando(de svn):

Código: Seleccionar todo

svn co https://tank-war.svn.sourceforge.net/svnroot/tank-war tank-war

Por una parte es sencillo, por que el código no es excesivo, pero tampoco esta muy comentado, solo comente las partes en las que creí que despues se me podrían olvidar o revolver. Sin embargo podrás notar la forma en la que están las clases y también como distribuí los archivos. Lo que buscas está en el directorio include y src.

[.teri]

Toma tu tiempo en diseñar la arquitectura de tu motor para ser usada en el juego. El principal objetivo de este motor es evitar que reescribas otra vez el mismo código, o bien adaptarlo sin tomarte mucho tiempo para tu juego en particular.
Una regla que me aplico es "la memoria está para aprovecharla, no derrocharla". El ejemplo que te ha dado carlostex es muy claro: cargas una sola vez una imagen, asígnala ahora a cuanto personajes quieras. Puedes tener una imagen guay de 32 bits de alta resolución para un tipo enemigo, pero no vas a cargar esa misma imagen una y otra vez para cada enemigo que acabará con la vida de tu héroe, ¿verdad? Y por más que la ram sea más abundante y relativamente barata, quiere decir que podrás hacer más cosas gracias a la ram, no que la desperdicies. Con la misma memoria ocupada por un recurso repetidas veces, se puede dedicar para cargar sonidos, o texto, o lo que sea.

[Juanxo]

Toma tu tiempo en diseñar la arquitectura de tu motor para ser usada en el juego. El principal objetivo de este motor es evitar que reescribas otra vez el mismo código, o bien adaptarlo sin tomarte mucho tiempo para tu juego en particular.
Una regla que me aplico es "la memoria está para aprovecharla, no derrocharla". El ejemplo que te ha dado carlostex es muy claro: cargas una sola vez una imagen, asígnala ahora a cuanto personajes quieras. Puedes tener una imagen guay de 32 bits de alta resolución para un tipo enemigo, pero no vas a cargar esa misma imagen una y otra vez para cada enemigo que acabará con la vida de tu héroe, ¿verdad? Y por más que la ram sea más abundante y relativamente barata, quiere decir que podrás hacer más cosas gracias a la ram, no que la desperdicies. Con la misma memoria ocupada por un recurso repetidas veces, se puede dedicar para cargar sonidos, o texto, o lo que sea.

Ojo, es totalmente cierto esto, pero también depende todo de tus aspiraciones:
- si lo que te interesa es hacer más la parte del motor y subsistemas inferiores, creo que es recomendable hacer lo que te recomienda teri.
- Si tu proyecto no es demasiado grande y te interesa más hacer lo que es el juego en sí, te recomendaría que primero lo tengas funcionando, y ya luego te preocupes de optimizar las cosas que tengan que optimizarse

[pablo9891]

Basicamente mi idea es la de hacer el juego, tal vez no me exprese bien al decir que lo que queria hacer era un game engine, lo que quiero hacer es un juego sencillo, como esos en los que con una bola vas golpeando los bloques y estos van desapareciendo, yo se que lo que necesito es una barra que se mueva, una pelotita y bueno, ya vere como trabajo con las barras que s emantienen estaticas, pero como separo todo es del sistema que controla el juego, es decir el sistema de audio, video, fonts, y como logro que se relacionen entre si??, esa es mi principal duda, lograr una forma lo suficientemente sencilla para que se relacionen estas dos partes

carlostex muy interesante tu codigo, basicamente vos lo que haces es dividir el codigo que le va sa dedicar a todo lo que es el sistema SDL, y lo que son los actores en los headers game y esena respectivamente, y a partir de ahi que es lo que haces despues, como los relacionas?

[carlostex]

Bueno, la forma de hacerlo pues es siguiendo el esquema de orientación a objetos. es una buena pregunta, en uno de los libros de sdl que esta en esta página se hace al final un juego 1945 el clásico de aviones, creo que a ese tipo de estructura se refiere Juan, es un juego sencillo, y es fácil ver que se hace en el main y como se van llamando las funciones que mantienen el juego, pero ese esquema para un juego mas grande sería muy engorroso a mi parecer. Regresando a lo que me preguntabas, bueno cuando empecé el juego fue de la forma como el 1945 del libro, declare funciones para mantener el cuadro y los actores, era casi todo estructurado, luego me di cuenta que me acomodaba mas la forma un motor, un motor para ese juego, lo aclaro por que no es lo mismo que el motor de pilas que trae un montón de cosas. Mi motor trate lo necesario para el juego que tenia pensado, pero claro al ser un motor es muy general y puedo hacer con el otro tipo de juego, quizas un RPG, uno tipo Mario bros, pero no implementa un motor de física por que no es necesario, en cambio pilas mientras mas general sea mejor.Me desvié un poco jeje, pero bueno, la forma que lo junto es llamar a las clases que necesito, si quiero crear un actor pues lo creo al inicio del programa, le puedo dar una velocidad y se ira moviendo cada que pase un frame sin hacer nada mas, pero si quiero detectar una colisión pues tengo que meter el código en el bucle principal donde llamo a las clases que ya cree para ver si un objeto choca con otro.

Quizás si miras los ejemplos que tengo te des una mejor idea, están en la carpeta test, son tres checate el que dice debug, es muy simple, pero aí se ve el uso del motor, lo que hago es incluir hai todo el motor, por que lo compilo como un biblioteca dinámica, puede parecer ciertas cosas engorrosas, sobre todo la parte en la que defino unos puntos ya lo veras de referencia en cada actor, pero no termine de afinar muchas cosas, básicamente lo que tengo son ideas, que funcionan pero les falta un poco de código para que queden mejor, por que si no defino esos puntos los actores no aparecen, ya que el gestor de gráficos no los dibuja.

De hecho la parte que puede ser mas compleja no es como interactúa la lógica del juego con el motor, por que como te digo solo es ir instanciando objetos según necesitas. En cambio la interacción interna del motor puede ser un poco compleja, en mi caso como ya viste para cada módulo(actores, gráficos, efectos, sonido, etc) tengo creado un manager, y la idea es análoga a la de un jefe de un departamento, organiza a sus subordinados y mantiene la comunicación con los demás departamentos si es que lo necesita, y un director que se encarga de pedirle a los jefes las tareas que requiere de ese departamento, y el cliente en este caso la lógica del juego o el que lo programador hace peticiones al director.
La biblioteca del motor está preparada para ser importada en un script de LUA lo que permite un desarrollo mas fácil si no se quiere usar C++.
Saludos, y cualquier dudad del código intentare responderla en cuanto pueda.

[pablo9891]

A proposito del libro que nombras, lo lei, pero se me hizo bastante vueltero en algunas cosas del diseño, por lo que prefiero diseñar algo propio. como vos bien decis me gusta la idea de una jefe de departamento, esos managers que vos tenes serian pro ejemplo el header esena.h??, estoy tratando de conectar lo que me decis con el codigo que tenes, entonces cada vez que la logica del juego necesite algo esta se lo pedira a algun objeto de la clase esena y esta a su vez accedera a las clases correspondientes de las cuales se proveera para llevar a cabo la tarea

[carlostex]

Es correcto lo que dices, en la clase game, que vendría siendo la clase maestra de la cual se accede a todo, tiene una función update, esta función se encarga de hacer un apdate a todas los demas managers, por ejemplo el de animación y a una clase que controla las colisiones, pero no actualiza a todas, por que hay clases que solo sirven al inicio del juego o bien, son llamadas al realizar alguna tarea. De hecho si te fijas en la clase escena puedes ver como se realizas las tareas, como esto lo hice pensando en la implementación en LUA, todo lo que se permite hacer se encuentra implementado mediante funciones en escena.h, de ahí se va bajando a las demás clases para que permiten cumplir la tarea, es decir si quieres comenzar leyendo el código es en esena.h donde debes comenzar, hay un archivo arriba de esena.h en la jerarquía es game.h, pero este solo se encarga de inicializar el vídeo y de renderizar la escena. No todo lo que puede hacer el motor esta en esa clase, aveces en los programas test he tenido que acceder a las clases manualmente, estoy consiente que la manera en la que se hace funcionar al motor es un poco engorrosa, me gusta mas una como el estilo de pilas, que es instanciar objetos en el script.

[pablo9891]

Basicamente mi idea para este nuev juego, seria tener una clase para los graficos, de la cual posteriormente se derivarian los personajes del juego, tambien me interesaria tener una libreria donde estarian todas los subsistemas que necesitaria, en el main tendria ambas librerias y clases relacionadas, y las clases de los personajes estarian relacionadas con la clase de los sistemas, esa seria mi idea por el momento

[carlostex]

Por que no empiezas a escribir algo de código, lo que se te valla ocurriendo y nos lo muestras para darte algunos consejos, puedes empezar por el sistema de video y después con los actores. con eso pronto veras algo en la pantalla, y ya cuando lo tengas será mas fácil seguir el esquema de desarrollo que haya quedado

[pablo9891]

Lo que voy a comenzar haciendo es definir algunas clases en un diagrama de UML, las mas basicas y una vez hecho eso voy a comenzar con la programacion

[danielpuch]

Carlos, me voy a meter a chusmear tu codigo.

Es que me gustaria aprender C/C++ mas adelante, por ahora estoy en python/pygame pero me interesa el tema.