[Libgdx, Box2D, KryoNet] Saving huge amount of Sprites + Box2D-Objects

[BadBreath]

Hello everybody,

my name is unimportant, so call me »BadBreath«.

I'm currently working on an ambitious – maybe or likely even overambitious - project, that is my first game project ever.

As I'm studying to become a software engineer I sat down and thought about things I could do to heavily improve upon my skills. It basically ran down to two things, working on an operating system (and thus learning C – which I must do anyway -.-) or trying to combine my hobbies and passions and mix everything together, jump into cold water and try making a game.

So guess what, here I am, seeking your advice on problems I wouldn't face if I didn't make dumb decisions in the first place *g*

Anyway I want to give you a short overview about what I'm trying to do.

So, basically I try to create an a bit more advance jump&run where you face real physics and a huge amount of blocks you have to destroy to reach your target.

As if that wasn't ambitious enough I also try to improve my networking skills, which are far more than rusty.

For all of that I'm using Libgdx, Box2D and KryoNet to »help« me. (Honestly I though these awesome libs and frameworks would just need me to give them some voice-commands and do the rest for me … hell, it's 2013 already!)

So I created the fundamental basis of the whole project but now I'm stuck a bit with everything, most of all performance.

The thing is that I create (or wanna create) a huge amount of blocks at the beginning. So there should be ten-thousands of Static Box2D Blocks that make up the world and their corresponding sprites. Obviously that's way too much to load, even for the 16GB-Ram-Monster-Machine I'm working on, not to speak of other systems. (If this gets done – and I tend to finish the work I've started – I want others apart from NASA and NSA to be able to play this little game!)

So I thought about a Saving-System. There are two different approaches that came into my mind – the implementation of both being built upon Kryo(Net).

1) Upon creation I save the whole world into one file and when the game starts / updates I only load the X blocks surrounding the (local) player.

I'm biased on that one. Wouldn't it all come down to a very fast algorithm if I jump around the world at maximum warp-speed?
Also, if another player breaks blocks I need to save them locally as well :/

2) Upon creation I save the world into multiple files of the same size and load them when passing a(n invisible) border.

Not sure about that one either. Are there better solutions?

I really couldn't find anything regarding this problem. Either it's way too trivial or it's one of the more advanced tasks.

Thanks a lot for any advice in advance!

Kindest regards
BadBreath

PS: English is not my mothertongue, so sorry if something is unclear because of that

[Orangy Tang]

Don't save the sprites and box2d objects directly, save a more abstract representation of your world (eg. a 2d array of tile ids), load that, then create sprites and box2d objects from that.

Also, you don't want to create a box2d object for each tiles, you'll want to combine multiple adjacent solid tiles into a single big box where possible.

If you want a big world that you load in/out as the player moves, then splitting your world into multiple files based on world chunks is the usual way of doing it. The trick is getting the right chunk size so that your loading is quick enough but you're not holding too much at once.

Other than that it's hard to give more info without know what kind of game you're after. 2d? 3d? Some kind of top-down zelda game? Platformer?

[BadBreath]

Hello Orangy Tang!

Thanks a lot for taking your time to answer.

Well, it seems I forgot the passage about what exactly my game will be about. It will be a 2D-Plattformer where you can destroy different blocks.

I'm not sure it really is more performant to create new (bigger) Box2D-Objects as every tiny little block should be destroyable, just like in Minecraft or Terraria for that matter.
(Please, don't misinterpret this, I'm not saying my approach is better, I'm saying I'm not sure! You're the experts here and you lacked some information I just provided! )

The thing with saving is far better than my approach, thanks a lot for this. I'll have to see how I'll do that on the fly though. I mean, on the initiali loadup I can create the whole world, but I don't want a loading screen or stuttering when players move as the world will be created from the abstract format just then.

I'd love to see some implementation of this :/

Games published by our own members! Check 'em out!

[Orangy Tang]

I'm not sure it really is more performant to create new (bigger) Box2D-Objects as every tiny little block should be destroyable, just like in Minecraft or Terraria for that matter.

If you've got a chunk of solid platform that's 10x10 tiles, that'll be 100 box2d objects, or 1 box2d object if you merge it. The second will be *much* faster. You can still destroy individual blocks, just break them apart into smaller ones when tiles are destroyed.

Also having tiles each with a rectangle means you'll get internal edges (see the faq 'tile based environments' https://code.google.com/p/box2d/wiki/FAQ )

Using many boxes for your terrain may not work well because box-like characters can get snagged on internal corners. A future update to Box2D should allow for smooth motion over edge chains. In general you should avoid using a rectangular character because collision tolerances will still lead to undesirable snagging.

If you poke around in the box2d manual it suggests that an even better solution is to use 'edge chains' to stop this snagging behaviour instead of just collision rectangles.

[BadBreath]

I'm not sure it really is more performant to create new (bigger) Box2D-Objects as every tiny little block should be destroyable, just like in Minecraft or Terraria for that matter.

If you've got a chunk of solid platform that's 10x10 tiles, that'll be 100 box2d objects, or 1 box2d object if you merge it. The second will be *much* faster. You can still destroy individual blocks, just break them apart into smaller ones when tiles are destroyed.

So, upon breaking one tiny block I "simply" destroy the old, big Box2D and splite it into 2 or 3 new ones (depending on where the block I destroyed lay.

I mean if I have this simple setup:

----------

and I destroy the first block I get this:

x--------- so 2 distinct box2D-Objects.

But if I destroy one not at the edge I get 3:

--x-------

hm. Well, I'll have to find a fast algorithm for re-creating new Box2D-Elements on the fly then.

Also having tiles each with a rectangle means you'll get internal edges (see the faq 'tile based environments' https://code.google.com/p/box2d/wiki/FAQ )

Using many boxes for your terrain may not work well because box-like characters can get snagged on internal corners. A future update to Box2D should allow for smooth motion over edge chains. In general you should avoid using a rectangular character because collision tolerances will still lead to undesirable snagging.

If you poke around in the box2d manual it suggests that an even better solution is to use 'edge chains' to stop this snagging behaviour instead of just collision rectangles.

Hm, I'll have to dig deeper I fear, because I haven't understood everything yet.