 |
 About A.I.
In the previous chapter, you have seen a simple example of how objects can be moved around.
The movement code can become quite complex, sometimes involving more than one dynamic brush.
Like a spider and it's wire, moved together to give the impression of a singe entity.
As these entities become more and more complex, they give impression of intelligence and can be called A.I. (artificial intelligence).
Of course this is not trully intelligent behaviour, it's just well programmed.
However, for a game's level of complexity, when an upset bird is moving
to intercept the player, it is considered pretty intelligent.
Think now about the example of the bat or the mouse from the previous chapter.
If you have 10 such objects, moving the same way, but in different locations, you must add 10 dynamic brushes and
callbacks for each room location where they move. But you can use a single UpdateBat or UpdateMouse function, sending
the index or the id of the dynamic brush you want to update, as a function parameter.
This can be called an A.I. class and it is usually represented through an update function.
There could also be an Init function, that may be called when the room is entered.
A few such A.I. classes are implemented in the ai.gs file, but users can add more if they need.
Some A.I. can be pretty simple, like the bat or the mouse, and some can be pretty complex.
Imagine an air bubbles special effect used when the player walks underwater. It uses of a set of dynamic brushes,
representing air bubbles, moved by a special code that takes in consideration the player's position, if he is under water,
if he has oxigen mask and so on.
Let's now have a look at some of the most common A.I.
Spiders and chains
A spider A.I. moves up and down between two specified positions, similar to the original spiders found in the classic Dizzy games.
For the wire, it can be combined with the chain A.I., by setting it as the target of the chain.
|
|
Spider A.I.
It represents a dynamic brush, updated through the AIUpdateSpider(idx) A.I. function.
The function moves the object up and down between two vertical coordinates, specified in the O_USER and O_USER+1 properties.
The O_STATUS property keeps the direction of moving, 0=up, 1=down.
|
The chain A.I. can resize it's height until it reaches another specific object, below.
It's like a chain or a wire with something hanging from it, like an elevator or a spider.
The advantage is that, when the hanging objects moves up or down, the chain object will be auto-adjusted to the right height.
|
|
ChainLink A.I.
It represents a dynamic brush, updated through the AIUpdateChainLink(idx) A.I. function.
The function changes the object's height until it reaches the vertical coordinates of a target object.
This target object is specified through it's brush id, in the O_TARGET property of the chain object.
|
Let's add such a spider with an wire.
Start from the default template data.
Add a spider object (tile=164, x=528 y=232, color=red, type=dynamic, id=1000, collider=call handler, class=hurt).
Set the O_USER (#32) property to 216, as the top y coordinate, and the O_USER+1 (#33) property to 248,
as the bottom y coordinate.
Add a wire object, picked from a part of a dotted tree trunk (tile=112, x=536, y=208, w=1, h=24, map=4,0,5,8, color=red, type=dynamic, id=1001, collider=none, class=none, target=1000).
Save the map and add the following update callback. Then run the game and play with the spider.
Trains and paths
A train A.I. is an object moving on a specified path, like an elevator or some dangerous creature.
It is similar to the mouse from the previous chapter but the path can be more complex than just back and forth.
|
|
Train A.I.
It represents a dynamic brush, updated through the AIUpdateTrain(idx) A.I. function.
The function moves the object along a path given through other objects, called waypoints.
The O_STATUS property tells if the train is active and moving (1), or if it's stationary (0).
The O_TARGET property of the train object keeps the brush id of the current waypoint to move to.
When the train reaches the position of the current waypoint, another waypoint is set as a new target,
in the train's O_TARGET property.
This new waypoint is stored, as brush id, in the O_TARGET property of the old waypoint.
So waypoints objects are linked together in a path, by targeting one another. If the last waypoint targets
the first one, we have a cycle.
The O_USER and O_USER+1 properties of an waypoint, also defined as O_WAYPOINTSPEED and O_WAYPOINTFLIP, store information
about the speed and flip option, the train must have while moving to this waypoint.
Waypoints are usually kept hidden, so their O_DRAW property is set to 0.
The waypoint class is not necessary to set, but will help, making clear the purpose of the object.
|
Let's see an example of a moving train.
Add a simple platform object on layer 0 (x=576, y=248, w=32, h=8, tile=125, map=0,56,32,64, color=yellow, type=dynamic, id=1010, collider=hard, status=1).
Set the target to 1011.
Add the first waypoint object on layer 7 (x=576, y=248, w=8, h=8, tile=0, color=magenta, type=dynamic, id=1011, draw=0, class=waypoint).
Set the target to 1012 and the first user property, representing the speed, to 2.
Add the second waypoint, identical to the first one,
but at y=176 with the id=1012 and the target=1011.
Add the following call in the room's update callback and run the game.
You must consider that these A.I. classes, implemented in the default template, can be used as a starting point
for more specific situations. It is the developer's choice to use them like that, or to write different ones more specific to his needs.
Read the ai reference info, check their implementation in the ai.gs file and try to understand it.
Homework
Extend the path of the moving platform with another two waypoints located in the next room, to make
a rectangular path cycle. So the third waypoint will be at the same height as the second, but the horizontal coordinate will
place it somewhere in the second room. The forth waypoint will be under the third, at ground level, like the first one.
Do the correct linking between them. Consider another update callback, for the second room, and don't forget to present the platform's object.
Here is a possible solution.
|
|
|
