Eta Para El Código Fuente Del Motor?

[Vicente]

 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

[matute]

 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

[matute]

 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

[Vicente]

 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

[zupervaca]

 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:  

[matute]

 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.aspx


http://msdn.microsoft.com/vstudio/teamsyst...at/default.aspx

El 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

[matute]

 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-f2eafbf2653c

http://msdn.microsoft.com/library/?url=/li...tml/scbatlp.asp

Saludos Matias

[Vicente]

 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

[matute]

 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

[matute]

 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

[Vicente]

 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

[matute]

 PD: respondi sin ingresar al foro  :( , pero bueno creo que se nota que era yo el que respondia  :D

Saludos Matias

[matute]

 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

[Vicente]

 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