As I said, I have tried to integrate lidgdx-ai into JME in my code base. So yes, it’s possible!
For now, it will include serveral libgdx util as libgdx-ai depends on them. For everything except physics related problem, I’m quite confident that the libgdx-ai can handle well. Let say we will have a libgdx-ai-jme library, a folk of libgdx-ai. And, as advertised in its wiki, support 2.5D and soon 3d
For “physics” and “floors”, I think I have to summon the dark lord from hell and …modify some code to see if it fit. The NavMesh can also be integrated after include the MeshGraph and MeshGraphCell. And of course, other pathfinding methods: Theta*, and cooperative pathfinding for example. (i may contribute this to the orignal repo as well)
For “telegram” stuffs, which I find quite “out of hand”, I will make them internal API, only used for StateMachine and those existed Telegraph implementation.
To introducing “Agent” in this lib is very debatable, Agent and Actor concepts have overlapped part and different part. To be honest, I don’t have enough brain power to think about merging this two into one right now. But let see.
For BT, I will retain almost everything. Because I’m not really interested in it much
Sorry for my stubborness if you find any unintended offense.
@atomix
No offense at all. We were just discussing, right?
If you give me read access to the source code I’ll look into it to see if I can improve gdx-ai in order to fix the problems you encountered while integrating steering behaviors and physics.
This is going to be long discussion, isn’t it? The main problem of developing MonkeyBrains further is “what does good AI framework and what are they responsibilities?”.
I will start with my idea, and it would be great if we could agree on some points so we can improve MonkeyBrains.
I think of AI framework as mind. It doesn’t have physical properties so it is up to user to implement body. Like mind can live exist without body, so the AI framework must be flexible to work with any physics library or similar. Because of the premise AI framework must include except of agents and their behaviors and objects of interest for AI. Objects they can perceive, touch, use and such.
The goal is to make a lot of independent behaviors, and it is up to user to include use what behaviors that are useful to him.
Because AI framework should represent mind, behaviors are at main focus, not agents.
I thought there would be more, but I think this sums it all.
It’s not like I going to to write a PhysicsForce calculation or anything like that. They are just utils and it should be there just like Steering or pathfinding.
PhysicsSteering is exactly like other Steering behavior, except it abstract out some methods for user to implement with the physics engine of they need:
PhysicsAvoidSteering look quite like the WallAvoidance, scan obstacle around the Vehicle but will use physics cast instead of normal raycast. This will solve the case of dig though the ground I said before, because this Steering will exam the terrain.
PhysicsGravitiyForceSteering take force into account, so any steer vector normally just calculated in an virtual plane need to be reform with a “gravity” and “force” its physical body have at that moment. It’s look like PiorityBlendSteering but have with some physics elements built in. For example: two ball in a physics world not just collide and stop (like boids in normal steering) but they be push away from each other immediately, can deform and reduce the force if it’s a soft body…
All those elements will be abstract out as much as possible to hook into modern physics engine.
“Floor” is also very common in 2.5D game. And I’m not talking about a real floor but virtual planes, and there are virtual gaps between those virtual planes that character can go though.
Support for floor because I think people going to JME tend to write 3D or 2.5D games intead or just 2d game (even if they can). That’s what fancinated about out engine compare to libgdx or cocos for example.
Anyway, I want and needs suggestions I always overthought time to time.
I make a new thread to discuss about libgdx-ai for those who interested with the idea. Because we also have the main dev of the lib join this conversation. It’s going to be a huge advantage and a good opportunity to “make benefit” of both engines. So i make the move, i will push my demo code as soon as I get my weekend time.
@atomix I agree that terrain (floor) should be the part of AI. It is necessary for good spatial reasoning. I started the jNavigation project for use of Recast Navigation for the purpose of MonkeyBrains, but I never finished it. I will probably start it all over again, as the Recast Navigation was updated with new methods of creating navmeshes. The best possible way for representing terrain is with polygons, and Recast works well with them, but the problem is that with that kind of terrain representation are implementing basic senses. How did you implemented terrain reasoning and what are your thoughts of it?
@Pesegato I was thinking about your posts, I think there was misunderstanding what does inventory do. It is possible that the name was misleading. I think of Inventory class not as storage that agent has, but some things that agent can do periodically. I think I can better explain this with few examples.
In FPS, agents have gun, weapon, bombs. I think it is wrong extend Agent class and possibly override something that shouldn’t be overridden in framework and I think that from big picture, agent entity and weapon entity can exist separately and logic of them working together shouldn’t be in agent class, but in behaviors. So the idea of extending agent in direction of weapons should be in use of Inventory interface and making basic behaviors that will go well with them. Example of that in MonkeyBrains is SimpleAttackBehavior and Inventory class.
Inventory will never have the status of class, because the storage of weapons differ from game to game. It maybe list, array or matrix. It is up to programmer to define how to store items.
Inventory is embedded into agent class and it will be given tpf-s. This will enable to reduce cooldown everything what is added that should have cooldown in inventory. I remind you that weapons have cooldown and are unable to use, until the cooldown is over. Without this programmer will have extend the agent and override the appropriate methods to reduce cooldown.
Steering behaviors are influenced by the mass of agent. Mass depends of agent’s mass and mass of his inventory. Also embedded into agent. If you don’t want to include mass of inventory just return zero for appropriate method.
I am aware that some agents don’t use weapons, so this problem is solved inside of agent class. If you don’t use inventory, it will not change anything.
Super powers, magic, skills should be stored into inventory, as they can be used periodically. They will not have mass. But inventory is used for this kind of stuff. I think MagicInventory for magic stuff is god extension for Inventory, as it can include stuff like mana, and with Java 1.8, we can make additional logic inside of these inventories…
I think I explained my point of view nicely. What do you say @Pesegato should we return Inventory and possibly rename it if the name was misleading?
Yes, there should be an interface Terrain (because if there is any more abstract name to call it). VirtualGround i suppose. VirtualSpace and VirtualGround are the world of full 3D physics and world of 2.5 and 2D steering, pathfinding respectively.
A NavMesh is a candidate for VirtualGround because it wrap around a 3D geometries and suggest a surface that AI character can walk and can think in this surface. The virtual grounds have boundaries. Think of floors and rooms.
VirtualGround or VirtualSpace should only affect “behaviors” and “senses” but should not affect “overall stragegy” or the layer upper that. In an FPS for example, VirtualGround should affect local movement and animation of characters, but not team tactic, team events for example. That’s said, VirtualGround is the semi-real and related to physical embodiment of AI agent, to distinguish with AISpace which is a fullly virtual space in mind.
Of course bringing any thing like VirtualGround or VirtualSpace on an AI framework will limit the flexibility. I think they should be utils only.
As I implemented AI for an RTS game, I used VirtualGround a lot. Two main usage of VirtualGround in such game is for pathfinding and team tactic. And underlying is use a Versionable, changable navmesh.
Let me explain about this version of NavMesh. It’s not a general NavMesh like one in Recast. It’s a Mesh, and very changable.
When my units do pathfinding in the Mesh, they insert they positons as inner vertexs in the Mesh’s Cell. The Mesh’s Cell have a limit of capacity and whenever that Cell is consider full. You have to re-route with another path.
Then, the calculated path is also embed in the Mesh. If one find a similar path already built in the Mesh (with threshold) it may reuse that path.
The Mesh is updated over time. The inner vertexs can be clear after expire time. This ticket holder method is much more efficient that the normal cooperative path finding method which involve a 3d table.
By travelling the mesh by adjacent Cells, a team tactic can enhance its vision by far instead of thinking in Node Model. Because, we have informations about surface attribute (dirt, grass, lava…), also positions and area.
Versioning here is a complicated concept from database world. For the user, it’s look like we have a multi-version of NavMesh geometry sharing the same reference. That charateristic enable mutil-agents, multi threads to working in the NavMesh at the same time. An Agent can decide to do pathfinding in its outdate Mesh (with a threshold of differencies) or update the local Mesh.
Operation in the Mesh work by multiversion concurrency control
rule or timestamp-based concurrency control
If you don’t want to mess with this concurrent design, you can just forget it
That’s a slim cut of what can be done if you involving Mesh and Cell instead of Node, as implemented VirtualGround and for Terrain reasoning.
The last note: If I write a library,I never tend to force user to use my utils part. Terrain reasoning only existed in a few genre of games. So if they don’t have a VirtualGround, or any Terrain at all in game. They don’t have to know about it.
First of all, I like your tenacity
I have to say that your Inventory makes much more sense now; however I still think you are leaking (too much) game logic into the AI.
And also this approach is somewhat enforcing a way to code things (weapons/attack) inside behavior, which may not be what the game developer want.
If you take a look to the image I’ve build several post ago, you’ll notice that I try to keep things as simple as possible (to the point of making them dumb), but that’s just my personal preference.
Keep in mind that I’m not an AI expert, nor a game developer expert, so I may be mistaken and I might change my mind later on. But now this is my point of view… hope you don’t get offended!
Since the library is for jMonkeyEngine I think that an abstraction layer is good; however the prime candidate for a “floor” should be
com.jme3.terrain.geomipmap.TerrainQuad
It has a lot of nice goodies, is well documented and it’s even editable from the SDK!
@Pesegato
TerrainQuad is a datastructure for terrain i suppose! We have to separate this two concepts when implement them.
VirtualGround should be some thing independent with any Spatial. Later on, we can have TerrainQuadVirtualGround or NavMeshVirtualGround… depends on what really affect the way AI think and decided to move. It may not really affect the way AI move . The virtual ground is the conceptual part of the mind about surrounding “walkable surface” to be distinguish with VirtualSpace is conceptual part for surrounding enviroment in general. Those utils are really helpful in games that characters or agent actually “walk” or “move”. Most games but not all. That’s why they should be utils only. That’s the point.
I don’t know if that is a good thing, but it helped me a lot in achieving my goals.
When you say it like that, it seems that framework is leaking game logic, but I agree that this approach is enforcing a way to code with MonkeyBrains. I see the Inventory as yet another observable space, that seem to be important for AI.
Example: Some Mortal Kombat look-a-like game. One player will have in inventory all possible skills, and behaviors that will use those skills. I think that behaviors can’t and should be independent from observable state (skill status shouldn’t be directly inside of behaviors). Reinforcement learning as really important method for AI in games, is this kind of games is based on possible moves that agent can do with success that move had. Moves that had better success will occur more frequently than the others. The idea is simple, but the results are good. For making this kind of learning processes that depends on “self-awareness”, some concept of agent state should be included.
Like this Inventory (maybe we should rename it as AgentAwarnessState or something similar, I am open to suggestion, as AgentAwarnessState does not sound good), health status is also important for AI decision making, but it is also part of game logic. Idea that agent first shoots at agent with lower HP status is area of AI, how the HP status drops is game logic, or it should be, but the boundary between is really fuzzy.
I like your approach. I have approach of making blocks for AI and then recombining them, but you have proven a lot of time that my blocks can be too big to be used, so we have separated them to fit to your needs and my idea of how framework should be. My idea is to have one very simple base that is flexible and different blocks with less flexibility, but with great results for some particular game type.
I am not easily offended kind of person. It is great for having you on board, as my idea it that MonkeyBrains shouldn’t be just framework for game developers, but also for average programmer that wants to make AI easily without much thinking how the AI works (hence idea of AI framework with very flexible base, and branches that are not so flexible).
I agree with @atomix about VirtualGround point of view. VirtualGround as interface and TerrainQuadVirtualGround and NavMeshVirtualGround as concrete implementaion of that interface, just like List, ArrayList and LinkedList.
@tihomir I think your goals exceeds mine; so for now I’ll just concentrate on what I want to implement. On a second step, we’ll think on how is best to extend the functionality
(Note, it’s not a lightweight library):
