LÖVE

I plan on making a game with physics, and it's going to get bigger as you get farther away from the starting place. What should I do for smallest and largest positions in love.physics.newWorld()?

Thanks

Box2D has many constants so you're not going to be able to create a super huge physics world populated with bodies.
Even if you could create something like that, the lag of simulating it would make your game unplayable.
What you could try is to generate the physics objects as the player nears them.
Another approach is to split your 'infinate' world into 'screens' like in the original Zelda.
In both cases you would keep the bounds of your Box2D world farily small.

miloguy wrote:I plan on making a game with physics, and it's going to get bigger as you get farther away from the starting place. What should I do for smallest and largest positions in love.physics.newWorld()?

Thanks

You cannot have really infinite world within finite amount of RAM (unless your world is procedural). You need to think about your game design. For the beginning, you can make it "big enough", then splice it as needed.

ivan wrote:Box2D has many constants so you're not going to be able to create a super huge physics world populated with bodies.
Even if you could create something like that, the lag of simulating it would make your game unplayable.
What you could try is to generate the physics objects as the player nears them.
Another approach is to split your 'infinate' world into 'screens' like in the original Zelda.
In both cases you would keep the bounds of your Box2D world farily small.

I should point out that people are always hating on Box2D around here, but in practice you can actually make a pretty big world. The largest subsection in, say, A Link to the Past, is easily within the limits of Box2D.

As a functional example, my platformer Kurosuke creates worlds that are 16384 units wide/tall by default. I can go larger, but I want to keep multiplayer running smoothly on netbooks (I have a little Asus that I use for testing).

I faced the same dilemma in my game, miloguy. After a lot of thought and testing, I ended up finding out that the best solution was to drop Box2D and make my own physics system.

That's what I'm doing for my 2D sidescroller engine. It's coming along pretty well and I haven't even touched Box2D, even for collisions. Box2D never works well, or at least realistically, for platformers. Yet everyone tries to use it.

Jasoco wrote:Box2D never works well, or at least realistically, for platformers. Yet everyone tries to use it.

Yeah I tried that... didn't work out well. Box2D is about being realistic, and that's not what platformers are.

Jasoco wrote:That's what I'm doing for my 2D sidescroller engine. It's coming along pretty well and I haven't even touched Box2D, even for collisions. Box2D never works well, or at least realistically, for platformers. Yet everyone tries to use it.

I guess Kurosuke is of no count, then.

Seriously, why do we even have Box2D in Love if everyone hates it so much?

tentus wrote:Seriously, why do we even have Box2D in Love if everyone hates it so much?

People often misunderstand its uses (or how to use it) because it's essentially a whole new API on top of regular LÖVE. I personally love it, but I also know when to use it and when to stick with my own solution.

tentus wrote:

Jasoco wrote:That's what I'm doing for my 2D sidescroller engine. It's coming along pretty well and I haven't even touched Box2D, even for collisions. Box2D never works well, or at least realistically, for platformers. Yet everyone tries to use it.

I guess Kurosuke is of no count, then.

Seriously, why do we even have Box2D in Love if everyone hates it so much?

The question is why everyone hates it And why do we have Box2d in Love? Because everyone has it (it is common on iPhone, Android, and in other game engines).
So I guess it is good to have it also in Love (despite the fact that I have never used it).