I'm currently developing a top down, realtime, zombie shooter. I'm coding this in Java, using JBox2D as my physics engine. I have been coding the networking this week, and am now up to the physics synchronization.

I'm planning to use the predictive client/authoritative server model, where the client is free to move, as long as the server approves of it later. This involves the client sending packets containing movement data to the server, and the server calculating latency, and re-simulating the world from an older state.

My problem is, my current physics engine, JBox2D (basically a port of Box2D), doesn't support rolling back the world, and apparently isn't that easy to serialise the world data. I have 2 solutions, I could either modify/extend my current physics engine, or write my own.

Reasons for writing my own physics engine -

  • I can remove unnecessary features. In a top down game, I only really need collision mechanics, and handling forces. No gravity is involved.
  • I can understand the code better, and it would [most likely] be easier to implement roll back functions

Reasons for extending/modifying JBox2D

  • Writing my own physics engine, would be a significant amount of work, which could be cumbersome
  • JBox2D has a widely supportive community, that can help me with my dev
  • JBox2D, has specific optimizations, for things like collision detection, which make it useful
  • Some work as already been done on this, but little code has been shared

So what are your opinions. This is my first game, and I am no way a professional game developer. If anyone could provide some links to work already done in the area (preferably using JBox2D/Box2D/Java).

  • \$\begingroup\$ Also note that if you use JBox2D, you will need to use strictfp everywhere, which will seriously impact performance. Otherwise the server and the client may not get exactly the same results. I would recommend using fixed point instead. \$\endgroup\$ Dec 12, 2011 at 10:04

1 Answer 1


Collision detection in 2D is so damn simple I don't know why you would even bother using a physics engine in the first place. And since all handling forces are straight forward or on a curve (no falling, altering diagnals etc.) Personally it's a no brainer to me which you should pick. Making your own is simple. Collision:

account for the 3 possible collisions that can happen in 2 rectangles:

  1. Edge to edge: Pretty simple, you get the axis of a single edge, and another and you decide whether they occupy either the same space or near enough to it.
  2. Edge to corner: This will easily be the most common if you have rotating shapes. Luckily, it's also quite simple to implement.
  3. Corner to corner: This will happen so rarely that it's not even worth implementing. The reason for that, is that 2 things would have to be moving in exactly opposite directions on the same exact axis down to your engines last calculated decimal. Now, if everything rotates by 45 or 90 degrees, this MAY (even still probably not) be worth including

EDIT: As commented, I'm far less familiar with this matter, and should not be consulted about the bullet/projectile collision.

When I have worked with bullets in 2D space, I used a sort of pathing that worked in both straight line and curved where I would throw the projectile using the physics engine (that I did not make from scratch) and use standard collision.

Read about building this from scratch in the comments.

EDIT: *Trust me,* regardless of which, you will need some form of dead reckoning in your games engine, because of the projectiles and how many projectiles could be on screen at any given time. You ABSOLUTELY do not want to update every single bullet on screen per frame at it's given location. But it's a great way to make a game unplayably slow :D! You should only ever update these things:

  • A projectile is being thrown
  • The direction it's being thrown at
  • Whether or not it's curved
    • And if so, what is the function of the curve
  • What projectile it is (This accounts for the graphic, effects, damage, everything)

Now update the data in the engine accordingly to that data, rather than on the server for each damn projectile, and send out packet data for every single bullet. (Imagine doing that with even just 2 machine guns on screen! Jesus!)

  • \$\begingroup\$ Of course its relatively easy to implement, but I'm also interested in the optimization of collision detection, which I have no idea how to implement. \$\endgroup\$ Dec 12, 2011 at 11:29
  • \$\begingroup\$ The method I described really won't require optimization if you do it as described. The only optimization that may be needed, is the time that you preform the checks, and how often collisions are actually updated. Eg: They REALLY only need to be updated when there is a possibility of collision. \$\endgroup\$ Dec 12, 2011 at 11:34
  • \$\begingroup\$ To expand upon what I last stated. You only really need to check for building collision for example, when your character is moving in the first place. You only ever need to check for unit collision, when you even have units in view that aren't your character. You only need to check for projectile collision, when they even exist (at that moment). You can skip any form of collision type detection (is it edge to edge? corner to edge? etc.) after you know that something is even touching something else or close to it. Otherwise, skip it overall. \$\endgroup\$ Dec 12, 2011 at 12:09
  • \$\begingroup\$ Except when I'm processing collisions server side, in which I need to detect collisions for multiple players etc. \$\endgroup\$ Dec 12, 2011 at 12:16
  • 4
    \$\begingroup\$ @MadPumpkin: your overconfidence reflects badly on your answer; you are talking about detecting collisions, yet you don't mention sweep collision detection which is at the absolute core of proper bullet handling in a 2D shooter. Also, even with sweeping, resolution is about as important as detection since you need to decide which collision happened first, resolve potential conflicts, and maybe start the whole resolution again in case of removed entities. Certainly not the trivial matter you appear to be implying it is. \$\endgroup\$ Dec 12, 2011 at 12:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .