Approaching pool ball movement

Me and Hemul1 came up with a game idea based around pool (or billiards) and decided to pursue the game as a joint venture.

What we're aiming to do is have a somewhat simple pool game, combined with another form of gameplay. Simple means that there'll be no way to strike the cue ball from different angles to create back or top spin.

As such I started testing out ways to do the pool part of the game. Searching the forums I found an example using the physics behaviour.

Thing is I can't work with the physics behaviour to save my life. Even back in CC I hated, hated, using physics, because I could never get it to work the way I want it to. Maybe I just suck at working with it, I don't know. The objects eventually always go into sleep and become completely immovable, etc.

So I started looking at alternative solutions too.

The way I see it, we have at least four different ways to approach it.

1. We use physics anyway, and try to wrestle it to do what we want.

2. We use bullet behaviour to handle ball movement and bouncing off walls. But we still have to handle ball-to-ball collision with events.

Would involve some math.

3. We use custom movement for the entire thing. Would involve WAY more math.

4. We do everything with events, no behaviours. This obviously involves, like with custom movement, lots of heavy math.

The upside to 1 and 2 is that we get a lot of the work done upfront. Downside would be that we have to work around the behaviours to get them to do what we want. A collision between the balls, using physics, is not accurate to how pool balls behave, and a collision between balls using bullet behaviour just straight up isn't.

Upside to 3 and 4 is that we'd have much higher control over how the balls behave. Downside being, as stated, heavy(-ish) math. Neither of us are all that proficient with heavier math though, but that's something can be researched.

So, which approach is best? I realize that there's not a clear answer to the question, but I'm kind of stumped currently.

From my point of view is clear that behaviors are not giving you the results you expect. Tweaking them can have a big chance of not getting were you want to and still taking a lot of work.

In this case I would particularly go with number 4, since it seems you want full control of how the balls behave. I would remove the variable of having "unpredictable" behaviors to any extent, so there's no chance of getting stuck in any way.

If you are confident that you can do it through events and have a good clue of how to do it, I would say go for it. Otherwise consider your current capability and take what you fell most comfortable with.

Thanks a bunch R0J0hound! I haven't examined the capx or the articles in detail yet, but I ran a preview of the capx. Very nice, definitely shows it's a better idea to go with method 4. Even if it might require more work.

I had previously found this article: archive.ncsa.illinois.edu/Classes/MATH198/townsend/math.html

With that, the articles you linked, and the capx to use as a guiding post, I think we can get something down.

I skipped the angular motion, and it will lock up if you design a layout with objects overlapping, but other than that it looks alright.

Hm, we might want to add angular velocity so that we don't have to fake too much of the ball rolling animations.

With objects overlapping I trust you only refer to the ones that are colliding?

We are going to show the pool table at an angle, and in order to not have to further compensate balls colliding with an angled surface, I figured we'd use the Mode7 plugin you posted not too long ago.

Here's a test I did: https://dl.dropbox.com/u/22615804/bbbb-mode7/index.html

We're not gonna rotate it and such during gameplay. I'm only using the effect to get the table angled.

The collisions are pretty crisp due to the method used in the tutorial, but it's pretty slow when many collisions occur at once.ow many collisions did you consider many? I haven't noticed any slowdown. It stays at a nice 59-61~ FPS for me. Though I recently upgraded and am now running an i7 system, which could explain it. The primary target platform is Ouya though, so if it's too heavy, that could be an issue.

I also noticed that there's constant motion. Even if a ball comes to a stop another one soon enough bumps into it and sends it off with renewed force. Though I'm sure it's not too hard to fix.

ith objects overlapping I trust you only refer to the ones that are colliding?

Yeah, but let me clarify, C2 treats both objects in contact and objects on top of each other as colliding. For the algorithm used I mean the latter, objects on top of each other.

e are going to show the pool table at an angle, and in order to not have to further compensate balls colliding with an angled surface, I figured we'd use the Mode7 plugin you posted not too long ago.

Here's a test I did: dl.dropbox.com/u/22615804/bbbb-mode7/index.html

We're not gonna rotate it and such during gameplay. I'm only using the effect to get the table angled.

With that you're going to need to figure out the perspective transform to map the balls to the correct positions on the table. I haven't done this myself yet but here is a link that has the math:

http://www.coranac.com/tonc/text/mode7ex.htm

ow many collisions did you consider many? I haven't noticed any slowdown. It stays at a nice 59-61~ FPS for me. Though I recently upgraded and am now running an i7 system, which could explain it. The primary target platform is Ouya though, so if it's too heavy, that could be an issue.

If I double the object count it noticeably stalls when about five or more collisions occur, but it may very well be due to my 1.5ghz single core 10 year old computer. There is a lot that could be done to make it go faster, such as calculating the time of collision instead of iteratively finding it and using a spacial hash of some sort so collisions are checked against only the other nearby balls instead of all of them. In my capx the most blaring inefficiency is collisions are checked between every ball with all the others twice. It could be improved to once if the collision pair were saved to a list somehow.

also noticed that there's constant motion. Even if a ball comes to a stop another one soon enough bumps into it and sends it off with renewed force. Though I'm sure it's not too hard to fix.

Yes it's pretty simple to change the formulas to take into account acceleration for friction. The elasticity can probably be changed from 1 (perfectly elastic) to 0.9 so that it's more realistic.

Ok, before I even think of going further into this and start trying to work the math.

R0J0hound Would the mode7 effect override C2's built in z-ordering?

If not (like I suspect), then it's a full stop and move to another engine for the time being, because for this to look good we need proper z-ordering, which C2 doesn't have yet (EDIT: well, more accurately, proper z-ordering tools. The z-ordering itself works fine, you just can't work with it well during runtime). And afaik it's not looking like Ashley's putting it in any time soon (if I'm wrong on this Ashley, please do tell).

EDIT: Well, now we got better z ordering tools, so that point is moot.

All is well.