Foros - Stratos

Programadores => General Programadores => Mensaje iniciado por: CoLSoN2 en 03 de Octubre de 2002, 03:22:15 PM

Título: Organizacion de clases
Publicado por: CoLSoN2 en 03 de Octubre de 2002, 03:22:15 PM
                                Bueno, tengo que organizar mi juego de alguna manera, y tengo 3 posibilidades (en este aspecto):
1º - Clases sueltas, y luego creas un objeto de cada y lo utilzas por separado en el programa principal (cVBuffer, cTexture, etc)
2º - 1 clase para cada "engine" del juego (cGraphics, cSound, etc) ke encapsula a las otras del mismo "campo". <- ahora lo tengo asi
3º - 1 Clase (cGame) que encapsule a todas las demas (ia sea en forma 2º o 1º)

cual usais vosotros? k ventajas/inconvenientes tiene cada una ?                                
Título: Re: Organizacion de clases
Publicado por: Frodrig en 03 de Octubre de 2002, 03:41:53 PM
                               
CitarBueno, tengo que organizar mi juego de alguna manera, y tengo 3 posibilidades (en este aspecto):
1º - Clases sueltas, y luego creas un objeto de cada y lo utilzas por separado en el programa principal (cVBuffer, cTexture, etc)
2º - 1 clase para cada "engine" del juego (cGraphics, cSound, etc) ke encapsula a las otras del mismo "campo". <- ahora lo tengo asi
3º - 1 Clase (cGame) que encapsule a todas las demas (ia sea en forma 2º o 1º)

cual usais vosotros? k ventajas/inconvenientes tiene cada una ?

Bueno, personalmente para hacer Crisol (puedes obtener el codigo fuente del motor en http://usuarios.lycos.es/crisolengine) cree una clase por cada subsistema. Estas clases a su vez actuan de Facade para cada uno de los demas elementos asociados a dicho subsistema. A parte, existe una clase denominada CCRISOLEngine que actua de Facade de todos los subsistemas.

La coordinacion de las diferentes clases (llamada al subsistema grafico para que haga render, al de sonido para que los reproduzca, etc) lo hago a traves de unas clases que representan los diferentes estados del juego y que son amigas de CCRISOLEngine para poder trabajar con los diferentes subsistemas pero de forma directa, pues los metodos que se ofrecen via interfaz siempre son de caracter general y no permiten, por asi decirlo, bajar a la "sala de maquinas" de la clase.

En fin, supongo que no me habras entendido muy bien, resumiendo:

Uso el metodo 2) para hacer modular el motor y poder trabajar entre subsistemas sin colision, pero acudo al 3) para mantener todas esas clases encapsuladas en un mismo sitio.

Un saludo.                                
Título: Organizacion de clases
Publicado por: NeLo en 03 de Octubre de 2002, 04:06:34 PM
                                Yo también tengo una clase CApp que controla a los subsistemas CRender, CSound, CInput...

Saludos.                                
Título: Organizacion de clases
Publicado por: Loover en 03 de Octubre de 2002, 05:50:07 PM
                                Nelo, ¿puedes mandarme un ejemplo de cómo lo haces? Quita todo el codigo que tenga que ver con tu motor y demás :). Solo quiero ver como se hace una estructura así... ¿utilizas herencia?

Si tienes tiempo mandamelo aqui: javidrislo@hotmail.com                                
Título: entiendo
Publicado por: CoLSoN2 en 03 de Octubre de 2002, 06:34:46 PM
                                Eso abia pensado Frodrig, tener una clase cGame que las maneje todas (mas que nada pq quiero hacer una especie de manejador de eventos, y acerlo de otra manera seria jodidillo..)
thx a todos =)