Pulpcore Pool Game (Advice Please).

Game Mechanics
#1

After quite annoyingly wasting an hour playing a miniclip pool game this afternoon it ocurred to me it ‘may’ be relatively easy to write a simplified version of one using Pulpcore.

I put this together in about 2 hours using Pulpcores bubblemark code (ok, I nicked a pool table/cue from the net, so will replace the stolen graphics if I continue with this). Doesn’t do anything yet!

http://www.bullsquared.com/pool/pool.jsp (Pulpcore applet)

Source code for those not familiar with Pulpcore/Bubblemark tests here:
http://www.interactivepulp.com/pulpcore/bubblemark/
http://www.interactivepulp.com/pulpcore/bubblemark/src/Ball.java

Question, is: I know nothing about ball physics/java physics libraries etc… (Can’t say I even understand the Ball.java elastic collision code either)… Anyone know if it would be easy to change this (the vx/vy velocities) to put in some ball momentum code so the balls actually stop (easy noob examples please?)… Or would it be better to use a physics engine and if so, which one? I guess for cueball top/back spin and side would have to do this myself regardless (or do any of the physics libraries handle this too)?

Not sure whether I’ll continue with this one (depending on complexity of physics) or add the ever growing uncompleted work shelf!

#2

It’s been done so many times, if you have no real spark for the game or the physics i don’t see why bother…
But, Basic ball to ball collision already being there, (though if you look at it a bit it allows balls to pass through each other every so often) there should already be velocity / acceleration variables to tweak, f.ex. (acceleration * 0.9) dampens speed nicely, depending on your unit scale of course.
Adding curves is also doable, easiest by adjusting the direction of the ball i.e. cheating, not by actually modelling the spin and friction to the realistic level.

#3

I like this simulation:
http://compsci.ca/v3/viewtopic.php?t=14897
It looks ahead to determine how long until the next collision. When you step the simulation, if a collision would happen within the step, it steps the simulation to the collision, does the collision response, and then steps the rest of the way (or until the next collision). This is really neat, but the math is a bit hairy (although it is done for you in that thread). This approach works well with a box, but less so if you want advanced features like pillars or whatever inside the box, or if you want curved trajectories.

The other (less cool but simpler) way to do it is what you already have. Just apply a constant friction to slow down your balls. Eg, vx *= 0.9.

Your pool game will look more realistic if you use two friction values. If your velocity is below some threshold, apply kinetic friction, otherwise apply static friction. The reason why is when a pool ball is hit, it is not yet rolling. The ball is being pushed along the table surface and the friction is high. The friction with the table surface causes angular momentum. As the ball slows it starts rolling, which causes less friction with the table surface.

#4

Well, if am brutally honest, have absolutely no spark/interest whatsover for the physics, but am gonna bother, if that upsets anyone, so be it. Yesterday I found a 100+ page .pdf tutorial describing all the game physics on programming a pool game. Nuf said!

Anyway, new version is up (changes described on webpage)… I have multiplied the vx/vy by 0.99 (0.90 slows balls down too quickly) and when they reach below a certain velocity, I set the velocies to 0. Not perfect but a very good approximation (a few tweaks may improve too). Will have a look at some of the kinetic friction pages later to see if that can help provide a little more realism (especially when ball falls under a certain velocity).

The looking ahead code (if can get it working) would be cool so I can provide some little helper arrows (so player can see which direction next ball will go!). The pocket jaws may be bitch to code too, but if can get these 3 things working the rest should be quite straightforward… :persecutioncomplex:

#5

Does the tutorial describe resolving multiple simultaneous collisions involving the same ball? That’s where things really get ugly.