The Nature of Code - Agents

The Nature Of Code in BASIC256 - Content

Chapters

1. Randomness

2. Balls (Vectors)

3. Forces

4. Oscillation

5. Particle Systems

6. Agents

Agents

What are agents in this context

Up till now, the objects that we drew were just inanimate things that underwent the forces acted upon them: wind, gravity, random movement etc. What if those inaimate things could actually decide themselves what to do, based on their own rules?

An autonomous agent should be able to make its own choices on how to move in its environment (our canvas). The choices it will make are just another set of forces but calculated from within.

To be able to do this, an autonomous agents needs three key components:

1. The ability to perceive (however limited) its environment

2. The ability to process this environmental info and to make decisions based on it

3. The lack of a leader. Whatever happens in the environment will be an emergent behaviour based on the sum of individual actions

These autonomous agents will also model their motions with vectors and forces, so we will be able to use things like Walkers, Movers and Particles

Verhicles and steering

Craig Reynolds, developer of the famous "Boids" flocking algorithm, expanded his early ideas into a 1999 paper "Steering Behaviour for Autonmous Verhicles". Here we will also call our agents 'Verhicles'

As usual, the Verhicles will have a position, a velocity and an acceleration vector. Next to this, they will need the following:

1. One or more goals (seek a target, flee, arrive, avoid obstacles etc)

2. Steering. once a goal has been selected, the next move will have to be calculated. This is a steering force (desired velocity minus current velocity)

3. Locomotion. Not important in our setup as our agents will just 'move'. No wheels, legs, paddles

Most important of these is the goal and we will need to steer towards it. In Chaper 2 (Acceleration to mouse), the steering movement was more one of falling toward the mouse. Here, the verhicle needs to make the decision to steer to the target while having a maximum speed

The verhicles behaviour here is a bit like a puppy chasing a ball as it will overshoot the target seeing it goes at full speed until it reaches the target and has to reverse course.

Verhicle steers toward a goal

And this is what it looks like:

We can also incorporate an arriving function so that the verhicle slows down as it reaches the target.

Steering and Arriving

And this is what it looks like:

Our target has in both cases has been the mouse pointer. As long as the mouse pointer is not on the canvas, the verhicles just goes in its current velocity forever. We can make this more 'life-like' by giving the verhicle what Craig calls a 'Wandering' status

We could do this with a more or less random movement like we did with the walkers in Chapter 'Randomness', but here we will use Craig's algoritm to give the verhicle some liveliness

Just wandering about

And this is what it looks like:

A last behaviour we will show will be the Avoidance behaviour when the verhicle approaches the wall during its wandering. You will see that the verhicle still breaches the wall of the canvas, but to be fair, so does the p5.js example in the book.

You can also visualize the trail by setting the switch sw_showtrails to 1

Wandering but staying on canvas

And this is what it looks like:

Flow Fields

Another of Reynolds' steering behaviours is having the verhicle 'adopt' the velocity vector of the position it finds itself in. He did this via Flow Fields.

Flow fields overlay the canvas with a grid of squares, with each square containing a velocity vector. Now, there are many ways one could create those velocity vectors, going from very simple where all vectors are the same to fully random. Of course these extremes do not result in a very natural looking behaviour. One could also make the velocity vectors swirl around the centre but one of the best methods is using Perlin noise to give rise to a more natural movement.

Of course, the gridsize itself is very important. Again, theoretically you could make the gridsize size 1 (each pixel has its own value/angle/velocity vector) but that would not be efficient. It would work with limited number of 'verhicles' (some hundreds), but would bog down when you have thousands.

The following example show the verhicles following a Perlin Noise flow field with a gridsize of 10. Press right mouse button to increase the gridsize, left mouse button to visualize the flow field and middle mouse button to flood the flow field with particles so you can see the watershed-like nature of the flow field

Steering by Pelin2D Flow Fields

And this is what it looks like:

Next up:

Chapter 5: Physics Libraries