Ive gotten to the point in my game where I am about to being AI. Just like the current Controller, I would like the entity to be set to a spatial, not the other way around. This is so that when you are updating a node, and the spatial gets its share of updateWorldData(float time) i would like the entity to be updated too. So something like this in pseucode:
AIEntity birdAI = new BirdAIEntity(bird);
birdAI.setProperty("Shit On People's heads", new Float(50));
birdAI.setProperty("Flying Speed", new Float(10));
bird.addEntity(birdAI);
do you think this makes sense? or is this is the wrong approach to AI?
To be honest, I don’t really know what a good approach to AI would be. But Spatials are purely graphic concepts. The Entity is supposed to contain everything about a game object (graphics, ai, sound, physics, etc). That’s why Entities contain Spatials. That being said, I understand where you are coming from, but the reason Entities are in the state they are in, is there hasn’t been a need (for me) for them yet. My original idea was that entities would also be heirarchical. As a user you would build the entity tree and not directly deal with spatials. Something like:
Entity player = new Entity("Duke Nukem");
Entity world = new Entity("Level 1");
player.setSpatial(dukeNukemModel);
world.setSpatial(terrain);
So, in the addChild method there would be code that builds the scene graph:
public void addChild(Entity c) {
//check if it's a Node (if not add a Node?)
getSpatial().addChild(c.getSpatial());
//do any physics tree stuff if needed. as well as sound.
}
then you'd render the entity which would handle drawing, playing the sound etc.
Now, this is just brainstorming stuff, and probably a little ways off. But I just want to show that the nodes and everything you are currently deal with are purely used for rendering data to the display.
that sounds cool. But what would be the purpose of a heirarchial entity system? its not like the parent can supply physics information to the child ( or could it? ), and I would think the same applies for sound and physics?
Well, it depends on the physics engine we use I guess, but if my parent is going 50 Miles/hour then I should be going 50 Miles/hour. If I’m attached to my parent and I am pushed, then it should affect my parent. Things like that. Sound is already in a heirarchical system.
I know what a heirarchial system could be used for in AI, its kinda complicated. If my parent knows something, e.g. A boss, he can send a message to the children to let them know they need to regroup or something.
Sure, but jME’s AI system will provide the very low level components needed. That is a robust FSM framework, a neural net framework, etc. I’d say the FSM is probably the best place to start. But AI is one of those things that as an API we need to keep lowlevel, as soon as you add anything into it, it becomes application specific.
yeah, i thought of that, but then the Contoller will resemble entity very very closely. Why not just create AI using Entities in conjuction with controllers. That is what I shall be doing.
I’m not sure combining the trees will be the most efficient thing to do, although it may make the code a little easier to write.
The problem is that not all graphical objects will have sound or AI information. If they don’t, I can see the system having to waste time calling a bunch of no-op methods. Also, I imagine there will be some wasted memory with extra pointers/objects/primatives that are never needed. While that’s not a big deal on a small scale, if you start getting lots of objects, it adds up pretty fast.
I’m not shooting down the idea or anything, but it’s definitely something to consider.
Also, for what it’s worth…
My experience with AI (I used to work on an RPG MOO) is that it is highly specialized. Like Mojo said… it’s very application specific. I think what will end up happening with the proposed mechanism is just calling a bunch of ‘updateAIState’ methods on objects (whether they have AI or not), and that’s about it.
There is definitely some value in providing low-level framework stuff like neural nets, genetic algorithms, fuzzy logic, (maybe path finding?) etc… but it’s tough to define generic behaviors that belong in a low-level engine. Heck… it’ll be tough to define those low-level frameworks in a generic way.
The problem is (my understanding) most AI applications are totally dependent on how the input is formatted. That is to say… it’s hard to find a pattern in something (ie, use a neural net) in a generic way. Eg, handwriting recognition and image recognition… While they’re pretty similar, the code is basically all in the details.
Not to say that there isn’t a ‘good enough’ solution (as there often is)… it’s just going to take a lot of forethought.
Sorry… kind of a tangent, there. I’m just really interested in AI stuff.
well, ive started the FiniteSM framework and the FuzzySM framework ( the Fuzzy implementation just extends FSM).
I was planning on doing path finding too. Using a standardised file to map out the areas using an editor of some sort. Loading the map into jme and supplying it to the AI to pathfind using A*. The nice thing about this that the map isn’t the actual scenegraph, its like a transperant sheet over the scenegraph to provide which areas are accessable or not.
Hrm.. Maybe. Path finding is one of those grey areas, I think (which is why I put a ? with it, above).
Getting that static overlay map just right is going to be really tough.. obstacles, terrain, doors, etc..
I wrote something a few years ago in my MOO that used.. dang.. what was it called.. It's not the A* algorithm.. I picked it up in my networking class in college from the graph theory stuff.. Uhm.. Dijkstra's Algorithm? I think that was the one I used. I think Bellman-Ford is the name of the other we'd talked about.. but I don't remember which one it was that I implemented.
Anyway.. my point is (yes, I have one), it might be possible to do it with the existing landscape rather than having another mapping. Not saying that'll be easy, either.. but at least that way, the work is done in the engine rather than by the programmer or level-designer.
All that would need to be done is define on the bot what types of things are passable and what aren't.. then use those rules to derive that map.
This allows for different bots to have different abilities. Eg: Maybe one can swim and hence cross a river while another can't and must go around. The map wouldn't really be able to define that.
well, in a sense it can. If each "block" has a number between 0 and 1 representing difficulty, 0 being easy, 1 being impossible, then "swimable" would be around the 0.5 region, and a bridge would be in the 0 region. Pathfinding is really finding a path. Agent-World interactions are placed in the entity class and not in a path finding algo. But thats my opinion.
If thats the case, i believe this thread has reached its conclusion whereby spatials shouldn’t be tied in with entities. Seperate trees will exist in order to optimise for each subset of a game. And to simplify the graph.