No this is not a treason, and I’m not going to promote libgdx here!
As discussed in the MonkeyBrains thread. For those who curious about using this lib in jme3… Because the library is generic enough to use in any java project which include libgdx utils. So i’m going to extract those class needed from libgdx (with all the license of course) and let a JME3 game run this library.
Later I will modify few classes to make it suite more with JME3 and 3D AI. This include physics, cooporative AI and may be Agent later.
There will be one tower defense example game included to be demo. But don’t expect too much, it’s just a demo
For who want to see the repo only, there will be no new commits until next week, but here we go.
copy from it wiki…
The gdxAI project is a libGDX extension living under the libGDX umbrella.
However it does not force you to use that specific framework if you do
not wish to do so. The libGDX jar remains an essential requirement,
mostly due to the use of libGDX collections which are optimized for
mobile platforms by limiting garbage creation and supporting primitive
types directly, so avoiding boxing and unboxing.
GdxAI tries to be a high-performance framework providing some of the
most common AI techniques used by game industry.
However, in the present state of the art, the gdxAI framework covers
only part of the entire game AI area, which is really huge. We’ve tried
to focus on what matters most in game AI development, though. And more
stuff will come soon.
Currently supported features are:
Movement AI
Steering Behaviors Pathfinding
A*Hierarchical PathfindingPath SmoothingInterruptible Pathfinding
Decision Making
I’ve studied the libGDX and I found that the Message Handling part (telegram & co.) looks like an improvement over my architecture of custom Event interface with Listener.
Once again, I feel like a caveman
@atomix, what do you think about using telegram for general game event management (not necessarily AI)? What is your suggested alternative? I ask this because you said that you are planning to make it private…
I don’t think telegram should be a general game event. I will make it internal API, that mean some of those Telegram creation will be handled to TelegramFactory and be protected. Telegram is specific to a StateMachine or other facilities that already used it. For cross layer event (Layer in term of AI like I explained in the other thread) should be more generic. Cross layer event for example: a Position from Steering send to upper layer like CharacterAnimation should be immutable (can not be changed). Current design just send a reference, an extra piece of information that can be trouble in conccurent enviroment: http://libgdx.badlogicgames.com/gdx-ai/docs/index.html?com/badlogic/gdx/ai/msg/Telegram.html
To be clear, I will never use a solid class or an interface to be a strict protocol for all my messages or events, because there should be a lot of types of events in the game. If you plan (and also have techniques) to manage, transfer, compress and hide informations in the messages for example, you should make a contract for them to obey: make them implements an interface, or extends from abstract class. Otherwise, just don’t force the user to make one kind of message.
In the AI framework to be specific, you can… but take a step back and think about it first. The problem of events delivery is quite a hard one. It involves a lot of techniques like concurrent, compression, referencing … The things look like low level for a guy just want to write a game. So, you should chose it wisely to save you and your user later. If they meet a complicated usecase that you event system did not work, they will comeback and complain about it more than you think. Is there any possible way to work around, like a generic deliverer of messages, and you should keep it an util only!
That “broadcast station” is quite like eventBus if you have used it in Nifty. If you use Guava, you can also use its EventBus for free. For a lightweight and a quite advance alternative, you can use .
I’m personally prefered MBassador because of its elegant design and powerful annotations. Of course you can try to write one that suite your need… Recently I learned that I should talk less and do more, because I can’t and shouldn’t give non target advices!
Most libgdx API are not thread-safe by design. That’s why I’ve deliberately chosen to use the extraInfo field in place of inheritance. This makes telegrams easy to pool behind the scene.
Thread-unsafety and pools are common policies across all libgdx API.
I’m trying to have some progress in the 3d AI demo but it’s chinese new year holiday here, and we are partying so hard lol . I will remind you whenever it’s ready to check out.
Sorry for long delay. This is the said tower defense game I’m talking about.
I finally picked my lazy ass up and push some code. This example become good enough as an “publish-able mobile game”, so I decide to spend more time with it and later (till now) release the “share-able” part of it
It used:
jme 3.0
libgdx 1.3.1-mini
libgdx-ai
atom-mini
Which give an overview of what is essential for the two frameworks to coblaborate in one project.
JME3 side:
atom-mini use various java libs and jme3 contributor’s projects like:
Guava,
Trove (optional)
tonegod.ui
Lemur
ShaderBlows
… So because we don’t have a gradle pipeline yet, try to import them manually.
Libgdx side, only:
utils
math
ai (lastest) but
without btree – because it’s link to graphics in some classes (getFrameId). I don’t want to try to remove that my self even it’s easy because I’m lazy.
The fun thing is to write an EmbedLibgdxAppState that work as Application, Files, Graphics interfaces at the same time. Provide an appropriate timer.
In the repo there are:
master : where I use Jme agent technique!
jme-libgdx-ai: where is the fun part, use libgdx and libgdx-ai
I will push my lastest code with some models tonight, at least that what I can do to replace the ugly boxes.
Thanks to some great work by @davebaol GDX-AI is now practically independent of LibGDX. See this issue:
And the updated wiki page:
Despite being born as a libgdx extension, the gdx-ai framework is now able to operate properly regardless of the libgdx environment. To make the magic happen, the GdxAI class acts as a service locator with three services, each implementing a specific interface. Such services provide the means to interact with the surrounding environment.
I really love the idea of a general purpose AI library that works across (Java) game engines. I encourage AI programmers in the jME community to contribute to GDX-AI.
