YakYak

I'm making a little Pong clone to test out some code on my DS. I can't quite work out a decent looking behaviour for the computer bat. Right now I just make the computer's bat track the ball's y position, so it never misses, and you can't ever win.

Since this is Pong, and it's probably the simplest game going, what's a nice simple routine for making the computer bat 'good enough' but sometimes miss? I had a go and ended up lost in a mess of 'if' statements trying to test for all sorts of things, which seemed too complex and messy.

program in a deliberate miss every few turns (track -20 pixels or whatever)
miss interval could be a random number
miss interval gets shorter to ramp the difficulty up

Here's how I'd do it:

Have the AI only "think" every n frames, so it doesn't have perfect reactions.

Each AI "think" tick, predict where the ball will be when it gets to the AI bat - include a randomised fudge factor so it's not perfectly accurate. For bonus points, make the prediction more accurate the closer the ball is to the AI bat.

The rest of the time, just move the bat towards the predicted target location. Maybe make this randomly overshoot the intended location for extra realism.

Tweak the reaction time and accuracy to adjust the difficulty level.

Do a different game, Pong is shit.

Beerman's ideas seem pretty sound, as do the others.

other ideas:

Limit it's speed, so if the ball is moving too quickly or if it thinks too late it cannot get to it (but it still tries). The speed can be tweaked as part of the difficulty.

Make it worse at guessing bounces off walls, i.e. make it so it mis-estimates where it has to be pre-bounce, then adjusts after the bounce, again potentially missing.

These are based on limitations of the player, and would give the player strategies, i.e. make the ball move sideways as much as possible and bounce it off the walls. The downside of such strategies is the ball might come back the same way, making the game more interesting.

If Racing the Beam is correct, then just have a pop at the VCS algo, it's bog simple:

When the ball is served, the top of the AI bat is aligned with the ball. The AI bat tracks the ball's Y movement once it's served, but skips every 8th update. It'll reset itself and recover from the drift when the ball hits the top or bottom of the screen, as long as the ball is aligned with part of the bat. Otherwise it'll carry on drifting and eventually miss.

You could do something more fancy with angle prediction but it's probably more faff than you need to do. Just fiddle about with skipping frames and catch-ups and you'll probably have something that works for sod all code.

I remember playing a pong that evidently used the algorithm:

bat.y = ball.y

It wasn't all that much fun, oddly enough.

I'll have a look at that, ta Racing the Beam was a good book, hope they write more.



That's what mine currently does. It's great for debugging, but gets boring after about half a second However, when both bats do it, it makes a nice attract screen.

I had a go with this and it produces something good enough. Right now it's not possible to influence the ball by hitting it with different parts of the bat, so the game is quite hard to beat - but it can be beaten if you get lucky.

Now to add some 'spin' to the ball depending on where it lands on the bat.

What you need is some fuzzy logic.

First, Beerman's right. Computers react too quickly. Therefore, only run the AI every x frames - slow down its reactions.

Second, computers are far too precise - and this is where the fuzziness comes in. Deliberately retard its precision, so it only has a rough idea of what it's doing in a round about way.

This is easier to achieve than it sounds. As an example, I used this kind of code in my "Ping Pong" example (see attachment):


Where "BallY" is where the ball actually is, and "RoughY" is the fuzzy version that the AI sees - it divides the vertical into 20 pixel high "zones" and then aims the AI at the centre of whatever "zone" the ball is in. So the AI doesn't know precisely where the ball is, only where it roughly is. Give or take 20 pixels or so.

You can, of course, change the degree of fuzziness by making the "zones" bigger or smaller. What I did in my example game is that it has a 160 pixel "zone" when the ball is in the third closest to the player - so it only knows which third of the screen (e.g. "top", "middle" or "bottom") to roughly aim for. As it gets half-way across, the precision improves to 100 pixel "zones", then 80 pixels then 25 pixels, as it reaches the CPU's bat.

Third, don't control the AI's Y coordinate directly. Control its speed (or its second derivative, in maths speak).

This also gives the game something to do in those frames when the AI ain't running. It simply continually does this every frame:


Where "EnemyY" is the AI's bat Y coordinate and "EnemyDY" is the "delta" (or speed / direction) added to it every frame.

The AI does not touch its Y coordinate directly, but rather looks at its "fuzzy" view of the world (only every x frames too) and tries to work out by how much it needs to speed up / slow down the bat to get to the ball in time.

To purposefully allow for overshooting and undershooting, the speed is fuzzified too.

This time around, though, I actually work it out precisely, then make it fuzzy afterwards just before applying it to the bat - the sole reason for that is that though I want the AI to sometimes be a klutz, I don't want it to be too stupid and thus present no challenge for the player. So the fuzziness of the speed delta is only applied when it wants to move over a certain speed.

That is, when it's moving slowly, it has better speed control than when it's rushing like a madman to reach the ball on the other side of the screen - which also neatly emulates what human beings tend to do as well, as we tend to lose all our precision with the mouse when we're flinging the pointer around at a rate of knots. And, thus, the AI tends to be more likely to fuck up on exactly the kind of shots that the player will typically fuck up on - the mad dash across half the screen to get there in time.

Another real simple addition, which makes it fairer on the player (and, again, actually makes it look a bit more human) is that it only actively chases down the ball when it's coming towards the AI's bat. When the ball is heading towards the player, the AI "relaxes" and then either moves up or down a bit or roughly re-centres itself near the middle of the screen (this is chosen randomly).

The most interesting thing about this "fuzzy" approach is that the AI isn't just letting you win randomly. That's just, well, too random.

Indeed, except for the random choice of whether to re-centre itself or move up or down a bit when the ball is heading away from it, there is no randomness in the AI routine at all. It's genuinely trying to do its best at all times.

But it "fails in the gaps", so to speak.

That is, it only reacts every x frames - if the action is too fast, then it can fail in that reaction time gap. It doesn't know where things precisely are, only where they roughly are - that loss of precision creates a "gap" in which it can fail. It only has "fuzzy" control of its speed and sends it roughly at the right speed in the right direction - but not precisely so, that it can fail in the gap of its imperfect control of the bat.

And, of course, all of these impediments are exactly the impediments that humans have while playing the game too - which makes it fairer and makes the AI seem a touch more "human". Our reaction times can be a bit slow. We don't have any clue how many pixels exactly we are away from something. Even the best eye-to-hand coordination with the mouse suffers from its imprecisions.

You see, Mr.Spock was wrong. Humans are not illogical at all. We're just "fuzzy logical".

Use the mouse to move your bat. Left mouse button starts a game. Esc to quit a game in progress and also quits out of the program when on the title screen.

First to reach ten wins. Enjoy!


Edit - maybe the CPU player is a bit too stupid sometimes. Oh, well, demonstrates its capacity to fail. Just example code, and not exactly fine-tuned and well-polished (the text is not lined up symmetrically on the screen and it is possible, though rare, for the ball to get "stuck" in the bats or the side walls - I realise these things but can't be bothered to fix them).

Otherwise known as Artificial Stupidity.

I did the (dodgy) AI for an air hockey mini game a few months ago.

The basic rules are obvious: when the puck is to the left of the paddle, make the paddle go left. When it's to the right, make it go right.

Then you add some inertia so the paddle takes some time to change direction. This is 100% of the gameplay. Implement it so that when you want it to go left then it applies an acceleration to the left, etc. There's a maximum speed the paddle can travel. The acceleration and maximum speed directly affect the difficulty of the AI, from easy to virtually impossible.

For the y-coordinates, I made it so the paddle moved towards the middle of the AI playing area when the puck was on the opponent's side. When the puck passed onto the AI's side, the paddle moved back towards the goal area. Again the speed of this this movement affects the difficulty. If the puck was directly in front of the paddle I applied a large forward acceleration to shoot.

And that was it. Bearing in mind that the puck and paddle were circular, all sorts of fun can be had. Fuzzy logic can fuck off. It was really popular around the office until someone higher up kept losing and knobbled the human controls.

How about offsetting the accuracy of the bat's location by a random amount, but with values that map to a normal distribution(bell curve)? It will hit bang on or close to the mark most of the time, only just catch it some, and every now and then will miss. On the rare occasion it will miss by a margin. Then you can scale the difficulty by just changing the standard deviation of the distribution, perhaps during play if the ball increases in speed.
It would be easy to calculate exactly where the bat will need to be while the ball is still traveling. Humans 'guess' where the ball will be and move into position, offsetting that calculation will make the bat seem to guess as well. Building on that, changing the predicted angle of a wall rebound randomly might make the bat seem more human as well.

I was going to have different game modes, in the style of the Atari 2600 carts. I think I might also have different computer opponents to play against too, each using a different AI routine.

Have you considered using neural nets and training them?
http://www.karlsims.com/evolved-virtual-creatures.html