• entries
37
65
• views
48177

# Working on the AI, a coreographic fight.

777 views

This week was full work on the AI, which was lacking a bit, to say the least. It is a simple state machine that changes based on the distance to the character (far? jump, close? punch/kick) and its own physical state (falling? stucked? idling? close to edge?).

Eventually I managed to make sequence I'm quite proud of:

Several silly situations came out of it before I reached that stage:

The AI trying hard to punch, only to fall to their death.

Finally! It manages to punch me.

It's not really hard to terminate the threat.

Sometimes it even terminates itself... is the most convoluted way.

The AI is not prepared to fight flying robots.

Ok, that was a decent punch.

So it does not get too cocky.

If you are interested in Posable Heroes, you can wishlist it on steam.

There are no comments to display.

## Create an account

Register a new account

• ### Similar Content

• Hi,  I was wanting to read the box2d source, but wanted to get a broad overview first.  I'll just say what I understand so far:
Box2d has discrete & continuous collision detection.  We first integrate our shapes velocity, and using a 'conservative advancement algorithm, we advance the shapes & find toi.
It then uses gjk & barycentric coordinates to find the closest point on the shapes.  If  theyre overlapping we use epa or sat (and dont get a contact point? Or run gjk again?)
It then builds an incremental manifold (i probably have this wrong) adding a point each frame.
Then once all collision points have been collected for the frame, they go through the collision solver that takes each collision, & adds an impulse to the shape to bring the relative velocity <= 0.  We go through the list of contacts several times (the iterative rigid body solver), to stabilise the simulation.
I'm not sure what it uses for discrete collisions?
What things I don't understand is
1. When do we know we don't need a collision point anymore? When the collision points are moving away?
2. How do we know a contact point is unique with gjk/barycentric coords? Or do we just add them and wait till they get pulled off the list?
3. If the toi is less than one & we want to use the rest up, do we run the whole collision routine again for a max say 4 times, to use it up, and where does this fit into the iterative solver?
I kind of just want to get an overview of how a physics engine fits together and the parts or algorithms we need.   Its just for a hobby engine, and with understanding as a priority.  Any help would be great, and sorry if the question is a bit over simplified.

• I am developing a simply 2d physics engine and I' ve read the source code of box2d and matter.js. I found some insteresting thing on finding contact point:
Box2d use indicent edge, reference edge and clip to determine a contact point. It's very complex method and hard to understand.
However, matter.js use a very simply method to do the same thing. just find the vertex that contained by opposite polygon with hill-climbing:
var verticesB = SAT._findSupports(bodyA, bodyB, collision.normal), supports = []; // find the supports from bodyB that are inside bodyA if (Vertices.contains(bodyA.vertices, verticesB[0])) supports.push(verticesB[0]); if (Vertices.contains(bodyA.vertices, verticesB[1])) supports.push(verticesB[1]); // find the supports from bodyA that are inside bodyB if (supports.length < 2) { var verticesA = SAT._findSupports(bodyB, bodyA, Vector.neg(collision.normal)); if (Vertices.contains(bodyB.vertices, verticesA[0])) supports.push(verticesA[0]); if (supports.length < 2 && Vertices.contains(bodyB.vertices, verticesA[1])) supports.push(verticesA[1]); } and it works well in demo.
My question is: why does box2d use such complex method? It's clear that matter.js's method is better. Or there are some potential shortcomings in matter.js's method?

• I'm currently implementing a 2D physics engine, then i stuck in collision resolution. So i did a search in google, and i found this passage, It explains how to use impulse to separate two objects.
But after that, i found another another passage, this article is very complicated, but they seem talking the same thing ——— how to implementing the collision resolution. So now, what i confuse is why are there two completely different approaches of collision resolution? What's the difference between them? Which approaches is right?
I am not a native english speakers, so i hope you can understand what i wrote.
Thanks.

• Hello folks,
I am fighting with a really simple problem that has been driving me nuts. I'm usually fairly confident with trigonometry and I'm pretty sure the issue here is not the math but in some behavior behind the scenes.
A bit of background - basically I'm developing my own little 2D game engine using C++, in my free-time for fun. I work with game technology and simulation products IRL so for the most part this has been plain sailing. I am using Box2D for physics, and SFML for rendering.
My game at current has a few space ships flying around via keyboard and AI input. These space ships need exhausts! So I'm currently in the process of getting a 'component' system in place, however my problem is that the animated exhaust sprites are not going where I want them to.
When the base GameObject class runs it's update method, it does the following:
Queries the physics object for a position Converts the physics position to a pixel position (x10 scale factor) Moves the sprite to the new position Passes new position to all 'component' objects into their 'UpdateComponent' method Components move their sprite to the correct position However the exhaust sprites seem to wander around all over the place, in no way representing where I actually want them to be! This should have been a simple case of:
newPosition = (sin(rotationRadians) * offsetX, cos(rotationRadians) * offsetY) + oldPosition Here is the current code:
void Exhaust::UpdateComponent(const Vec2f & position, float rotationDegrees, float deltaTime) { float angleRad = DEGREES_TO_RADIANS(rotationDegrees); float offsetX = sin(angleRad) * mOffset.x; float offsetY = cos(angleRad) * mOffset.y; sf::Vector2f newPos(position.x + offsetX, position.y + offsetY); mSprite->SetRotation(rotationDegrees); mSprite->SetPosition(newPos); mSprite->Update(deltaTime); #ifdef _DEBUG sf::Vector2f p(position.x, position.y); stringstream ss; ss << rotationDegrees; DebugUtils::DrawCross(p, 8, sf::Color::Green, ss.str()); DebugUtils::DrawCross(newPos, 8, sf::Color::Green); DebugUtils::DrawLine(p, newPos, sf::Color::Green); cout << rotationDegrees << endl; DebugUtils::DrawSpriteOutline(*mSprite->GetGraphic(), sf::Color::Green); #endif // _DEBUG }
And here is a gif of it all going wrong! (link below)
Gif of game engine problem
Any help would be much appreciated, even if it is just a thought of where the problem might be originating from!
Thanks!
• By JesseTG
A Really Useful Box2D Editor
You're a game developer. Your next project will have Box2D-powered physics, and it'll be awesome. So you wrestle with installers, build systems, possibly with compiling the library itself, and then get a rectangle moving around on-screen. Now what? If your game is non-trivial, you could have dozens of different types of objects. You're not going to have a good time describing them in code, as you'd have to recompile every time your designer (which could be you) blows his/her nose. You could come up with your own loader, but then you'd have to come up with your own file format, too, and that's time not spent actually making your game!
Enter R.U.B.E., the Really Useful Box2D Editor. R.U.B.E. is a level designer for virtually any game that uses the Box2D physics engine. You can use it to visually create a wide variety of collision shapes, place them on-screen, and edit their properties. R.U.B.E. also boasts a comprehensive scripting system, support for nearly all Box2D constructs, and extensive customizability.

The Setup
I use R.U.B.E. on Ubuntu 14.04 and a reasonably beefy 2011-era Samsung laptop. R.U.B.E. is available for Windows, Mac, and Linux. The Mac version, however, does not officially support 64-bit computers; it might or might not work. Likewise for any Linux distribution other than Ubuntu. When in doubt, see if the trial version works. I'm using R.U.B.E. to develop a top-down shooter written in Java and libGDX.
The Editor
The user interface for a program like this should aim to minimize the barrier between the designer's ideas and his/her implementation. Fortunately, R.U.B.E.'s editor does a decent enough job of that. The controls for the editor itself are a bit clunky, relying on keyboard shortcuts to perform basic geometric transformations (e.g. pressing S to scale an object, as opposed to just grabbing a handle like in Unity or Inkscape). A bit annoying, but you'll get used to it. Other features, like the ability to position the menus freely, or the ability to copy objects to other programs as plain text, or even to run the Box2D engine to see how objects move in the world, are very much welcome. I don't think you'll be wrestling with the program too much.
The Scripting
My limited experience with RubeScript, the built-in scripting engine derived from AngelScript, was a pleasant one. The language itself is nothing spectacular, preferring simplicity for programmers and non-programmers alike over flashy features. Better documentation for the built-in types (strings, arrays, etc.) and code completion would've been nice, at least.
What really makes RubeScript stand out is its thorough functionality. Almost all of the built-in editor actions--adding or deleting bodies and joints, smoothing or removing vertices--are actually implemented in RubeScript, and can be viewed in R.U.B.E.'s installation. If the developer himself can write the meat of R.U.B.E. in its own scripting system, I'm sure you can get something out of it, too. Tools like this are why game designers benefit from some programming skills.
The Competition
Minimal. Most available alternatives lack some of R.U.B.E.'s most defining features. These other editors are only designed for creating simple game objects (such as PhysicsEditor, which doesn't support joints), or lack adequate import/export facilities (e.g. BoxCAD, whose output requires ActionScript 3.0 to be used). Other more generic solutions such as Tiled or even Inkscape might suit your needs if you can write a loader to convert their output to Box2D worlds. I don't feel that most of these other alternatives fill the need for a 2D physics world editor, though for very small games you may disagree.
The Surrounding Ecosystem
I have nothing but good things to say here. The official documentation for R.U.B.E. is excellent. Even if you ignore the built-in manual (which is very detailed and contains plenty of images), there's a wealth of resources available on the official website, including sample projects and video tutorials.
But perhaps best of all, Chris Campbell (the developer) actually gives a damn about you. He reads the forum and any e-mail he gets. It's easy to report bugs or offer feedback from within R.U.B.E. itself. I can send a hastily-written bug report or feature request through through R.U.B.E. and continue working before my concentration wavers. You'll actually get a response from Chris within a reasonable time frame, and he'll make sure you get the best out of R.U.B.E. you possibly can. He's helped me numerous times with reporting bugs, feature requests, and even general Box2D questions.
The main problem with R.U.B.E., as I see it, is that your game's technologies will be limited to whatever has a R.U.B.E. loader and a Box2D port available. This issue isn't exclusive to R.U.B.E.--it's inherent in any technology that's not as mainstream as, say, PNGs or WAVs. While R.U.B.E. does have loaders available for many popular game frameworks and programming languages, if none of them suit your needs you'll either have to reconsider your toolkit or write your own loader.
The Bottom Line
A designer alone may not have much use for R.U.B.E., because odds are if he/she is using a prefab game engine like Game Maker or Unity he/she'll be using its respective built-in editor. But for programmers or designers working with programmers, R.U.B.E. is a solid investment. R.U.B.E. is flexible enough to play well with any custom game engine, yet simple enough to make entertaining game worlds with ease. I wholeheartedly recommend taking the \$30 plunge.