Virtual Pool in a Box
 










Results of Pool in a Box

Results

Speed of execution

The main function playgame is called once every 100 ms.  The function readADCs, a function that read 3 different ADCs sequentially from the potentiometers and the accelerometer is called once every 33 ms, since 33 * 3 = 99 ms.  We want the ADCs to be read at nearly the same rate as playgame is called, to ensure optimum accuracy, especially where determination of acceleration is concerned.

 

Flickering of the table and balls occur, since we are redrawing them during playgame to prevent them from getting erased by a traveling ball or moving cuestick.  To reduce flickering, certain delays are added in such as delayT and delayTB, which are actually counters that increment up to a certain value before drawing and undrawing.  It was also found that tweaking the voltage values on the -24 V supply to the LCD can reduce the flicker of the balls to a great extent.

 

In addition, playing 15 object balls introduce more artifacts to the screen compared to the playing of a minimum of 2 object balls.  A logical reasoning would be that having for loops for 15 balls take longer than that for 2 balls.  Similarly, playing 15 object balls at certain random times result in slight hesitation in the movement of the balls on impact with other balls.  Ironically, to think about it from a skewed perspective, this may be good for the player, since he can watch “in slow motion” the reaction of the balls on impact. 

 

Overall, it can be said that playing 15 balls introduce certain glitches.  However, playing up to 5 balls in the Training mode is smooth to the effect of near perfection.

 

Our “Pool in a Box” exhibits high interactiveness with the player, since the player controls a real cuestick, and is able to watch the cuestick move in real time on the LCD.  In addition, user-friendly instructions on screen make it clear to the player as to what buttons to press to navigate or to move the cueball around.

Accuracy

We started out the project with great ambition, wanting our pool game to be nearly identical to a real life pool game that is played at the same time.  A check of online resources and the numerous complicated equations involved in real life revealed this to be near impossible.  In the end, we took a step back and changed our focus.  To make the game playable and glitchless to the human eye was what we aimed for.

 

That being said, the motion of the pool balls can be considered highly accurate.  Collision with the side of the pool tables proved to be perfect, regardless of the number of balls being played.  Where collision between balls was concerned, the balls exhibited movement in the right directions almost 95% of the time, when fewer balls were being played.  15 balls being played resulted in lower yields, perhaps 75%.

 

However, we do realize that when many balls are clustered closely together, one touching the other, as in the case at the start of the game, collision detection between balls is not able to function that well.  In most cases, the balls remain stuck together, since we find it complicated to include in our algorithm the transfer of kinetic energy to the nth ball in line, like real life should.  To overcome this problem, we introduce the ballbreak state, such that on breaking the ball at the time the pool game starts, the 15 object balls adopt positions slightly apart from each other.  In that way, ball breaking is able to look like the way it looks in real life.  Pool champions might call this cheating, but we prefer to call it “thinking out of the (pool) box”.

 

One major difficulty we faced is regarding the accelerometer.  We tried all methods possible, to make the acceleration of the cueball reflect the strength with which we handled the cuestick.  We experimented with 3 different accelerometer altogether, the 2g, 10g and 40g.  We also tried varying the sampling speed of the ADC, as well as taking averages.  In the end, the simple conclusion we draw is just that the player has to hit the cuestick softly.  This is good in a way, because it emphasizes “soft touch”, encouraging the player to go for accuracy more than brute strength.

Safety

Since the LCD uses -24 V, we covered all wires with black tapes, to prevent any shorting.

 

In the labs, we experimented using only the potentiometers, without the actual cuestick.  The cuestick was only attached to the potentiometer on the day of demonstration.  Hence, no one gets poked in the eye, and everyone remains happy.

Interference

Since we did not use RF, there was no interference.

Usability

From ages 3 and up.  Everyone can play this game.  In fact, kids not able to reach up to the normal pool table will finally get a chance to play simulated pool.