Algúna novedad al respecto? Se puede hacer ingeniería inversa del dll ya que no está "obfuscado" pero sería más cómodo contar con los source files directamente ...
A ver si podemos sacarlo con la versión que salga a finales de Abril. El problema es que cambiamos tantas cosas que no hay nada afianzado, y si sacamos el código la gente ayudará, pero luego tendremos que decirle que todo eso se ha reescrito y que no sirve...pufff
Ahora mismo he reescrito de nuevo el render pipeline, antes era orientado a mesh, ahora orientado a material...
Hola!
eeeh, que la IA si está liberada! No le intereso a nadie :( Aquí solo se piensa en los gráficos :(
Un saludo! :P
Vicente
Cita de: "Vicente"Hola!
eeeh, que la IA si está liberada! No le intereso a nadie :( Aquí solo se piensa en los gráficos :(
Un saludo! :P
Vicente
Yo si le heche un vistazo ;)
:D
Cita de: "Haddd"Ahora mismo he reescrito de nuevo el render pipeline, antes era orientado a mesh, ahora orientado a material...
Pregunta de curiosidad teórica: ¿qué ventajas trae renderizar por material en vez de por meshes?
pues que hay muchos menos cambios de shaders. Como cada material es un shader, es más óptimo renderizar así que renderizar por mesh, e ir cambiando de material cada vez.
Lo habia indicado hace tiempo en otro hilo, realizar cambios de estados en el render y en los shaders de direct3d es lentisimo, la mejor solucion es renderizar por material como dice haddd y haciendo un administrador de estados para el render y los shaders, puedes llegar a ganar mas de 1000 fps (por lo menos en mi tarjeta grafica), puedes probar todo esto en un ejemplo del sdk de direct3d, se llama "SateManager".
PD: Como puntilla decir que opengl para esto es muchisimo mejor ya que realizar cambios de estados en opengl no baja tanto los fps, en mi humilde opinion esto es debido a que las llamadas a una libreria son menos pesadas que a objetos COM, ¿alguien sabe si es por otro motivo tal vez? saber la causa del problema puede ayudar a dar mejores soluciones ;)
bueno, zuper. Te diré que he probado poniendo y quitando el StateManager y me va más rápido a veces sin el StateManager...Supongo que será cosas de MDX, pq yo depuro y voy viendo como llama a las funciones del effect y es todo correcto, pero se ve que por alguna razón lo ralentiza....
Me imagino que te ira sobre ~10 fps mas lento, el motivo es por que no dibuja muchos materiales distintos, si dibujara 100 materiales distintos por ejemplo, algunos de ellos tendrian los mismos valores en algunas estados y es cuando se ganaria velocidad, si tienen todos diferentes estados se pierde algo de velocidad por la comprobacion previa que se hace para saber si ha cambiado o no su valor.
Explicacion mas esquematica:
- El orden de materiales: Selecciona el material una vez y renderiza todas las mallas con lo que se gana mucha velocidad.
- El administrador de estados: Solo se usa cuando se cambia de material con lo que solo gana velocidad si los materiales tienen estados parecidos, es decir, si el material madera tiene el color 255 y el material que se va a seleccionar despues de el tiene el mismo color se ganaria velocidad ya que ese estado no se cambiaria, si es diferente se pierde algo de velocidad con este administrador ya que hemos hecho una comprobacion previa para saber si ha cambiado o no (osea un if). Otra ventaja del administrador de estados es que al tener memorizados los estados en un array o variables sueltas nada mas que se pierde el device podemos restaurar los estados previos automaticamente y con el mismo codigo siempre.
A mi me gusta mucho usar los dos sistemas ya que cuando se tienen escenas muy complejas puedes llegar a ganar muchos fps.
;)
Gracias por las explicaciones.
Por cierto: cuando el código esté disponible prometo que me registro al foro ... :D
Con lo majos que somos en el foro, deberías registrate antes :P
Un saludo!
Vicente
Novedades?
Pues ahora hay mucho más código por la IA de Vicente... :P
Pero bueno, yo he documentado un montón. Espero que pronto podamos sacarlo...
Hola,
yo por mi parte voy a terminar los namespaces que utilicé para la demo de IA de la conferencia y subo una nueva versión del código con la demo. Me queda bastante trabajo sobre todo en HadddEngine.AI.Navigation, los demás están bastante bien, pero ese tiene currela aún.
Espero tardar alrededor de 15 días, pero ya sabemos todos como es esto ;) Un saludo!
Vicente
Hola, primero quiero felicitarlos por la engine!!. estoy trantando de hacer herramientas, especificamente un editor visual, templates de codigo ( T4 para GAT ..) y soporte de scripting para su engine!!, como veran me gusto mucho y estoy decidido a trabajar con ella!!, pero tengo un gran problema y es que probe todos los decompilaores que encontre para tener el codigo fuente compilable y ninguno obtiene los fuentes sin errores.
Es posible que me facilite los fuentes por mas que luego los modifiquen. Los necesito para probar pequeños cambios y sugerirles mejoras que necesito para poder implementar las herramientas que les comentaba.
Mi idea es que cuando las herramientas comiencen a estar funcionales publicarlas en alguna pagina web.
Aspiro a hacer algo similar a Visual3D Architect .Net pero que trabaje con su engine Haddd.
Saludos Matias
PD: para dar soporte a Visual Studio 2005 Express implementaria tambien los templates de codig opara uso de Haddd con NVelocity, ya que creo que GAT que es lo que usaria en un comienzo ( T4 ..) es para VS 2005 Standard o superior..
Espero que me puedan dar acceso a los fuentes asi aanzo con estos proyectos.
Saludos Matias
Hola!
tengo que reconocer que lo del NVelocity, GAT y T4 esos no me he enterado de nada :P
Respecto a los fuentes: como siempre hemos dicho la idea es liberarlos, pero el trabajo de avanzar en el motor y a la vez documentar las partes viejas se hace muy pesado (además que siempre mola más hacer cosas nuevas que documentar). Como ya nos hemos pegado muchas tortas diciendo fechas, de momento no comentamos nada: cuando esté se pondrá.
Respecto a darte acceso a los fuentes, ni idea, Haddd te comentará, pero creo que seguramente preferirá que esperes hasta que lo lancemos en general, porque a veces en la documentación se reescriben algunas cosas, y mantener 2 versiones (la tuya y la nuestra) iba a ser una locura.
De todas formas, me tienes intrigado, que son todas esas cosas que comentas? ;) Un saludo!
Vicente
Estaria bien que nos pusieras algun link a NVelocity, GAT y T4, ya que yo tampoco tengo ni idea de que es eso, aunque esta claro que es para c-sharp.
Lo unico que encontre fue esto:
NVelocity,
T4 y GAT, no se si los links son correctos o son cosas que se llaman igual.
PD: Ya sabeis que aunque no este activo actualmente en csharp todo lo de este lenguaje me interesa :rolleyes:
Hola a todos, el ink de zupervaca de NVelocity es correcto, y agrego links al GAT ( GAT = Guidance Automation Toolkit):
http://www.guidanceautomation.net/cs/default.aspxhttp://msdn.microsoft.com/vstudio/teamsyst...at/default.aspxEl GAT es mucho mas amplio que NVelocity.
NVelocity es una libreria que permite generar codigo mediante templates, yo la conoci trabajando con una libreria de persistencia de objetos , NEO ( net entity objects)
http://neo.codehaus.org/ y relamente me parecio aceptable y facil de usar.
Respecto a GAT, GAT es una herramienta mas avanzada y mas completa, una de sus caracteristicas es la de generacion de codigo ( mediante templates T4) , pero tambien permite incluir Wizards, Templates de proyectos y automatizar casi cualquier tarea de programacion dentro del Visual Studio. Claro siempre el grado de automatizacion dependera del tiempo que empleemos en desarrollar las herramientas basadas en GAT.
Todo lo hecho con GAT se integra al Visual Studio, por lo que finalmente obtenemos al utilizar GAT es un Visual Studio con un monton de herramientas para (en este caso.. :-) ) hacer desarrollos que utilicen la engine.
El unico problema que tiene GAT es que requiere Visual Studio Standard o superior, por eso pienso implementar tambien templates basados en NVelocity para aquellos programadores que usen Visual Studio Express.
Saludos Matias
PD: Un desarrollador de GAT me comento que es muy probable que el GAT sea parte del nuevo visual studio ( Orcas .. se llamara asi no el nuevo visual studio??... me confunden los nombres que ponen a veces la gente de Microsoft a sus proyectos mientras estan en desarrollo, por que la mayoria de veces los terminan cambiando en el producto final :-) )...
Yo actualmente estoy utilizando GAT en un proyecto basado en el CAB.. alguien conoce el CAB ? :-)
les paso otro link por si les interesa, pero tiene mas que ver con desarrollo de apliucaciones WinForm SmartCliente y complejas que con la engine.
CAB = Composite UI Application Block
http://www.gotdotnet.com/codegallery/codeg...ca-f2eafbf2653chttp://msdn.microsoft.com/library/?url=/li...tml/scbatlp.aspSaludos Matias
Hola!
voy a ver los links, porque todavía no me entero mucho ;)
Respecto a Orcas: Orcas es el nombre clave de la versión 3.0 de C#. Respecto al próximo visual studio lo único que se es que Cyder (o algo así) es el nuevo editor de formularios para WPF, pero no se del nombre en clave del VS.
Un saludo!
Vicente
Vicente es realmente muy bueno tu codigo de AI !!!!, veo que estan usando c# 2 a fondo!! , idgo por que vi que estan utilizando genrics en forma intensiva.
Te hago varias consultas :-)
El codigo liberado tendria modificaciones importantes tambien ( como la engine)? o leves modificaciones a las que se le iria agregando funcionalidad a la ya existente de ser necesario?
Por otra parte estoy tratando de imaginar como se utilizarian los algoritmos geneticos y las otras herramientas de AI en un juego, y dime sime equivoco pero lo que se deberia hacer es utilizar tu API para programar el comportamiento de los distintos "Actores" del juego no? esto es todos aquellos personajes "vivos" ( no cosas inanimadas..) excluyendo claro esta al personaje propio en caso de ser un juefo en primera o tercera persona ( en un juego de estrategia la AI tambien gobernaria aspectos de nuestro personaje/s imagino)
Estoy equivocado? Es mas o menos asi el tema?
A nivel de simulacion fisica, tambien creo que se tienen en cuenta los objetos cuyas propiedades fisicas e interaccion virtual estan simulados en el motor de fisica, estos pueden ser o no objetos tambien manejados por la AI correcto? No seria bueno entonces tener una clase unica que contemple estas dos cuestiones fisica, y AI, .. lo imagino como un "Actor" generico que podria tener programacion de AI y propiedades fisicas
( ejemplo si un personaje lo chocan o se cae , o sufre alguna otra interaccion fisica deberia entonces su AI responder de cierta manera, no es logico entonces manejarlo en una unica clase?..)
Como veras experiencia en juegos no tengo, si en simulaciones, por eso me hago estas preguntas...
Bueno tengo muchas mas preguntas, pero quisiera saber antes que opinion o respuesta me podrias dar a mis dudas.
Saludos Matias
Vicente, te hago una consulta mas, siguiendo con la linea de las ideas expuestas arriba :-), estaba pensando una situacion hipotetica en un juego FPS , en la que la que apareciera un enemigo. Supongo que para hacer el juego interesante del enemigo deberia tener una buena AI, se me ocurre entonces que tendria una estrategia de ataque, que tenga en cuenta entre otras cosas su estado de salud ( energia / fuerza .. etc .. como lo querramos imaginar), imaginemos que este enemigo es aplastado por ejemplo por una roca, o colisionado por una caja que le arrojemos no deberia entonces modificar su estado de salud ( disminuir) y por ejemplo modificar su estrategia de ataque y defensa??. Imagino toda esta situacion por que creo que como programador me resultaria mucho mas facil programar todo esto desde un API que me permitiera programar por ejemplo una clase "EnemigoX", que herede de "Actor" y que actor tenga una funcionalidad ya programada para manejo de las propiedades fisicas, AI Y DE RENDER TAMBIEN !! ya que si el enemigo esta herido y escondiendose para embozcarme por que cambio su estrategia de ataque ( su AI en funcion de su interaccion fisica y su estado) no deberia cambiar tambien el modelo grafico, y su animacion??? no se deberia arrastrara o cojear como un enemigo herido..
Bueno espero que se entiendan mis inquietudes :-) ? y que no sean muy "delirantes" :-) pero basicamente me pregunto si no se deberia integrar en una clase Actor, la parte de animacion, de fisica y de AI de una entidad del juego, y si esto no se deberia hacer a nivel engine para facilitar la programacion de juegos, y para lograr aspectos del juego mas realistas.
Saludos Matias
Hola!
veo que te has estado mirando las cosas ;) Como comentas uso Generics y Constraints de forma intensiva. El objetivo de la librería es ser lo más flexible posible, con lo cual uso mucho interfaces, clases abstractas, delegados y genericos. Creo que son buenas herramientas para permitir la extensibilidad de la librería.
Respecto al futuro: estoy preparando la siguiente versión con los nuevos namespaces que utilicé para la demo del Imagine Cup. Además de revisar y corregir fallos y bugs que alguna gente me comenta. Por lo general la librería no sufre grandes cambios de estructura, son más añadir métodos y funcionalidad según la voy necesitando. No veo de momento ningún cambio masivo importante a menos que viera que lo que estoy haciendo va por mal camino, y con la demo del Imagine Cup la verdad que todo funcionó bastante bien, así que a menos que pase algo raro seguiré así.
Respecto a lo de la física y el render y la IA. En la nueva versión aparecerá una clase llamada MovingEntity (nombre provisional). Una MovingEntity es una entidad con características físicas y una malla asociada (HMeshObject). El render de la malla no nos preocupa, el motor se encarga de eso de forma automática. De la física se encarga newton aunque aún no tengo claro como se relacionan la IA y la física. Si quisieras cambiar la malla pues nada, se cambia y sin problemas.
Respecto a los actores: mi enfoque en la librería es un poco más generalista del que tu propones. Me explico: la IA suele ser muy específica del problema, es muy difícil tener una clase "BotFPS" y no quedarse atado a ciertas convenciones que tu imagines en un tipo de FPS, pero que luego si alguien lo quiere usar para su propio FPS con otras ideas no le va a valer.
Normalmente la IA de un juego suelen ser máquinas de estados u otras cosas (reglas, goals,...). Yo doy la estructura básica, pero a la hora de crear un comportamiento es el programador de IA el que tiene que hacerlo. Yo no puedo saber que estados vas a tener, que funciones de transición entre los estados, etc etc etc. Te doy herramientas que te faciliten en la medida de lo posible crear esa máquina de estados, pero más no hago (porque no creo que valga la pena). Mi idea si que es hacer ejemplos de estas arquitecturas que puedan valer como inspiración y punto de partida a la gente que quiera usar la librería, pero no será código de la librería en si.
Respecto a las animaciones, la IA también gobierna las animaciones, pero ese es un monstruo con el que aún no me he peleado ;) Además esta parte se está replanificando en el motor así que tenemos que ver juntos cual es la mejor manera de hacerlo.
Si miras la librería, la entidad básica es HadddEngine.AI.Core.BaseEntity, que tiene un ID único. A partir de esa BaseEntity saldrán otros tipos de entidades que irán agrupando diferentes propiedades como comentas (malla y física).
Espero que te haya ayudado en algo! Cualquier pregunta que tengas de la parte de IA hazla gustoso, que yo encantado de responder. Estoy avanzando bastante bien en la nueva versión, espero poder subirla pronto (en unos 15 días a lo sumo). Un saludo!
Vicente
Hola Vicente, la verdad es que me sirvio mucho tus explicaciones, sobre todo para confirmar que voy a poder implementar varias ideas que tengo en mente con Haddd, y que tambien las voy a poder ir mejorando con la evolucion del motor!!.
Me gusta mucho como vas a implementar la AI y el diseño de la engine en general.
Voy a empezar a implementar esas clases que me decias que serian responsabilidad del programador de la AI del juego ( un FPS en principio..) y que no estarian incluidas en la engine y seguramente te voy a realizar mas consultas.
Felicitaciones nuevamente, va quedando muy bien la parte de AI!!
Saludos Matias
PD: respondi sin ingresar al foro :( , pero bueno creo que se nota que era yo el que respondia :D
Saludos Matias
Aclaracion :D
En realidad estoy trabajando en desarrollar un entorno visual que facilite desarrollar juegos con la engine,y otras herramientas que se complementen con esto.
Como primer objetivo estas herramientas servirian para para implementar un FPS, de ahi que estoy haciendo tambien un pequeño FPS, de ahi que estoy haciendo tambien un pequeño y simple FPS, que me sirva de test de las herramientas, para ajustarlas, probarlas y mejorarlas.
Las ideas que te comentaba quisiera implementarlas en estas herramientas, y algo que se me escapo pero que para este tipo de herramientas creo que tendre que utilizar si o si es soportar scripting desde las distintas partes de la engine. Tienen pensado algo al respecto?
Quisiera manejar mediante scripting la configuracion de la AI de las Entities, asi como tambien su fisica y por que no todo aquello que valga la pena manejarlo de este modo. Vi que directX en el SDKde Abril trae algun ejemplo de scripting con c#, no es una mala idea hacer algo similar y soportar c# como lenguaje de scripting (cambiaria la manera en que se actualiza y se instancia el este codigo respecto a una clase c# incluida en el core del juego claro..)
Bueno, aclarado que estoy tratando de hacer, te vuelvo a repetir que seguramente tendre mas consultas y preguntas!!
Saludos Matias
Aja, por eso tenías tanta insistencia en lo del FPS ;)
Te comento: yo que tú me pondría a mirar como van las cosas, pero esperate a que libere la siguiente versión para trabajar, ya que incluye cosas que son muy necesarias (como el PathPlanner para solicitar caminos). Pero si puedes ir mirándote la librería para hacerte una idea de como van las cosas.
Cambios que te interesen: State y MessageState desparecen, y los sustituye una interfaz: IState. Ahora la interfaz IFiniteStateMachine implementa de serie IMessageable y solo dejo una implementación de máquina de estados por defecto (FiniteStateMachine con el MessageHandler de MessagingFiniteStateMachine). La otra FSM ahora es trivial de hacer, porque implementando IState y heredando de IFiniteStateMachine tienes ya automáticamente toda la funcionalidad de una máquina de estados que a su vez es un estado de otra máquina de estados. Parecen cambios grandes pero ha sido para simplificar ese namespace que tenía mucho código repetido.
Respecto al scripting: está en nuestra interminable lista de "cosas pendientes". La idea es usar C# como propio lenguaje de script, porque nos facilita muchísimo la vida. Pero va a tardar en llegar aviso por dos motivos: el soporte de scripting es una cosa con mucho curro y además es curro que no conocemos como hacer ni como enfocar.
Te comento si quieres la idea mental que tengo yo con la IA a corto plazo:
- terminar los namespaces: AI.Goals, AI.Navigation (este me queda) y AI.Triggers
- revisar los algoritmos genéticos, especialmente el proceso de selection, crossover y scaling (ahora mismo se llama a la función de escalado continuamente! Y solo hace falta hacerlo una vez)
- implementar los debugers visuales. Si has visto el código, todas las variables son de tipo internal. Esto no es así por casualidad, me va a ayudar (espero) a implementar un debuger para cada namespace donde se registrarán los objetos que deseen ser debugeados. Este debuger mostrará información visual, ya que es la mejor forma de debugear la IA (o eso creo)
- generar un grafo de navegación a partir de la geometría de forma más o menos óptima.
A medio plazo:
- añadir AI.InfluenceMaps, AI.NeuralNets, AI.FuzzyLogic y AI.Rules
A largo plazo:
- añadir soporte de scripting
Quizás no es el orden de prioridades más óptimo del mundo, pero es el que me he puesto yo mismo. Además va un poco en el orden que me apetece hacer las cosas, y el scripting me da mucha pereza :P
Un saludo!
Vicente
Bueno me sirve mucho para organizarme todo lo que me cuentas. Voy a esperar a la proxima version de haddd para comenzar a programar ( o sea unos 15 dias mas o menos no ? :P ) y voy a estudiar bien la actual.
Respecto al scripting creo que es algo importante y pienso implementarlo desde un comienzo asi que cuando tenga una version funcional, que utilice tu API de AI, te la paso por si es de tu interes y sirve como contribucion a la engine, al menos como prototipo..
Probablemente en estos dias me registre y suba un sitio web donde vaya subiendo mis avances asi quedan disponibles por si les interesan a alguien mas.
Saludos Matias
En mi pagina web tienes una dll con codigo fuente para hacer scripts en c-sharp, si quieres puedes hecharle un vistazo, lo bueno del sistema de scripts nativo de c-sharp es que el codigo de los scripts se compila.
Yo encantado si te curras tu el scripting! :) Vamos, como si alguien más se propone hacer las demás cosas que faltan, que felicidad :)
Un saludo!
Vicente
zupervaca, gracias por el dato, ya baje tu dll, y la estoy usando como base para mis pruebas.
Saludos Matias
Hola Vicente, estuve conversando con una persona que trabaja en un estudio de desarrollo de juegos y me decia que le parece mejor que utilice una camara y un excenario como los del warcraft 3 para mi prototipo de juego ya que de ese modo podria utilizar mapas de alturas y entonces, con mapas de alturas me seria mas sencillo trabajar con la parte de AI. Asi que en lugar de hacer un FPS de prototipo para mis herramientas estoy encarando una idea similar pero trabajando con un mapa de alturas y con una camara mas lejana. Que opinion tienes al respecto?
Respecto a las ideas de integrar la AI, la fisica y todo lo relativo a los personajes y criaturas del juego me decia esta persona que un tema a tener en cuenta es que en su opinion los tiempos en que se manejan actualizaciones de la parte de render, de la parte de fisica y de la parte de AI son diferentes, que seria una locura tener en cuenta la parte de AI en cuenta con cada ciclo de render, cosa que me parece totalmente logica, pero aun me parece que la info de AI y demas cosas deberia ser almacenada y manejadas por una unica clase, y en todo caso que distintos threads de ejecucion y eventualmente algo como una clase AIManager registre las entities, con su info de configuracion de AI y su/s scripts y las "maneje" y realimente en tiempo de ejecucion.
Que ideas tienes al respecto?
Saludos Matias
Hola,
en lo primero de los mapas de alturas me pillas completamente :P Ni idea la verdad.
En lo segundo de los updates: yo pienso como tu amigo. El render se actualiza por un lado, y los componentes de la IA por otro (ya te digo que la física no lo se, que va a parte con newton). Más adelante cada manager de IA que uses tendrá un objeto que indicará cada cuanto debe actualizarse el manager: si le toca se actualiza y si no le toca no se actualiza. Respecto al AIManager ese que dices, creo que me recuerda al EntityManager en el sentido de que maneja el update de todas las entidades de IA, pero es que hay algunos managers más que el EntityManager (por ejemplo los MessageManagers que actualizan las colas de mensajes y el PathManager que actualiza las peticiones de búsquedas).
En mi opinión cada uno de esos managers tiene su propia frecuencia de actualización, según las necesidades que se consideren necesarias.
Espero haberte resuelto algunas dudas :) Si no sigue preguntando ;)
Un saludo!
Vicente
Ok. Voy a estudiar el EntityManager y el resto de los Managers :D . A medida que me surjan dudas te ire haciendo consultas, muchas gracias.
Apenas tenga claro el tema de los mapas de altura te comento el asunto, asi como tambien como lo utilizo e implemento en el prototipo y como integro la AI.
Saludos Matias
Perfecto!
Verás que el EntityManager le falta un Update (que lo único que hace es update de todas sus entidades registradas). En la próxima versión sale ;) Un saludo!
Vicente