Any news on the AI framework? I am very keen to get into this and not sure what has been done so far. Any suggestions where to start from :?
tomcat
My valient AI gurus are busy building AI for Army Simulations… I keep bugging them, and they keep assuring me that they will contribute when time allows. So, I have no idea when they are going to be able to get to it.
If enough time passes, I might get at least the basic FSM framework done. I can at least do that.
ok, if there was some basic stuff, I can get on with testing (and probably adding to it or providing feedback) so we have a token engine going.
tomcat
I don’t know how interested you are in FSM frameworks, but if you have access to Game Programming Gems 1, there is an article on how to create a robust framework. That’s what I was going to work off of.
OK, this is a good starting point. I look at it and see if I can implement it.
tomcat
I think I found the articles you were refering to. Reading it came across a coupel of points that you may be able to help.
First thing is that we need some kind of message passing mechanism between objects. Say if we have a FSM attached to an entity then we need the entities to be able to send each other messages to set the future states. I am not sue if we have such a thing in the entities. What do you think?
Secondly the entities need to be event driven. Again not sure if we have such a mechanism built in. Any ideas?
I hope we have something similiar to the above. Any comments?
tomcat
Well, the answer to both your questions is the same. Right now, there is no entity. The only concept implemented in the new jME is Spatials which is purely for rendering. I have yet to figure out the best way to tie everything together (Rendering, sound, AI, physics, etc). So, if there is a need for communication there is nothing stopping it from going in.
Similar to the sound thing, I’m unsure how to tie all these components together (right now, sound and graphics). Time to do a little research I guess.
Anyways, answer: No, neither communications nor event based triggers are implemented, but there is nothing keeping them from being implemented.
Ok, I see that there might be a little problem as the entity does not exit anymore. We really need some object off which we can hang various attributes such as graphics, sound etc. Entity was (and I think still would be if its not too much trouble to bring it back) a suitable place holder for various attributes.
It would help to identify each object in the world by givingthem an id and allows us to communicate with it if required.
I can look around to see how we can add a simple message passing functionality to the system (which would also be very useful for FSM) and pass on the info it that helps.
tomcat
I think still would be if its not too much trouble to bring it back
Entity or something like it will probably merge from old to new. See my response to the sound thread.
Nothing has really been done with AI at this point. To tell you the truth, other than this thread, no one has shown a real interest in it yet. So, it’s still very much an open topic.
Heh… I’m interested in AI. My jME-based project is a programming game (a la CRobots, Robot Battle, etc.), and one of the things I’ve been working on is a framework for running scripts in a virtual machine-like state machine, so that I can run multiple programs (written in a natural way), but from a single Java thread.
Something like this could be used to do the AI for in-game critters, although it might be a bit heavy if the critters aren’t that smart (e.g. if they’re just executing simple behaviors). One good thing, however, is that you can control execution speed of each script very well (that’s the whole point, in fact).
Right now there are two main limitations - it’s slow, and the scripting language is under-featured. Performance will be easy enough to address - right now the VM is a fairly naive, first-cut implementation, so I’ve on doubt there are some gains to be made somewhere. It’s faster than I thought it would be, but comparable Java programs execute at 4000x the speed.
My eventual plan is to compile suitable methods (“known-execution-time methods” - e.g. anything without a loop) down to JVM byte codes, which would speed things up enormously. Only “variable-execution-time methods” would remain interpreted.
I’m a little less certain about what to do with the scripting language. Right now it’s an object-oriented, weakly styped language, weakly typed, garbage collected (courtesy the the underlying JVM), that allows script-to-Java calls, but missing lots of things such as control over memory allocation, Java-to-script calls, scripty features like first-class lists and maps, and indeed many common operators.
I could continue adding features to it, which would make it usable without too much work, but my dream is to support something more popular, such as Groovy - or even just Java. One way to do both (and more) would be to rewrite the interpreter to handle a subset of Java bytecodes (e.g. not threading primitives), and then to post-process Java class files using a special class loader. That’s a lot more work, but it would make the system extremely versatile.