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

Part I: Views

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.

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

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

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

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

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

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.

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.

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

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

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

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.

Part II: Motion Control Using Paths and Motion Planning

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).

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.

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.

Part III: Rudimentary AI

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)

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.

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

Part IV: Polishing Touches

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.

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

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.

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