Basic movement game AI

I really love to play video games, and for a while I’ve been wanting to learn a bit about video game programming mainly AI and physics.
I have just read the first 20 or so pages of the good book on AI Artificial Intelligence for Games

and I though I was going to try the first easy algorithms that are explained there. So here I will introduce a little bit of the simplest way to develop the seek and arrive algorithm.
I will develop the example in Ruby using the gosu library to draw some simple characters.

The idea of the seek algorithm we are going to implement is very easy, we will control a character in the screen and another computer controlled character will seek our character on the screen and destroy him when he arrives to our character.

So the first thing to know is what is involved in a very simple movement. In the example we will not consider acceleration forces so we will have what is known as Kinematic movement. We will need 3 variables to express the characters static data at moment in time. So we can start with a Ruby module like this:

1. module Kinematic
2.  attr_reader :velocity, :orientation, :position
3. end
4.  

where all three elements are vectors. The velocity vector will give us the direction and speed of the characters, the orientation vector, in our case will simply be oriented towards the direction, so it will be the velocity vector normalized, and the position is the place where our characters are.

The orientation will also be expressed as a angle in radians using the atan2(-x,y) formula, where y and x are the corresponding coordinates in the velocity vector.

So the position and orientation will be both a function of the velocity like this:

1. orientation = velocity.normalize
2. position = velocity * time

where time is a small unit of time that will be a function of the frame rate we have. When the frame rate is bigger, the update time is smaller. It is calculated in our case something like this:

Let’s suppose our character travels at 2 meters per second, and let the frame rate be 60fps in a particular moment. then our time multiplier will be 1/60 which multiplied by 2 will be 1/30 that will be the length of our vector to be summed to the position vector in each frame. However we will change the value and adjusted to some value that makes the movement look good.

Ok so that is the basic movement, but now we need to implement the seek behaviour. The AI character will need to chase our own character in the screen, in the algorithm terminology we’ll be the target of the seek and arrive algorithm. So logically for implementing this algorithm we need both the character and the target kinematic data. We also need to specify a radius of contact (where the character catches the target) and a speed for our velocity vector.

So to our module we add this max_speed

1. module Kinematic
2.  attr_reader :velocity, :orientation, :position, :max_speed
3. end

We create now two classes that include this module

1. class Target
2.  include Kinematic
3. end
4.  
5. class Character
6.  include Kinematic
7. end

Both character and target include the module, but only the character will be AI controlled, the target will be controlled by ourselves.

So we will create the seek_and_arrive algorithm on the character, in a method that receives the character it is chasing.

First the seek part will be simply to create a velocity of speed ‘max_speed’ and direction pointing to the target’s position. Now for the arrive part we will use a ’radius of impact’ that determines when the character has actually reached the target. We will include this radius as information on the target character. So modifying the algorithm we now have:

1. def seek_and_arrive(target)
2.   @position += @velocity * @time_update
3.   @velocity =  target.position - position
4.   if  @velocity.magnitude < target.radius
5.  EventHandler::add_event(:capture,self,target)
6. end
7. @velocity = @velocity.normalize
8. @velocity *= @max_speed
9. @orientation = @velocity.normalize
10. end

As we see we are simply adding a condition and then sending an event saying that the target has been captured by the character. This event will be handled in the main loop of the game where it will show Game Over.

We will now create the graphics for the game with Gosu, I won’t explain much here as it is not the focus of the post.

The first thing, we create a character wrapper for our characters that will know about gosu, that way our original class remains graphics framework independent:

1. class DrawableCharacter
2.  attr_reader :character
3.  def initialize(character,window,character_img)
4.     @image = Gosu::Image.new(window, character_img, false)
5.     @character = character
6.  end
7.  
8.  def draw
9.     @image.draw_rot(@character.position[0], @character.position[1], 1, @character.orientation_in_radians)
10.  end
11. end

then we create a class for the controlled character and one for the AI Character:

1. class ControllableCharacter < DrawableCharacter
2.  def move(side)
3.     @character.move_ahead if side==:front
4.     change_velocity_according_to_side(side)
5.  end
6.  
7.  def change_velocity_according_to_side(side)
8.     return if side == :front
9.     if side == :right
10.      sin_radians = Math::sin 0.1
11.      cos_radians = Math::cos 0.1
12.     else
13.     sin_radians = Math::sin -0.1
14.     cos_radians = Math::cos -0.1
15.     end
16.     velocity_x = @character.velocity[0]*cos_radians - @character.velocity[1]*sin_radians
17.     velocity_y = @character.velocity[0]*sin_radians + @character.velocity[1]*cos_radians
18.     @character.velocity = Vector[velocity_x,velocity_y]
19.     @character.velocity = @character.velocity.normalize * (@character.max_speed+1)
20.  end
21. end
22.  
23. class AICharacter < DrawableCharacter
24.  def seek_and_arrive(target)
25.     @character.seek_and_arrive(target)
26.  end
27. end

The Controllable character will move depending on input from the keyboard that is captured on the main Game class. The AICharacter delagates its movement to the Character class that contains the seek_and_arrive algorithm.

Now the main Game class:

1. class Game < Gosu::Window
2.  
3.  def initialize
4.     super 1024, 768, false
5.     self.caption = "Seek and Arrive"
6.     @target = ControllableCharacter.new(Target.new(10, 10), self, 'target.gif')
7.     @character1 = AICharacter.new(Character.new(500, 500), self, 'character.gif')
8.     @game_state = :game_started
9.  end
10.  
11.  def manage_ai_characters
12.     @character1.seek_and_arrive(@target.character)
13.  end
14.  
15.  def manage_controllable_character
16.     if button_down? Gosu::KbLeft or button_down? Gosu::GpLeft then
17.      @target.move :left
18.     end
19.     if button_down? Gosu::KbRight or button_down? Gosu::GpRight then
20.      @target.move :right
21.     end
22.     if button_down? Gosu::KbUp or button_down? Gosu::GpButton0 then
23.      @target.move :front
24.     end
25.  end
26.  
27.  def manage_events
28.     EventHandler::each do |event|
29.      if event[0]==:capture
30.        @game_state = :game_over
31.      end
32.     end
33.  end
34.  
35.  def update
36.     manage_events
37.     if @game_state != :game_over
38.      manage_ai_characters()
39.      manage_controllable_character()
40.     end
41.  end
42.  
43.  def draw
44.     if @game_state != :game_over
45.      @target.draw
46.      @character1.draw
47.     else
48.      Gosu::Image.new(self, "game_over.gif", true).draw(0, 0, 0);
49.     end
50.  end
51. end
52.  
53. window = Game.new
54. window.show

The main details to get out from this code are the ‘update’ and ‘draw’ methods. The update method is called 60 times per second by default, and then the show method is called.

The full source code of the example is in github, just download and run the game.rb ruby file.

Of course this introduction is the simplest of the simplest in Game AI, but it is important information to have and very entertaining to learn.

Also of course there are libraries and frameworks that do most of the work for us, but I did this example (and hopefully some following ones) to learn the basics of how it works.

Alternatives to Multi Threading for concurrency in Java. STM and Actors

In the Java world we are used to work with concurrency dealing directly with Threads, Synchronization and Shared Data.

Java introduced a great deal of improvement in version 5 with the new concurrency facilities it provided, and had built on it in subsequent versions of the language.

These facilities are great and powerful, but they still can sometimes be hard to use correctly. I will cover concurrency in the traditional (and concurrency utilities) way in another post. This post is just about introducing a couple of alternatives to these.

In this post I’ll introduce the Software Transactional Memory (STM) model for concurrency. In a later post I’ll introduce the Actors model in Java.

STM: Very much like the transactions we are use to in DBs but working with objects in memory, keeping the ACI properties of transactions.

In this model we separate identity from state. This basically means that we have some entities that hold an inmutable state that can change over time. We’ll understand this better with the example that will follow.

The main advantage of this separation is that there is no need to block or synchronize as the state doesn’t change.

I’ll write a piece of code now and explain how it works. For the example I will use Akka and its support for STM with Multiverse.

Let’s assume we want to create a very simplistic kind of Stack (No validations, no anything) that only supports push, peek and pop and it should be thread safe. The simplistic code would be something like the following (No thread safe).

1.  
2. public class StmStack {
3.  
4.    private static int SIMPLISTIC_BIG_SIZE = 1024;
5.    private Object[] elements = new Object[SIMPLISTIC_BIG_SIZE];
6.    private int top=0;
7.  
8.    public Object pop() {
9.       Object value =  elements[top];
10.       top --;
11.       return value;
12.    }
13.  
14.    public Object peek() {
15.        return  elements[top];
16.    }
17.  
18.  
19.    public void push(Object value) {
20.        elements[top+1] = value;
21.        top++;
22.    }
23. }

It is very simple to see that there exist a thread safety problem with the state variable ‘top’. The problem is simply that this variable is shared mutable state. A variable that can be accessed, read and changed concurrently by mutliple threads. And of course the elements array itself has the same problem.

The common solution to this problem, would be to synchronize the access to the three methods. This approach is not hard to follow here in this very simple example, but even here it has a couple of drawbacks. One of them is that synchronizing and lock acquiring affects performance. Other can be that for example the peek method is not changing state, and in an application that will use peek more than any other method (more reading and moderate writing) no more than one thread will be able to peek. Also we need to remember to synchronize every method that we put in this class that will either read or write. When things start to get a little complicated (more locks, more granularity, more mutable shared state) understanding synchronization and locking logic is not very easy, and debugging synchronization and concurrency problems is hard to say the least.

We’ll see now the code using STM. This will look a bit complex

1. public class StmStack {
2.  
3.     private Ref<Elements> elements = new Ref<Elements>(new Elements());
4.     private Ref<Integer> top = new Ref<Integer>(-1);
5.  
6.     public Object pop() {
7.        final TransactionFactory factory =
8.                new TransactionFactoryBuilder().setBlockingAllowed(true).setTimeout(new DurationInt(6).seconds()).build();
9.  
10.        return new Atomic(factory) {
11.  
12.            @Override
13.            public Object atomically() {
14.                System.out.println("poping ");
15.                if (top.get() < 0) {
16.                    StmUtils.retry();
17.                }
18.                Object value = elements.get().get(top.get());
19.                top.swap(top.get() - 1);
20.                return value;
21.            }
22.        }.execute();
23.     }
24.  
25.     public Object peek() {
26.        final TransactionFactory factory =
27.                new TransactionFactoryBuilder().setBlockingAllowed(true).setTimeout(new DurationInt(6).seconds()).build();
28.  
29.        return new Atomic(factory) {
30.  
31.            @Override
32.            public Object atomically() {
33.                System.out.println("peeking ");
34.                if (top.get() < 0) {
35.                    StmUtils.retry();
36.                }
37.                return elements.get().get(top.get());
38.            }
39.        }.execute();
40.     }
41.  
42.     public void push(final Object value) {
43.        new Atomic() {
44.  
45.            @Override
46.            public Object atomically() {
47.                System.out.println("pushing " + value);
48.                elements.swap(new Elements(elements.get(), value, top.get()));
49.                top.swap(top.get() + 1);
50.                return "";
51.            }
52.        }.execute();
53.     }
54.  
55.     public int elements() {
56.        return top.get()+1;
57.     }
58. }
59.  
60. class Elements {
61.  
62.     private static int SIMPLISTIC_BIG_SIZE = 1024;
63.     private final Object[] elements;
64.  
65.     Elements(Elements elements, Object newElement, int top) {
66.        this.elements = elements.elements;
67.        this.elements[top + 1] = newElement;
68.     }
69.  
70.     Elements() {
71.        elements = new Object[SIMPLISTIC_BIG_SIZE];
72.     }
73.  
74.     Object get(Integer index) {
75.        return elements[index];
76.     }
77.  

The first thing to notice is that we changed the elements array of objects to a Ref object to an object of the new class Elements. We can also see that the Elements objects created are immutable. Noone has direct access to mutate its state. It never changes after created. This is one of the ideas that need to be encouraged. The use of immutable objects.

As we talked before the use of Ref helps to separate the ID of the reference to its state so in this case we have a Ref that will point to a different Elements object in different moments of time, but will not modify the one it has currently directly, it will just replace it. We do the same with the ‘top’ variable, making it a Ref instead of an Integer.

The next thing is the implementation of the different methods. As we can see we are wrapping each method content in an Atomic object, and putting the content inside the atomically method. This will ensure that the operation runs inside in a transaction.

The transaction ensures that all the values in the Ref variables are consistently changed or rolled back in case some other transactions modify them in the meantime, retrying automatically if that is the case. We can also observe the ‘retry’ method call. This method help us retry the transaction in the case a pre-condition is not met to run the transaction in the first place.


I’ll show a couple of running examples now(Just the relevant code):

first we run 7 push operations in different threads:

final StmStack stack = new StmStack();
push(stack);
push(stack);
push(stack);
push(stack);
push(stack);
push(stack);
push(stack);
sleep();
System.out.println(stack.elements());

The output:

pushing asdad
pushing asdad
pushing asdad
pushing asdad
pushing asdad
pushing asdad
pushing asdad
pushing asdad
pushing asdad
pushing asdad
pushing asdad
pushing asdad
pushing asdad
pushing asdad
pushing asdad
pushing asdad
pushing asdad
pushing asdad
pushing asdad
pushing asdad
pushing asdad
pushing asdad
pushing asdad
Number of elements: 7

Event though we called the push on the stack only 7 times, we can see that the push method (actually just the transaction part) was executed more than 20 times. This is because of all the retrying when multiple threads collide in the transaction execution. We can see that maybe for heavily writing applications STM transactions might not be the best solution because of all the retrying.


Now we run just 1 push, and then 6 peeks.


push(stack);
sleep(2000);
peek(stack);
peek(stack);
peek(stack);
peek(stack);
peek(stack);
peek(stack);
sleep(8000);
System.out.println(stack.elements());

And the output

pushing asdad
pushing asdad
peeking
peeking
peeking
peeking
peeking
peeking
Number of elements: 1

We can see that no retry is needed for the peeking. We can see that STM is better suited for multiple reads, low-to-moderate writes.

So with STM we have a model that avoids the use of explicit locking, offers great concurrency performance, helps encourage the use of immutable types and just mutable References, makes explicit the parts that we expect to be executed atomically.
It also dynamically and automatically handles threads and contention, and can help mitigate or entirely remove deadlocks as we don’t deal with locking or lock orders anymore.

STM is an alternative worth considering if we have requirements for concurrency that adjust to this model.

A lot more information in:


AKKA Documentation

And