1. Lecture IV: Views, Motions & Game AI
GAM 244: Game Design I
Lecture IV:
Views, Motions & Game AI

2. Part I: Views

3. Room Size versus Display size
Normally, GM will try to display the entire room on the screen, regardless of its size.
If the dimension of the room are smaller than your video display, the room is displayed inside a standard window box
Otherwise, GM will scale the graphics in order for it to fit on the video display. Distortion may occur, but the game is not affected.
Example: Try different dimensions for a room, use very small and very large dimension.
Question: what if your game calls for a very large room and you do not want to get any distortion?
Answer: use views.

4. Views
Creating ‘views’ is the standard solution to display oversized rooms:
Only a small portion of the room is displayed at any given time
The portion displayed changes over time, typically, following a game object.
Examples:
Platformers usually follow the main character in the level
Multiplayer racers will simultaneously show one view for each player
You can ‘zoom in’ the action or ‘zoom out’ to see the overall game.
In GM, a room can have up to 8 different views defined

5. Creating Views
When creating view, there are a number of room parameters we need to set.
Set the room size (‘setting’ tab) to some large dimensions
Using the ‘views’ tab, check the ‘enable views’
At least one view must have checked ‘visible when room start’
Now we must create at least one view. Views have three main characteristics:
The size of the display window (the ‘view’ or ‘viewport’) and
How much on the room is being showed in that viewport
What object (if any) should be followed with this view
All three of these characteristics can be specified in the ‘views’ tab

6. Creating Views Define View in Room:
X, Y: Upper left corner of the room
H, W: height and width in pixel Y X
View 0 H W
Full Room
Display Window
2- Define the view in room
1- Set the room size

7. Creating Views Define (View) on Screen:
X, Y: Upper left corner on the display window
H, W: height and width in pixel
View 0 Y X
View 0 W H
Full Room
Display Window
3- Define the viewport
2- Define the view in room
1- Set the room size

8. Creating Views 3- Define the viewport 2- Define the view in room
Full Room
Display Window
3- Define the viewport
2- Define the view in room
1- Set the room size
3.1- Define another viewport
Etc.
2.1- Define another view in room

9. Creating Views: View in Room
The ‘View in Room’ group (Third from the bottom) allows you to set how much of the room is visible through the viewport.
X, Y: The coordinates of the room that should be displayed in the upper left corner of the viewport.
W, H: The width and height of the room (in pixel) that should fit in the viewport (GM will scale the portion to fit)
Note:
The X, Y position will be overridden by the ‘Object Following’ if the object is not in view based on X, Y, H and W.

10. Creating Views: (View)Port on screen
The ‘Port on Screen’ group (second from the bottom) allows you to set the size of the viewport and its location within the display window.
X, Y: The coordinates of the upper left corner of the window relative to the display window.
W, H: The width and height of the viewport, in pixel
Note:
Views are drawn in order from 0 to 7.
Views can overlap (the later views obstructing the earlier ones)
To avoid distortion, make sure that the ratio W/H of the viewport is the same as the W/H of the view in room
GM determines the size of the display window from the total sizes and positions of visible views.

11. Creating Views: Object Following
The ‘Object Following’ group (bottom) allows you to have the view in room move along with a game object.
Object: The one to follow
Hbor, Vbor: When the object gets within that many (room) pixel of the edge of the view, the view will start moving.
Hsp, Vsp: Speed at which the room follows.
A speed value of -1 means ‘instanteneous’.
Other values may cause your object to go off-screem.
IMPORTANT:
Adjust the border so that
the any threat to the player is in sight
before being a danger

12. Creating Views: Limitations
One of GM’s limitations regarding views is that all draw actions are performed relative to the room and not relative to a view.
Full Room
View 0
View 1
Display Window
No Draw actions
can take place
outside the views
All Draw actions
take place here

13. Creating Views: Limitations
In particular, you cannot have a fixed overlay that would graphically separate the views
Example: see view-limitations.gmk
Full Room
View 0
View 1
Display Window
No Draw actions
can take place
outside the views
All Draw actions
take place here

14. Zoom in/out
When the game room is very large, the player may want to switch between viewing the whole room and a more local view with greater details.
You can achieve this using the view_visible[x] array of variables
x can range from 0 to 7 corresponding to each view
setting view_visible[x] to True or False determines whether the corresponding view is visible
Example: see player-controls.gm6
Note: always set to false views that are not used!! Otherwise, they needlessly slow down the game.

15. Part II: Motion Control Using Paths and Motion Planning

16. Paths Paths allows you to have objects move in preset complex motion.
Paths must be defined in the ‘paths’ resources.
They can be open or closed
Smoothed turns or angled straight lines
Speed can be controlled along the path
Speed is actually rated in percentage of the initial speed
When assigning a path to an object, we set:
Initial speed on the path
Whether to follow the path as absolute or relative coordinates
The orientation of the path can be controlled using code
Example: a bullet that shoots along a winding path. A single path could be rotated along any shooting direction (requires GML: we’ll see this example next week).

17. Note: finding the target is not guaranteed.
Motion Planning
GM offers two types of motion planning:
Direct: move the object towards a point x, y
Obstacle avoidance: same as above, but tries to go around obstacles
In both cases, the motion computed for a single step.
(that means: use these action buttons in the step event)
Note that GM’s motion planning is fairly sophisticated. Using only the ‘action button’ does not do it justice. Through GML, you can tweak parameters such as:
How far to look ahead
How much angle deviation to allow per search step
Maximum turn angle to allow per step
etc.
Note: finding the target is not guaranteed.

18. Motion Planning
If you are really curious, there is a third motion planning option:
Precomputed collision-free path
(only available through GML)
This techniques creates a path computed so as to avoid all collisions. You can then assign this path to a object to follow.
Beware:
Path computation is time consuming: use it sparingly
The path is collision free at the time of computation: if objects move while the path is being followed, collisions may occur.

19. Part III: Rudimentary AI

20. Making a Worthy Opponent
To make the tank game interesting, the opponent:
Must be aware of us (simply patrolling won’t cut it)
But should not be too aware (we need to be able to dodge him)
One possible solution:
When the green tank is far, patrol the area
When the green tank is close, hunt down and kill.
In order to do this, we can use the function
point_distance( x1, y1, x2, y2)

21. Making a Worthy Opponent
To make the tank game interesting, the opponent:
Must be aware of us (simply patrolling won’t cut it)
But should not be too aware (we need to be able to dodge him)
Similarly, when firing,
The tank should fire when we’re in its sight
But not fire like a fully automatic rifle!
Technically, this last point is not about AI but rather dealing with ‘realism’…
In order to do this, we can use the function
point_direction( x1, y1, x2, y2)
The use of alarms to slow down the rate of fire.

22. Making a Worthy Opponent
You can make the opponent more interesting by fine tuning some A.I. details such as
Range at which Brown detects Green
Precision of fire
Speed at which the Brown ‘spins’ to lock on Green
And of course, all these are influenced by other non-A.I. aspects such as
Range of bullets
Speed of tanks
Obstacles on the terrain
Once you got the mechanics going, you still must find out which settings make the game interesting

23. Part IV: Polishing Touches

24. Leaving Tracks
It would be nice if the tanks could leave tracks behind as they move around.
But at the same time, the tracks should fade after a time so as to not clutter the view.
Therefore, we’ll need to:
Create an animated sprite: two tread marks that fade from black to sand-color.
The track object should destroy itself at the end of animation
We can control the rate of disappearance through a variable called image_speed.

25. Depth
The depth of an object affects the order in which it will be drawn relative to other objects.
Visually speaking: if objects overlap, those drawn earlier will appear ‘under’ those drawn later.
By changing the depth value of an object, you can insure it is displayed properly relative to the others.
The drawing order is:
From highest depth to lowest depth (including negative values)
For objects having the same depth value, order is arbitrary.
Therefore, if you want to guarantee that an object appears…
on top of everything: give a large negative depth
under everything: give a large positive depth

26. Health Bars
GM maintains a single global variable health that can be used with the health bar action button.
This is fine for most cases, but if you wish to keep track of the health of multiple game objects, you need to work a little bit harder.
Specifically:
Each object needs to maintain its own health. Note: do not use the variable name ‘health’ as it interferes with the global one.
When taking a hit, the tank’s damage is reflected in its variable
In the draw event: use draw_healthbar (NOT the action button!)
Note: the ‘health bar’ action button only operate on the global health variable. Therefore, it should not be used for this purpose.

27. IMPORTANT NOTE
Many concepts presented this week were implemented using a very simple setting of a single player and single opponent.
Unfortunately, such concepts as
Motion planning
Health bar display
Adaptive behavior
etc.
are a little trickier to implement when you have multiple instances on an object in game.
We will see how to deal with multiple instances of the same object in next week’s lecture.
See also “Tank8-Existence tests” for dealing with targets that might be destroyed