Bueno, como supongo que ya os habreis dado cuenta, hay una ingente cantidad de personas haciendo un motor 3D en este foro.
Se me ha ocurrido que podiais contarnos la forma en la que lo habeis diseñado, la jerarquia y tipo de clases, peculiaridades, etc...
Yo llevo bastante tiempo con mi motor, pero nunca termina de convencerme la forma en la que lo estoy haciendo, y pierdo mas tiempo en cambiar estructura que añadiendo cosas en si.
Actualmente meto todo el engine en una .dll que contiene clases "sueltas" que no heredan unas de las otras, asi tengo las tipicas CWindow, COpenGL, CImage, CTexture, etc etc
El echo de usar clases "sueltas" me gusta por que el "usuario" del engine podria crear tantos recursos de cualquier tipo como quisiera (más de una ventana, por ejemplo, más de un renderizador, etc) Pero por otro lado esta independencia en las clases complica la forma de comunicarse e intercambiar datos entre ellas...
Hay gente que prefiere englobar todo en una clase singletone CApp o similar, y hacer un sistema menos flexible en cuanto a libertades para crear objetos de cualquier clase.
Quiza mi problema es que me empeño en hacerlo todo en riguroso C++ (Uso clases absolutamente para todo) cuando deberia mezclar más...
De que forma diseñais vuestro engine y por que?
Saludos!
P.D: Links sobre diseño de motores?
Creo q no se referia a ese tipo de motores , no crees ? :D :D
Bueno , q yo recuerde asi por encima esta web trata sobre el diseño de un motor , pero repito , creo . :o
http://www.wild-magic.com/Engine.html
Jejeje, efectivamente los motores de gasolina o diesel no son los que me interesan, aun asi aprecio tu aportación Mars Attacks :P
El OGRE ya le conocia, pero no sabia que en la web explican toda la jerarquia de clases y el diseño...
Respecto a la de Capiflash, no la conocia, y parece buena.
Gracias a ambos.
Por cierto, alguien por aqui ha implementado sistemas de Scripting en su motor?
Bueno , para lo del scripting , aqui hay uno q va por capitulos , explicandolo mas o menos .
http://www.peroxide.dk/Espero q t sirva , un saludete 8)
en cuanto al motor, este tambien esta bien
codigo fuente incluido :)
http://www.fly3d.com.br/tiene un monton de tools, como exportadores para el max, bsp, etc...
Gracias a Grungorr, Capiflash y CordayUK (ese avatar tuyo desconcierta a cualquiera... :P)
Estuve mirando el famoso LUA y algun que otro más sistema de scripting, pero puesto que de momento no pretendo hacer nada complejo, me gustaria más hacerme un sistema de scripting propio y simple.
Mirare los links!!
Alguien que haya echo algo similar... ¿Hasta donde se supone que debe llegar el script? Osea, si vas a hacer todo en un script, desde iniciar la ventana a cargar las texturas, para eso lo pones directamente en un .cpp y listo :P
¿Que es lo que se supone que te debe dejar hacer un script, y para que es logico usarlo?
Sé que pregunto más que los tontos, pero estoy dando rienda suelta a mi curiosidad, contenida durante años (Alguno podria dar fe de ello) :P
Te dí el link al crisol Engine. Implementa su propio lenguaje de script, simple y potente. Échale un ojo, aprenderás mucho y tienes todo el código y demás. Código muy bueno y bonito ;)
Hola.
Desde mi punto de vista es más complejo hacerte un sistema de scripting propio que usar LUA, cuando este es muy simple de usar en un codigo c/c++.
El uso del script es el que tu le quieras dar, pero está fuertemente orientado a usarlo en la "programación lógica" de algo, ya sea el comportamiento de diversos objetos segun que acciones se realizen y cosas asi. Yo en mi caso lo uso para programar el comportamientos de objetos y personajes en una aventura gráfica. Si haces click con el boton izquierda, derecho, si entras en una habitación, si sales, si usas un objeto con otro,etc... Ese es el tipico uso del script.
Aunque logicamente, también lo podrias usar para programar un juego entero, otorgando funciones de tu engine que se encarguen de iniciar,dibujar,etc... Pero esto último, creo que es mejor hacerlo directamente en codigo c/c++.
Si quieres información de LUA, mas que la oficial (que es un poco caca), leete el "mailing list" y bajate algunos codigos que hay en la seccion de proyectos.
Chao.
O2,
Qué uso vas a hacer de tu engine 3D?
Algo comercial o es pura diversión?
Saludos
--------------
Jabb
Jabb, en principio por diversión, y por aprender :)
[Over] : Precisamente por el echo de querer aprender prefiero implementar un sistema propio que usar LUA, aunque no se que ocurrira al final :P
Grugnorr : Lo del Crisol Engine me sera muy util para ver como funciona su sistema de scripting!
Ya os ire contando, Muchas gracias!
umh, yo pillaria los fuentes del unreal y me miraria el diseño de las clases, a mi me parece bastante acertado. saludos
Observa la naturaleza y crearás tu propia estructura de clases de la forma más adecuada. La fuerza está contigo joven SkyO2Walker.
Ioda
offtopic: no sera skyO3walker ? :D
Bueno, respecto a la jerarquia de clases, creo que por fin he encontrado una manera que (de momento) me convence...
ethernet: ciertamente el codigo del unreal parece bien estructurado y es agradable de leer, gracias por el consejo, la verdad es que si me ayudo :)
Leyendo ayer el articulo de nuestro compañero Consolcete en Edevi, titulado "¿Somos programadores de juegos o de engines?" la verdad es que en parte me senti bastante identificado...
Lo cierto es que hay una gran diferencia cuando se programa un engine pensando en el uso exacto que se le va a dar (Osea cuando se programa un engine sabiendo que se usara para un determinado proyecto) y programar un engine de proposito general
En este ultimo caso, el echo de pensar que tu engine puede ser usado por terceros (cuando nunca termina siendo asi :P) condiciona mucho el desarrollo, haciendote incluir opciones estupidas que retrasan el desarrollo, y forzandote a darle al motor una robustez mayor (como si los programadores que fueran a usar tu engine fueran imbeciles) que puede reflejarse en un rendimiento menor.
En al primer caso que expuse, hacer tu engine sabiendo para que lo vas a usar, programas exactamente lo que necesitas, y sabes lo que debes y no debes hacer para que el engine no pete... ahorrandote tiempo, dolores de cabeza y algunos otros males.
La verdad es que el dichoso Colson me hizo pensar... :P
Realmente es tan diferente la forma de desarrollar y trabajar con un engine de proposito general a uno desarrollado para una tarea concreta?
CitarLa verdad es que el dichoso Colson me hizo pensar...
rocks! ;D