Added steering behaviors to gdx-ai extension. #2202
Conversation
|
CollapsableWindow should use a capture listener so it gets evens before its On Mon, Aug 4, 2014 at 3:31 PM, davebaol notifications@github.com wrote:
|
|
Thanks @NathanSweet but maybe I'm missing something. addListener(new ClickListener() {
@Override
public void clicked (InputEvent event, float x, float y) {
if (getTapCount() == 2 && getHeight() - y <= getPadTop() && y < getHeight() && x > 0 && x < getWidth())
toggleCollapsed();
}
});with addCaptureListener(new ClickListener() {
@Override
public void clicked (InputEvent event, float x, float y) {
if (getHeight() - y <= getPadTop() && y < getHeight() && x > 0 && x < getWidth()) {
if (getTapCount() == 2)
toggleCollapsed();
event.stop();
}
}
});in CollapsableWindow's constructor does not seem to work. The issue is still there. :( |
|
Hard for me to debug without trying it, not sure where clicks are even On Mon, Aug 4, 2014 at 4:24 PM, davebaol notifications@github.com wrote:
|
|
@NathanSweet
|
addCaptureListener(new ClickListener() {
public boolean touchDown (InputEvent event, float x, float
y, int pointer, int button) {
if (getHeight() - y <= getPadTop() && y < getHeight()
&& x > 0 && x < getWidth()) event.stop();
return super.touchDown(event, x, y, pointer, button);
}
@Override
public void clicked (InputEvent event, float x, float y) {
if (getTapCount() == 2 && getHeight() - y <=
getPadTop() && y < getHeight() && x > 0 && x < getWidth())
toggleCollapsed();
}
});
}On Mon, Aug 4, 2014 at 4:51 PM, davebaol notifications@github.com wrote:
|
|
@NathanSweet @everybody |
| return frameId; | ||
| } | ||
|
|
||
| /** Returns a binomially distributed random number between -1.0 (inclusive) and 1.0 (exclusive), where values around zero are |
There was a problem hiding this comment.
In my opinion these are both exclusive.
|
They are just experiments. I forgot to remove the import, sorry. I'm going to fix it later at home. |
| */ | ||
| public abstract class LinePath<T extends Vector<T>> implements Path<T, LinePathParam> { | ||
|
|
||
| private T[] waypoints; |
|
Besides all those small comments...
Do you think it could be possible to change the orientation from I didn't really look at the implications of that in detail yet, but I think it should be possible to to have a steering API that works in any dimension the same way. Another option might be to treat 2D as a special case of 3D and assume Vector3 everywhere. The 2D users could then just use X and Y everywhere and keep Z just 0. But I'm not sure this is a better alternative... PS: The sliders in the tests really act weird when being dragged around... |
|
@nooone EDIT:
I think the problem is due to the scrollpane that is needed to avoid the annoying issue with the double click on the title bar of the CollapsableWindow. Anyways, the drag issue would be fixed by giving the window a proper width I guess. |
|
Holy crap, where were you three months ago!? |
|
@davebaol I understand your point. It's really only those flight simulations/space shooters that won't be able to use this API much. If this will be explained in the (future) wiki page, it should be okay. I've seen that there is already a test using Box2D. Do you think it's possible to add one more using bullet physics to show the way to use it in 3D? It might be pretty nice if one could just reference a test in case that there will be questions raised on that topic. Did you use bullet yourself already? If not, maybe I could find time to help with that, but that will for sure take a week or two. |
|
Shouldn't |
|
@NathanSweet
I don't think so. Follow path behaviors are behaviors, not paths. Also, you can use follow path behaviors with different path implementations: line path, spline path, etc.
That test uses box2d just to exploit its raycast implementation (too lazy to write my own just for a simple test). But yes, you should be able to use steering behaviors with box2d and bullet. You have to implement Steerable, Proximity and RaycastCollisionDetector. Unfortunately, with box2d you can't extend Body and Fixture because they are created by a factory. You'll have to deal with the userData to implement the steerable interface, I guess.
No, never used Bullet. But I would expect it's not so different from box2d. Of course your contribution is very welcome. Take your time. |
|
@davebaol Ow, I got it. The names confused me, I'm actually still looking at structural things of this PR instead of the actual logic. I didn't understant yet that they are actually behaviours. In this case the package is of course correct. However I think that in this case they should also be named "FollowPathBehavior". Just like all the other I'd still vote to move the About the bullet test: Edit |
|
It was actually a slightly later commit that fixed it. I don't see the On Tue, Aug 5, 2014 at 1:40 PM, Daniel Holderbaum notifications@github.com
|
|
@NathanSweet |
|
@nooone Also I think that keeping the FollowPathBase.Path interface as a nested class makes more evident that its implementation is required only by FollowPath behaviors. |
|
I don't want to be annoying, but I don't think that verbs are good class names. The way it is now is totally confusing me. |
|
I'd agree with appending Behavior to behavior class names. |
|
What is the status of getting this merged in? The only error I have left after trying to copy it into my own project is: |
|
@badlogic @NathanSweet @MobiDevelop @xoppa I'd like all of you to join this discussion and tell your opinion. I know everyone is busy, but this PR is here since more than a month and kind of ready to be merged. The only thing missing here is a decision... I'd say @davebaol should get the last few points in the TODO list done and then let's merge this and decide afterwards what's going to happen with the gdx-ai extension. This PR has been used by a few people already and seems to work. I'm currently using it myself in my 3D game. Steering is an awful AI task and I'm happy that I didn't have to write it myself. The test suite is pretty extensive and the documentation (both JavaDoc and wiki) is great. IMHO this PR is ready to get merged and whether or not the gdx-ai extension should be part of the libgdx ecosystem should not affect this PR, because currently gdx-ai IS part of libgdx. |
|
I'll getto it tonight or tomorrownight. Sorry folks,been a busy few weeks.
|
|
I'd prefer to move this extension out into @davebaol's ownership, outside of libgdx. It is effectively a solo project and would be better served by his retaining full control over it. |
|
I don't think it is or will be a solo project. |
|
You've created this extension effectively on your own, with minimal input from others, and you've shown yourself to be reluctant to deviate from the way you have already decided things should be. That, to me, is a strong indication that this is a solo project (or a separate project, if you prefer) rather than a part of libgdx. At the least, I think this extension should be handled externally to the main libgdx project (a la Ashley) where you (and others) can maintain it without binding libgdx to it. Ultimately, I'll defer to @badlogic to decide. I've stated my opinion. |
|
Well, If you read the whole thread I think that you'll realize that the only thing I was reluctant to change are behavior class names just because those names are the traditional names used all across the world since steering behaviors were invented in the early 1990s. |
|
IMHO keeping gdx-ai is a good thing for libgdx and the community. It offers some pretty basic functionality, like state machines, as well as some more advanced stuff like this huge steering system. LibGDX has so many features, but it's missing some ready-to-use solutions in the AI area. I think keeping it under the libgdx umbrella will increase its quality. Since it's easier to add it to a project (it is included in the setup-ui), more people are likely to find it and use it. Having it under libgdx (as an extension, or at least as a "subproject" like ashley) also increases the level of "trust" of a user towards this code. If it would be @davebaol's personal project, I might not even have used it, because one guy alone cannot offer the quality of what this community makes of it, when it is part of libgdx. That's basically the only reason why I would like it to be part of libgdx. I think this stuff is pretty cool and saved me a lot of work already. If it is only @davebaol's personal project and he will have less time, it's basically dead. If it is part of libgdx, the community will be able to keep it alive. I know that there are only four core devs here, and your time is limited, which is a pretty good reason to keep libgdx as slim as possible and not add "everything anyone ever made" to it, but I think gdx-ai is worth to be part of it. @davebaol: You have done a really good job with gdx-ai and I know you are listening to people and consider their input, but I have to agree with @MobiDevelop that you DO seem a bit reluctant to some changes. If nobody but you yourself share your opinion, you should change things according to their offers. That wasn't the case in rare(!) cases and you should "open up" a bit in this way. However I emphasize again that this happened only rarely and we were openly discussing other things behind the scenes. This should not influence this extension though. |
|
I agree with @davebaol. In my very humble opinion all this gdx-ai stuff serves well as an extension. Extensions are a good way to bring the extra functionality. And it's still kept separate from the core itself. Need for stuff like this is big and I think that adding this (and other game relevant features) as extensions in the future will greatly enhance libgdx. Of course not every single little improvement, but the main categories. Game development gets more complex as user desires and wishes are growing, and in order to keep developers using libgdx and to produce great games, libgdx not only needs to work robust (which it already does awesomely), but also needs to offer more features, that take work away from developers and offer high-level solutions, that integrate well with the libgdx ecosystem. Also, having this as an extension will bring more developers to use it, since it will be positioned much more prominently than in some repository maintained my a single person somewhere. And this also brings more developers to contribute and improve this in the future. Otherwise I fear great code like this might get lost... |
|
Having it as a separate repository like Ashley lets it have its own development and release lifecycle. It also means it would not require anything from the libgdx core team (in terms of testing, development, code review, etc...). Not every single thing needs to be in the core repo. |
acceleration. - Now Separation uses inverse square law decay.
|
OK, this is really impressive! I do however agree with MobiDevelop, i think it's time to move gdx-ai to it's own repo. Under the libGDX umbrella. Any participants in this PR as well as the pathfinding and state machine PRs should be added to that repository as managers. We'll build it on the build server, and keep it as a dependency in the Setup-UI. The core devs are just that: working on the core of libGDX. the gdx-ai extension has gotten so massive with this PR that i fear no core dev has the time to understand and support it. I'll setup a repo, give you guys access to it and make sure the build stuff is set up. You can ping me if you need to do releases and i tell you how it's done. |
|
I agree that libgdx greatly benefits from higher level utilities like this one. Don't be bummed, it's just that libgdx is quite massive already, so keeping its maintenance in check is important. We can keep a great collection of higher level utilities close to libgdx, even if not in the same repo. They show up in the libgdx setup UI and are easy for people to find and use. |
|
I see only one problem with this... what will happen to the tests? |
|
The tests should be moved into a tests project within the gdx-ai repo. |
|
But they heavily depend on the gdx core test "frameworks", that's what I meant. |
|
They'll have to be modified of course, they shouldn't depend heavily on the core test framework (which is essentially just an ApplicationListener). |
|
I'm moving stuff into a separate repo atm (including tests), i'll ping you
|
|
I didn't even mean the starter itself, I mean things like |
|
Worry not, i got this.
|
|
Well, I'm not bummed. But since there are some non-essential frameworks into the libgdx core that are not even extensions, I would have expected that such a decision would have been part of a larger reorganization plan, something like libgdx 2.0. |
|
Moved all the things to a separate repo at http://github.com/libgdx/gdx-ai. I added @davebaol as the dictator of that project. Please add any members you feel like they belong there. The project is Gradle based (surprise), you can import it into Eclipse/Idea like any other Gradle project. It currently depends on the latest libGDX snapshot. The project is added to the build server (which is currently experiencing issues due to Hetzner sucking...). The build server will push snapshot releases on a nightly schedule to SonaType. For real releases, ping me and i'll do them (sorry, i won't share the necessary keys/passwords). I ported all tests over, including the bullet tests. Please check the project asap so i can remove gdx-ai from the main repo (and hence enable the build on the build server). For existing users nothing changes, the dependency string is the same as before. |
|
Worry not, these "non-essential" frameworks will eventually vanish from On Sun, Sep 7, 2014 at 11:50 PM, davebaol notifications@github.com wrote:
|
Ok, just started working on the new repo.
Am I missing something? |
|
Nope sounds giod, apart from the versioning. We have already released that
|
|
@davebaol @badlogic I've created the wiki for gdx-ai, set up the home screen, the sidebar and copied the three articles about the extension from the libgdx wiki to the new one. I already deleted the Steering Behaviors from the libgdx wiki, but kept the ones about state machine and message handling for now, since they are still part of libgdx. I could however already delete them and edit the TOC right now, if you want. |
|
Closing this. |
Ok the project is ok and steering behaviors are back. I think you can proceed. |
EDIT:
This PR adds steering behaviors for 2D and 2.5D, suitable for most games.
Most steering behaviors work for full 3D too, excluded those behaviors that explicitly have an angular component, such as ReachOrientation, Face, LookWhereYouAreGoing and Wander (this is because we would need to change the representation of orientation and angular velocity from float values to Vector3 and Quaternion).
The other behaviors only work linearly, so none of them requires any modification for full 3D because the equations work unaltered.
Notice that the entire steering framework assumes that the direction a character is facing does not have to be its direction of motion, thus supporting independent facing that, among other things, allows you to smooth rotation over many frames when the direction abruptly changes.
Mainly the developer will have to implement the Steerable interface for the specific "engine" he's using: scene2d, box2d, bullet, his own engine or anything else.
Test classes use scene2d for the sake of simplicity.
@NathanSweet and @xoppa
In the test classes I'm using
com.badlogic.gdx.tests.g3d.BaseG3dHudTest.CollapsableWindow.Looks like I have to use a
ScrollPaneto make it work properly.Without the scrollpane when you double-click the title bar to expand the collapsed window one of the sliders may riceive both click events depending on the specific layout.
Using
stage.setDebugAll(true)you can clearly see that when the window is collapsed the title bar is vertically centered to the layout and the underlying non-visible components will receive click events.To replicate the issue replace
with
inside the
createDetailWindowmethod of the classcom.badlogic.gdx.tests.ai.steer.SteeringTest.Then run the Face behavior of the SteeringBehaviorTest. The "Deceleration Radius" slider will change when the Face window is collapsed and you click on the title bar.
Any idea how to fix this?