2D-MMORPG physics engine

Newbie & Debugging Questions
#1

Would it be more efficient to use Box2D collision detection for a 2D-MMORPG, or could it be more efficient to design my own physics engine? I’m mainly worried about calculation costs on a larger scale with hundreds of players.

What I have: So far I am working on my own physics engine that is an attempt at being as optimized as possible. I am using a tiled map environment and only check the tiles in the direction of the players movement(rather than checking against all stored collision tiles). Player movement is smooth movement(pixel-by-pixel) therefore collision detection happens for every round within the update() function. So far, my engine works great for collision against tiles.

What I ‘eventually’ want: The end goal is to be able to detect collisions with certain specified tiles, and also to have player vs player, player vs monster, player vs skill, monster vs skill collisions.

With that being said, should I just save the time I’m currently spending on making a physics engine and just use Box2D? Or should I keep going because maybe Box2D is too bulky for what I need it for? I’m essentially trying to go for the most efficient route possible, and am wondering if Box2D would be appropriate for games of very large scale and large amounts of collision?

#2

It depends on what you need. I guess for 2D you can go and write your own physics engine, as long as it doesn’t include rotations. It also depends on how you want the objects to interact. Though I doubt that you will run into performance problems on modern PCs with Box2D when only having few hundred objects. You should just try to setup a test and see how well it runs.

#3

Well if you think about it clearly.

You have a tiled map. Your player might be on two different tile at the same time and you apparently check for collisions in the directions he’s moving. So given that you would actually check for 2 up to 4 tiles collision, we can think of 6 or even 8 or 10 if your player moves really quickly. Which leads for a hundred of players to at maximum 1000 collisions which is ridiculously not enough to worry about performance. You can start to worry when you reach the 10^5 not so optimized collisions ( well on my engine i can run 10^6 collisions in less than 10 ms so it depends on the level of optimization of your collision method).

Now if you have other collisions to does you might as well calculâtes the number of collision check that might occur and see about that number.

#4

If you want box2d level physics then you’re better off sticking with it. Just be sure to make your game deterministic and probably opt for some kind of lockstep model for syncing the clients.

#5

Thanks for the replies!

I imagine setting up a test would be hard at the moment as I have not worked on network connectivity for the game at all. It would just simple be single player as we speak. I was thinking more in longer term before I burn a lot of time making the physics engine.

It sounds like I’m going to have to dig a little into Box2D source code to see how they are determining their collisions. My main question is whether or not Box2d is efficient. It’s easy for us to all implement an engine, but I just want to know if Box2D was written with high efficiency in mind. I’ll be staring at their repo link: https://github.com/erincatto/Box2D/tree/master/Box2D/Box2D

#6

Yes, of course it was written to be efficient. That’s the whole point.

But in my humble opinion, you’re asking the wrong question.

Box2D was written to be efficient at performing a specific task. That task is calculating rigid body physics and collision in an arbitrary world space.

So the question is not: “is Box2D efficient?”, it’s: “is Box2D the right tool for my job?”

You’re talking about tile-based collision, which doesn’t seem to jive with Box2D. Mario doesn’t need to use Box2D. If you’re comparing Box2D’s “efficiency” against a tile-based collision detector, then that’s a completely different question. You can’t really talk about efficiency without defining exactly what you mean by “efficient”. Otherwise you’re comparing apples and oranges. You’re also talking about an MMORPG (which is an entirely separate issue, but I’ll digress on that one for now), which doesn’t seem to jive with Box2D either. What portion of collision calculations are you doing on the server? What are you doing on the client? These are questions that you should answer now instead of later, and they should come before you start asking about the “efficiency” of Box2D.

#7

Kevin, I’m glad you posted because I think you’re the reality check that I may need – hopefully you’re able to get back to me.

When I first registered and asked for some advice in regards to an mmorpg, I was told that I could focus on making a single player model of the mmorpg game that I am aiming to build. Furthermore I could plan for network and scaling later after I get a good foundation of player, monster, and environment. Is this a poor approach? My overall goal is to detect player vs environment collisions via tiles, and player vs monster collisions via the objects themselves.

Could you elaborate on why Box2D would not be the best approach for handling collisions? I’m starting to get the feeling that I have started programming from the incorrect approach. I have handled nothing in terms of client vs server and only have a single player instance of a game that I would eventually like to make open to other players once things look a little ‘nicer’. Alternatively would you be able to point me to reading material that you think may be helpful for a person in my position?

#8

[quote=“Void_Massive,post:7,topic:55233”]
I really don’t mean to be discouraging. In fact, I think the only way to learn how to program is by, well, programming! So you’re already off to a good start, just because you’re trying something.

That being said, underestimating the scale of a project is a mistake that novices (and non-novices!) make all the time. After all, what does the first M in MMORPG stand for? :stuck_out_tongue:

[quote=“Void_Massive,post:7,topic:55233”]
In general, my advice is always: start smaller. Break your problem down into multiple individual steps. Break those individual steps down even further. Create prototypes that explore one aspect of your larger goal. Create a single-player game to help you figure out how Box2D works, or how it scales. Create a separate non-graphical game that explores how networking works. Keep these “games” as simple as possible. When you get each one working separately, then (and only then) think about combining what you’ve learned into one bigger piece.

So, sure, you should focus on the basic collision detection and whatnot first, especially if you haven’t finished a game before. But I would argue that it’s a waste of time and energy to try to make decisions now, at the prototype level, that will affect your big end goal.

By that I mean: you should start by making Mario. Explore how collision works in a game like that. Don’t worry about whether what you’re doing will scale or not, or how networking will affect it. Create a small game that uses Box2D. Start over and recreate that same game using basic tile collision. Boom: now you know how to use both.

Then start over again and create a networked chat application. Build from these small steps towards an end goal, but don’t try to make decisions about your end goal until you can pretty much answer the questions yourself.

It’s a bit like this: let’s say I don’t know how to build houses. I don’t even know how to build a tree house. I have no idea how to create a roof that won’t leak, let alone how plumbing or electricity works. And now I ask you: I’m planning on building a castle, so which type of wood should I use for the drawbridge?

The answer to that question is that I shouldn’t be asking that question yet. I need to practice by maybe building a fort first. When I figure that part out, maybe I should move up to a treehouse. Maybe I should separately build a little moat and see what types of bridges work best, without even worrying about the castle that will be inside that moat.

I’m not sure if that metaphor works, haha.

[quote=“Void_Massive,post:7,topic:55233”]
Box2D might be a fine option. It’s a great option for a single-player physics game. Is it the best option for a non-physics game that can just use simpler tile-based collision detection (like Mario)? Probably not, only because it’s overkill. Is it the best option for a game that handles collision detection on the server? Maybe, but your entire setup will look completely different, and what you define as “efficient” might mean something else.

My real point is that we can’t really answer the question for you. It depends more on your personal preferences and coding style, and more on the exact type of game you’re building (which even you probably don’t exactly know yet), more than it does cold hard technical facts. The only way to get a more concrete answer is by building small prototypes that test out different theories.

[quote=“Void_Massive,post:7,topic:55233”]
I wouldn’t say that you’ve got an incorrect approach, just maybe an overly optimistic plan. Think about it this way: you’re working on a single-player prototype right now, not your final goal of an MMORPG. That final goal comes later, after you’ve built up some knowledge about how these individual pieces (collision detection, networking, etc) work.

[quote=“Void_Massive,post:7,topic:55233”]
The best advice I can give you is always: start smaller. Instead of asking about how efficient Box2D is for an MMORPG (which we can’t really answer, because that question is extremely broad), build a small prototype that tells you more about how many entities Box2D can handle, what types of information it gives you, etc. Then do the same thing with tile-based collision. Repeat until you can start combining these fuzzy concept into a more cohesive whole.

And if that sounds tedious, well, welcome to programming!

Edit: I am reminded of this: http://yourgameideaistoobig.com/

(Again, I’m not trying to be discouraging! We all tend to bite off more than we should be chewing- that’s part of the fun of being a programmer! But the only way to get to our big end goals is by starting smaller and working our way towards them.)

#9

Don’t even worry! In many ways I’m looking for more of a blunt and direct answer. I’m very familiar with developing and have a lot of java background, but I’ve only recently decided to try and make a game when I’m not at work. It’s just something that I have avoided because in the back of my mind it seems like such a massive task that I literally wouldn’t know where to start or what books to read – so I posted here and just started coding to the best of my OO ability.

I really appreciate your detailed response and I think you have pointed me in the right direction. I’m going to take all of your advice and make a small communication application, and elaborate from there. Your post will be my mini-bible for the next week or two, and then I’ll most likely report back with whatever i run into. I hope many people starting out will stumble upon your response as well!

Here is also a nice read for anyone else that may be in a similar situation as me: http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/

Best~

#10

Along with starting much smaller, you might look into participating in game jams. Ludum Dare is in 3 weeks, and it’s a great way to force yourself to work on smaller games. But smaller game jams are happening all the time: try http://jams.gamejolt.com/browse/active or http://itch.io/jams for a start. Also check out One Game a Month.