Por si a alguien le interesa, yo he estado viendo cosas y deja el tema del scripting mas claro:

http://nwn.bioware.com/builders/sctutorial.html

Un saludo,
HexDump.

Jejejej, pues nada acabo de entrar ahora y me he quedado bastante sorprendido al ver que más o menos mis conclusiones finales se parecen bastante a lo que comenta tei.

Por una parte he decidio partir las distintas clases de entidades en 2 partes, una en C++ y otra en lua. En lua se van a encontrar los datos de la entidad como vida, velocidad, etc... Mientras que en C++ tendré una clase muy genérica, llamemosla actor. La clase de C++ será la que defina una serie de callbacks a los que llamará el engine cuando pase algo, como puede ser OnHit, OnDeath, etc... y estos llamaran a los que tiene cada entidad en script.

Durante el juego, el script o codigo de c++ podrán crear actores, al crearse se creara la clase de c++ que pedira que se cargue su parte de datos en lua, manteniendo ambas partes un ID para poder hablar una con la otra.

Alguna idea más? problema, etc...? Yo lo veo bastante bien.

Un saludo,
HexDump.

He, Tei, dices que no sabes mucho del tema y te sueltas unas parrafadas de la leche y además con sentido :D, que bueno.

A ver si alguien más se pasa y da nuevos puntos de vista, aunqeu ya te digo, el tuyo me parece muy logico en muchos aspectos.

HexDump.

Tei claro que has ayudado hombre, además me das distintos puntos de vista sobre esto, que yo no tengo.

Solo hay una cosa que no veo clara. Las clases de actores se definen complemtamente en script? y la factoria de esta tambien en script? Te lo digo porque si no es así siempre habrás de tocar C++ para añdir una entidad.

Entonces para resumir, lo q sugeris seríai algo así?:

1) Se escribe la clases de la entidad en script (declaración de clase y lógica).
2) Se tiene algo parecido a un factory de actores en script que se encarga de parsear un directorio de entidades y registrarlas.
3) Desde C++ se llama a createActor (una funcion en script) que a partir de esa factoría te instancia el objeto que quieres. y te devuelve su ID a C++ para poder usarlo en un getActor o algo asi (q no se i le va a hacer falta alguna vez ya que toda la logica se hace en script según esto). En este caso, estoy suponiendo que la gestion de entidades se hace en el script, que no se si es el mejor lugar para hacerlas vivir.
4) Si todo esto es correcot solo me queda como duda el tema de las colisiones/físicas. Yo quiero meter en las entidades desde escript cosas como OnHit(), OnDead(), etc... Que se tendrán que llamar desde un dispatcher, por ejemplo, yo uso newton como motor de fisicas, cuando se detecta que 2 se pegan se llama al OnHit() en script de los objetos.

Siento si me he liado y te estoy dando la paliza en demasía pero es algo que parece que tú tienes muy claro y yo lo llevo colgandillo :D.


Gracias por adelantado,
HexDump.

Gracias por las respuestas, y buen apunte el de Gdl. Por otra parte, Gdl, segun tu metodo, la creacion de actores estaría en lua, es decir tu desde lua vas cargando los actores que automaticamente se registran en c++ (o eso es lo que entiendo de lo que me has comentado). El tema es, donde deberian de estar las instancias de los actores en la cara de C++ o script?. Y nadie, ha comentado nada sobre el tema de tener esas 2 funcioncillas por actor.

Gracias por adelantado,
HexDump.

Hola,

Estoy diseñando en este momento el sistema de scripting para mi juego y la verdad veo tantas posibilidades que no acabo de concentrarme en un diseño decente para este.

Me gustaría que la gente que ya ha hecho previamente algo de esto me aconsejara, por cierto me he decantado al final por LUA + toLua++ por la comunidad tan arraigada que tiene (python no me interesa).

Aquí dejo unas divagaciones:

En principio el script lo quiero montar simplemente para configurar acotres en mi juego, algo que podría haber hecho tambien con un simple xml, pero ya que voy a usar el scripting para IA tambien lo uso para esto.

Tenía pensado tener un fichero .lua por actor y tener 2  funciones dentro, una de inicializacion que pasandole un ID hace una petición a la cara c++ y "setea" el objeto con sus valores por defecto, como, malla, energia, etc... La otra función sería una de IA que se llamaría desde el DoLogic de cada actor en C++ para ejecutar la IA del objeto.

Sería algo como esto:

en el fichero Orc.lua:

function Orc_Init(OrcInstance)
{
//Inicializar valores del orco
}

function Orc_DoLogic(OrcID )
{
//logica del orco
}

In c++:

en orc.cpp file:

Orc()
{
//Cargamos script

Script::Orc_Init(this);

//Lanzamos lo necesario para cargar recursos, com por ejemplo
//la carga de la malla que ha asigando el script a este objeto

}

void Orc::DoLogic()
{
Script::Orc_DoLogic(this);

}

Que pensais? alguna forma mejor de hacerlo?

Un saludo,
HexDump.

                                Bueno, en vista de que no posteo casi na en stratos, y como se me hechan al cuello en programacion de juegos (Repand  :P , etc....) he decidido hacer un post offtopic ya que estoy en examenes y ahora mi mente ta en otro lado.

Solo queria decir QUE YA ME HAN ARREGLADO LA GUITARRA!!!!, viva el servicio tecnico de Ibanez ;). Ahora solo falta que acabe de bajar el Killer licks del yngwie pa pasar unos ratillos bien y quitarme el mono de pogama xD.

Ala un saludo a todos los que me conocen, me da igual si son enemigos o amigos.... (de los enemigos ya te esperas lo que van a hacer pero los amigos son lo peor, siempre te pillan desprevenido xD).


RECLAMACION: Un emoticon con una lengua mas grande joer que este parece q se este riendo... y si puede sr de color verde pos mejor :).

HexDump. :oops:                                

                                Yo berseker creo q no es tan raro. Varios objetos distintos pueden usar la misma textura y los mismos render states, por ejemplo para simular cualquier tipo de material sobre ellos (metal de espadas, etc...). Una cosa que no me queda del todo claro son los render states, vosotros que pasa que ya exportais junto con el objeto la informacion de los render states que va a usar cada subset? (es decir cada parte que tiene una textura distinta, etc...?) o lo teneis "hard coded" en el objeto?.

Saludos.
HexDump.                                

                                Las ostia tio, que rapido contestas :sonriendo:, sorry por darte tanto la paliza. Por cierto, lo del drawprimitiveUp, ya me pensaba yo algo de eso. Lo mejor que sera crearse un vertex buffer fijo de un tamaño optimo para hacer batching y vas copiando los vertices e indices de cada grupo, colocas states y texturas y renderizas no?.


Again, gracias.
HexDump.                                

                                Berseker unas cositas mas.

Hablando en el IRC y discutiendo unas cosas hemos llegado a unas conclusiones. Mira ,tengo pensado hacer el renderer asi: Cada modelo mantendra una lista de vertices en memoria convencional (no VBs) y una lista de indices tambien en memoria convencional (no IBs). El caso es que cuando se tenga se llame al render de cada objeto se pase el puntero del objeto a la cola del renderer. En el objeto tambien se tiene el sistema q usa para renderizar los triangulos (strips, etc...) y los states. De esta forma el renderer cuando tenga q crear la escena, tomara los datos necesrios de cada modelo que hay en la lista, como numero de vertices, etc... y renderizara. Me mosquea que haya oido por ahi que mucha gente tiene un lista de triangulos en el renderer y no, referencias a los objetos, ya que de la forma que yo digo te ahorras copiar datos a la cola y necesitas menos memoria.

Nota: Para renderizar los distintos tipos desde memoria que tal DrawPrimitiveUP?.

No me contestes mu tecnicamente que soy palurdin :riendo:.

Gracias.
HexDump.                                

                                Mira Berseker, la opcion si no recuerdo mal la tienes en la pestaña de Packages y has de quitar lo de Build With runtime packages (la check box de abajo) de esta manera se linka todo estatico, tambien notaras un considerable aumento de tu ejecutable, unas 400 ks.

Si no recuerdo mal con eso esta todo, es que no puedo probarlo ya que justamente te das cuenta de si esta o no todo linkado cuando vas a casa de alguien que no tiene las libs :sonriendo:.

Ta luego.
HexDump.                                

                                Toy perdio, q estais de caxondeo o que :riendo:.                                

                                ummm, Berseker, no me pegues, pero q coño es un shader, al menos en la acepcion q tu lo usas, te refieres a textura?.

Otra cosa, seguramente sera por mi ignorancia, pero no entiendo bien la parte del final cuanto te refieres a ordenar por transformaciones, si yo tengo 2 cubos pues tiro a la lista los triangulos de los 2 y ya esta no?, no entiendo el problema, ya que yo ya mando alli los triangulso transformados. NO ME PEGUES EH? Q SEGURO Q HE DICHO ALGUNA BARBARIDAD :sonriendo:.

Gracias por contestar.
HexDump.


Nota: como te dije, tus tuts roooolllz :sonriendo:.


                               

                                Buenas gente,

desde hace ya algunos meses (desde q empece mi motor), he estado usando esta forma para renderizar mis modelos.

HRESULT CModel::Render()
{
       Codigo quitado...
       .
       .
       .

       m_pMesh->DrawSubset(0);      

   return S_OK;
}

como se puede ver, cada modelo se encarga de renderizarse y de mandar los triangulos a la tarjeta grafica atraves de un D3DXMESH.

Ahora que he empezado a rediseñar ciertos aspectos del motor, he creado unas clases q encapsulan carasteristicas de los objetos del engine, ya sea un ejemplo la CRenderable de la que heredan todos los objetos que puedan ser renderizados. Los problemas han llegado al empezar a incluir un manager de fonts y soporte de modelos md2 al motor, ya que este tipo de objetos estan basados en lista de triangulos, (bueno para los fonts podrian usarse strips sin problemas), asi que estuve pensando en hacer varias subclases q heredaran de CRenderable llamadas CMesh (que incluye un D3DXMESH q renderiza mallas indexadas), un CTriangleList, que renderiza listas de triangulos, etc... pero es un palo ya que necesitaria crear nuevas subclases para cada tipo de de dibujado de triangulo (strips, etc...). Asi, he decidio basar todo el motor en listas de triangulos y añadir un renderer y un puntero a una lista de triangulos a este, asi, los objetos al llamar a su render no mandarian triangulos a la tarjeta, sino que los mandarian a la lista de triangulos del renderer y luego la escena se crearia desde aqui. De esta forma se podria optimizar (o eso creo yo) el dibujado de la escena ya que los triangulos se podrian ordenar por textura, estados de render, etc.... Bueno que os parece? se suele hacer asi?. Algun tutorial sobre esto?

Gracias.
HexDump.

Nota: vaya tocho mensaje :sonriendo:.