Arc collision using box2d

[Nathan]

Hiya,

I'm just getting to grips with what RUBE/box2d is capable of. For something like colour switch, would you recommend using rube for this?

Colour switch image (in-game the ball is one of the four colours in the circle):


I can see two ways of doing this:

1. I'd need to create several arcs for each circle. So I could draw the arcs using java and then look into boolean subtraction to check for collision (seems quite tricky)

Or

2. I could do something along the lines of adding a body with an n sided polygon fixture and then use something like a bevel curve to get a close approximation to a circle. A quick mockup:



Which method would you use?

Also, as this game has an infinite mode I'd like to be able to continuously read in new rube scenes every so often. I know you don't have experience with the Libgdx rube loader, but in your experience, would it create too much lag to continuously read in JSON files while the game is being played? Thanks!

[iforce2d]

Unless you really need to use polygons for some reason, I would probably do that with arc (line) shapes, which would be less collision detection work for the engine to calculate. This video should explain what I mean: https://youtu.be/HEjse56N8kA

You could add a custom property to each of the fixtures to define what color it is. Keep in mind that if the ball hits near the border of the arcs you can get a collision event for two arcs in the same time step.

In practice I have not found a scene that takes more than a fraction of a second to load the world or a bunch of bodies, even some of my large test scenes, at least on a desktop computer. However, you may be running on a slower system, and even a fraction of a second is too much to fit into the game loop without a jarring pause, plus you will likely be setting up other resources (texture load etc) as well. The only way I can see this working out smoothly is to cover it with some in-game fudgery that lets you pause the gameplay or screen scolling a little, eg. I'm thinking of the way some games freeze or shake the screen for a tiny moment to emphasize an impact, eg. https://www.youtube.com/watch?v=fv5yrq3IGQ8

If you have just a few moving bodies in the world, another possibility is to load/generate a large section of game ahead of time, say enough for a couple minutes gameplay, and while that is playing, load/generate another large section in a second thread, as a separate b2World. These two sections would need to have a small overlapping (duplicated) portion at the end. When the player gets to the boundary point you can switch from one world to the other (copy the velocity, angular velocity etc of the ball to the new world). This would be ok if it's one of those games where you can only progress in one direction, but would be a pain in the ass if the player can go forward and back at will.

[Nathan]

Thanks for the reply. I think I'll experiment with the line shapes for arcs. As for infinite levels, I'm not too keen on freezing the levels, I'll have to see how old Android devices do with loading in JSON files into current/separate worlds.

Perhaps I could just have one Rube scene with all the different shapes/obstacles (e.g. 50 different obstacles). Then I could randomly choose one obstacle and move it to the player's current position. Rinse and repeat. Can you see any issues with this?