next »

[deWiTTERS]

Short intro: I'm making an RPG editor that allows you to create your own 2D RPG in Flash.

Currently I have simple tile-based movement (really restricted to tiles), but I want to go to pixel movements to support making Action RPGs.

Now there are 2 possible ways to go forth:
1. Handle collisions and movements with Box2D (physics engine)
2. Implement my own movement and collisions

As I currently see it, Box2D has the following advantages:
1. Don't have to implement vector movements or collisions myself
2. My users (=game designers) can tweak the values to customize the gameplay feel.
3. Easy to extend my game editor to other genres (because of the more generic solution)

Disadvantages (or uncertainties really):
1. Can Box2D handle collisions inside a huge tilemap? Tile collisions are static objects, but still might require a huge amount of them for big tilemaps.
2. Can Box2D simulate old-school movements? Without too much damping? Might require a lot of tweaking.
3. Weird physics glitches where objects start acting strange.
4. Pathfinding might become more difficult to implement.

If I would just make an Action RPG game, I would go for implementing it myself because of the total control (and still not that hard to implement yourself). But since I'm making an RPG editor, Box2D brings a lot of advantages like tweaking options and future extensions. Plus using Box2D is a more generic/modular solution.

Anyone got any experience with Box2D that can give me some hints? To get an idea on how I want the game to feel, see Hyper Light Drifter footage:



If I would go for the Box2D option, first thing I would test out is see if I can get the right feel on moving the main character.

[Allen Chou]

By "old-school movements", I supposed you meant "tight control"? You can make rigid bodies in Box2D "kinematic". A kinematic rigid body strictly respects the velocity and position you set to it, and does not "budge" or "float" when interacting with other objects.

IMO using a full-blown 2D physics engine like Box2D just to have tile-based collision detection is an overkill. I would go with your option 2.

[RandyGaul]

Allen is right.

Kinematic means that the physics engine will integrate velocity for you, and if any *dynamic* bodies touch the kinematic bodies, the *dynamic* bodies will be pushed away without affecting the kinematic body. That's it. All custom behavior of anything kinematic will still need to be written for your specific game requirements.

If you don't really care about the above 2 benefits, then there's hardly any point in integrating a physics engine. In your example GIF, those effects can be achieved with collision and velocity integration. For collision detection just use circles and AABBs. For integration use symplectic Euler (Euler is 2 lines of code, swap the lines to get symplectic).

[deWiTTERS]

You suggested to go for option 2, but after reading your explanation, I'm actually more convinced to go for option 1 .

I didn't know about kinematic bodies, but as you say they can indeed provide fine grained control over the game entities. If you look at the gif when those enemies are pushed back, they seem to have a constant velocity, and are instantly stopped.

Box2D might indeed seem like overkill, but that also means I get collision detection and simple velocity integration for free. I agree that it's not all that hard to implement yourself.
But like I said, I'm creating an editor and not a game. Using Box2D would open up other features for the future. I can imagine flying enemies are better controlled with manipulating forces/acceleration, and my users might want to use some simple physics (boss with huge flail comes to mind ). Complex collision shapes also comes for free, etc.

Anyway, thanks for the explanation! It definitely helped me a lot. 

[RandyGaul]

I didn't know about kinematic bodies, but as you say they can indeed provide fine grained control over the game entities.

To be clear a kinematic body does not provide anything. It doesn't give any fine grained control. All it does is integrate velocity and push dynamic bodies.

[deWiTTERS]

To be clear a kinematic body does not provide anything. It doesn't give any fine grained control. All it does is integrate velocity and push dynamic bodies.

Yes, I understand. But the alternative would be to put a force as large as the wanted speed on a dynamic object to get it started, and a force as large as the speed to get it instantly stopped. Seems a recipe for strange quirks to me . With kinematic objects I can set and change the speed as I want to, I understand, don't worry .

Just to give you a little background, back in 2003 I implemented my own spring physics for PocketPC game Trial Challenge. So I'm not a complete noob, I just haven't kept up with what current physics engines support .

[dancing_dead]

offtopic, but you should probably reconsider using flash for this. internet seems bent on finally killing it.

[deWiTTERS]

offtopic, but you should probably reconsider using flash for this. internet seems bent on finally killing it.

Yeah I know, I'm having a heated discussion right now at Hacker News about it (user koonsolo is me ). Getting a lot of up and down votes at the same time .

Anyway, I was already keeping an eye on OpenFL for that same reason. Haxe and AS3 are very alike, so a port will be very straight forward and fast. I have a lot of experience of porting game code from one platform to another, so that won't be a major issue. And Box2D is supported! I just hope HTML5 will be up to par once Flash gets killed. If not, web game developers will have to resort to the other plugins: Java Applets or Unity3D or ... .

But thanks for the heads up!

[piotrj]

I would suggest option 3, use box2d for collision detection only. This way your collision detection is very fast and you can tune your movement as you see fit easily. Getting movement tight is fairly hard with box2d, but not impossible. Top down is still a lot easier than side view.

[deWiTTERS]

So, stubborn and obstinate as I am, I used Box2D anyway . It was actually not that difficult to do. Got it working in about 2 days. Here's a preview with Box2D debug drawing enabled:



Had some issues with keeping the NPC's at their position while bumping into them (tried various solutions). Even bumped into some strange behavior when switching from dynamic to kinematic bodies (while running the simulation), but in the end got it working as I want. Collisions and handling is done by Box2D, which is a huge time saver.

Combining physics with the round collision shape is also great for walking into narrow spaces where the collision shape barely fits. Very pleased with the result!

Edit: Adapting my A* algorithm to let the box2d body follow the tile path was also not that difficult. I just set an impulse to the next tile, and when arriving at that tile, setting the impulse towards the next tile in the path.