Skip to main content
GameDev.net gamedev.net
🔒 Locked

What is AI here?

Started by TitForTat Jul 23, 2004 at 9:15 PM 1 replies 1.5k views
Original Post
TitForTat
TitForTat
i want to introduce AI-Player to my pool game. Introducing AI-Player means what? Getting it done through programatic logic of my own. or Are there AI specific techniques. How can I achieve that thing in either case. As my application can tell: -wheather the path to the targeted ball from cueball is clear -where to hit the targeted ball to get it pockected to any pocket -wheather the targeted ball can be pocketed to some pocket. at the moment Im trying to achieve it through a couple of if/else and loops statements. But it is not reliable as i often get some new bugs to my application. Please guide me to some right direction.
IADaveMark
IADaveMark
We discussed this in this thread a while back but I will repost what I said back then:

******************

There are two different issues to address here. First, shot selection. Second, how do you make the computer NOT be mathematically perfect?

On the first issue, some of it depends on the game. As mentioned before, in straight pool or 9-ball, your shot selection is a little more rigidly defined. However, you can always define a set of object balls that are available. Once you have that set, you can itterate through them to determine the "feasibility" of the shot. As mentioned before, this is a combination of factors including the angle of the shot and the distance from cue to object ball and object ball to pocket. There are mathematical reasons, that sharper angles are more difficult and that longer shots are hard. Each of those are a function of circular degrees, though, and can be considered with some simple formulae.

With distance, it is simply a matter of the margin of error - expressed in DEGREES - that is available on a given run of distance. Since the pocket opening is a fixed width (which will vary depending on the angle to the pocket - but that is another calculation), you can measure the angle width of the pocket using the location of the ball as the apex of the angle. When using extremes, the issue is easy to visualize. If the ball is sitting on the lip of the pocket, the available angle is almost 180 degrees. When you are diametrically opposed to the pocket, however, the angle is only a few degrees. There is less margin for error on the path of the object ball if it is to enter the pocket.

The same function can be performed between the cue ball and the object ball, but the calculation is a little more tricky. First, one would have to determine the arc on the surface of the object ball on which it can be struck that would place it's path between the endpoints of the available angles to the pocket. For the most part, this is simply a matter of inverting the angles to the opposite side of the ball.

The difficulty on cut shots comes from how much of that target arc on the object ball is exposed to the position of the cue ball. For a relatively straight shot, most of that arc is facing the cue ball and therefore your margin for error is at it's widest point. On a cut shot, however, what may be 10 degrees on the surface of the ball may only look like 1 or 2 degrees when viewed from an almost tangental aspect- therefore the margin for error on your cue shot goes up substantially.. Also, remember that the distance from the cue to the object cuts down that angle as expressed in degrees as well.

Since the distance and position of the object ball from the pocket determine the width of the target area on the object ball, and the "perceived" width of the target area on the ball as seen from the cue's location, the "difficulty" of a shot is simply expressed as the angle width of the possible paths from the cue to an object ball that would yield a successful shot.

(incidentally, the strength of a shot can be dealt with in much the same way)

Therefore, shot selection could be determined by itterating through the available object balls on the table. For each ball, you would need to cast an LOS check to see if they can reach each of the 6 pockets unobstructed. For each ball-pocket combo, you would determine the available target area on the surface of the ball that would put it into each pocket. For each target area, you would then need to calculate how much of it is visible to the cue ball and what the width of that angle is from the point of view of the cue ball (giving you your difficulty level). If you are not worried about other strategy (e.g. setting up for the next shot), then simply select the widest cue angle as your easiest shot.

Of course, given the mathematical perfection of selecting the angles, the trick is now to "fuzzy up" the computer's math so it is more "human". This can be done in two ways. The first is to fuzzy each calculation above. The second is to get the mathmatically perfect answer and then apply a +/- to the actual angle of the shot attempt. Each way has it's own advantages and effects - and could actually be used in combination.

With the first method, you are actually affecting the decision making process of the computer - and could cause it to make (realistically) poor decisions. An example would be a tight shot around other balls on the table. If the LOS check and the desired angles are fuzzied up, the computer can be made to SEEM to think it can get the object ball past an obstacle when it really can't. This is a legitimate failing of people playing the game.

In the second method, you are affecting the execution of the shot rather than the decision making process - and would cause the computer to make (realistically) poor shots. Using the example above of a crowded shot... the computer may know darn well that it can thread the needle and put the object ball between the others and into the pocket - but just mis-cue the ball and put it slightly off line and either strike the obstacles or miss the pocket entirely. This, of course, is also reasonable to assume that a person playing the game would do.

I would reccommend applying both to some degree. In fact, the parameters that you use to fuzzy these calculations would be prime material for the difficulty level tweaks. Likely the most realistic method for affecting these decisions and shot is to use a sine calculation. Errors in perception and excecution usually take on a bell curve form with more samples being reasonably close to the "optimum" and less samples being "completely wild-ass" ones. Applying a sine factor into the calculation does this nicely.

If you were to grab a random number from 0-359 and throw a sin() at it, you would get a number from 1 to -1 with most of the samples falling closer to 0 and only a few being out at the edges of 1 and -1. If you multiply this result by whatever coefficient you need to scale it properly for the task at hand, you would end up with a value that is occasionally correct, mostly in the neighborhoood, occasionally poor, and rarely piss-poor - on EITHER SIDE of the target value (+ or -).

When you apply this to the perceptions and decisions made by the computer, your angle calculations will widen, narrow or shift one way or the other from what is the ACTUAL value. When you apply it to your execution (the cue stroke), your computer player will strike slightly left or right of the proper angle needed for the desired path. You can see how applying the fuzzification to both the decisions and the execution looks a lot like a real pool player, in this case.

There are, of course, more advanced considerations. There would be another layer of calculations entirely if you were to include bank shots or combination shots. Also, most decent pool players are looking ahead one or more shots so they can "play position" by leaving the cue ball where they want it for subsequent plays. This is done much of the time through "English" (spin) on the ball and would require a much more advanced physics model if you were to implement it. However, this should get you started.

Remember, as always, I'm just pulling this out of my AIss, so I can't vouch for it's validity or accuracy.
Dave Mark - President and Lead Designer of Intrinsic Algorithm LLC
Professional consultant on game AI, mathematical modeling, simulation modeling
Co-founder and 10 year advisor of the GDC AI Summit<
jacksaccountongamedev
jacksaccountongamedev
Hello.
I’ll be completely honest here and point out that I did not read the above post (1/4 to 12 at night). However, I do recall several years back in my younger days I created a 2D example-program that displayed AI for a game of pool. This AI was incomplete and did not go as far as lining up and taking the shot, but it did successfully choose a ball and subsequent hole to aim for.
Upon I brief search of my hard disk I have recovered and uploaded this program, of which is now available here. Taking into account a number of factors, the Artificial Intelligence is very accurate in locating the best shot on a somewhat simple basis.
Now is not an appropriate time for me to discuss this, but if you please I can go through the algorithm used to achieve the effect in this demonstration.

Anyhow, hope this helps - it is pretty basic though, and probably not of much use.
Jackson Allan
Luckless
Luckless
for a pool game, one thing to give the AI a more human feel is for it to do its path testing with a slightly Smaller 'test' ball before deciding shots, *May also want to have it decress in size the farther it goes from where the real ball its pathing is.*

This means that the computer will do the math, find a good shot, but miss, as it hits another ball along the path. A very human mistake, I do it now and then too.
Old Username: Talroth
If your signature on a web forum takes up more space than your average post, then you are doing things wrong.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.