Strategies in Game Design



Advanced Game Prototyping

Lesson 1 Software Instruction: Game Maker Tutorial 10

Part one intro to 3D page 1

Part two Parallax Scrolling tutorial lesson page 6

Part three Pa+rallel Projections tutorial lesson page 12

Part four Scaling Images tutorial lesson page 22

Part five Isometric Games tutorial lesson page 32

Part six Making Sprites and Masks page 37

.

You’re ready to create games that look more three-dimensional (3D) and there are many ways to do this.

I. Classic methods for faking 3D in 2D game engines

Folks, there ain’t no such thing as a true 3D game. All games produce a 2D image on a flat computer or TV screen. They might look 3D, but they aren’t really. So what makes a game ‘3D?’ It is a combination of the way the game is created, the visual image the player sees, and the way the player controls the game.

Modern 3D games (e.g., Unreal, Halo) model their game worlds with 3D Objects utilizing 3D graphics hardware. In them, the player’s viewpoint has the hardware creating the correct image ‘on the fly’ (i.e., instantly with raw computer processing power), taking into account aspects like lighting, hidden surface removal (Objects behind other Objects cannot be seen and should not be drawn) and atmospheric effects.

Although stunning in appearance, there is a price to pay for 3D graphics bonanza. Modeling a 3D world with 3D Objects is difficult, time consuming (as you well know), and the programming logic, including the game Objects’ behavior, collision detection, camera movement, and so forth are also very difficult. Thus, making a modern 3D game is a huge undertaking that requires a large team of specialized game developers and typically costs millions of dollars. Even then, many of these games have errors (in particular, in the handling of the camera, plus the character motions and collision detection).

How does this affect us using Game Maker? Well, this program does not support true 3D game worlds (obviously), but there are functions for ‘old school’ 3D graphics. You see, all 3D looking games produced through 1995 (and many since) don’t use 3D worlds. For example games like Age of Empires and the Command and Conquer series (except for the last) are not played in a 3D game world, but instead employ an isometric view. They use Sprites to represent the game world and characters, and then employ some relatively simple tricks to give the user a feeling of a 3D world.

In this tutorial, we’ll examine four of these tricks for creating 3D looking games in Game Maker. We’re getting into more advanced techniques now, and eventually we’ll take a stab at doing real 3D graphics, but that’s in a later tutorial. Right now, we need to understand where the illusion of 3D comes from.

II. The illusion of 3D

How do we take a 2D image on a flat screen and make your brain accept that it’s a 3D image? There are many elements that come into play when creating this illusion:

1. Objects that lie behind other Objects are (partially) hidden

This is a key concept. You can’t see through solid Objects, right? So, when a character is partially hidden by a tree, the viewer’s brain immediately accepts that the character is behind the tree. By simply drawing some Objects over others (remember the ‘Depth’ you can set for Objects?), the viewer gets a better insight in the 3D relationship between them. Thus, to make a world look 3D, we must only display the Objects that are actually visible. This process is known as hidden-surface removal.

3D graphics hardware deals with hidden-surface removal automatically but, because Game Maker creates a 2D world, we have to do hidden-surface removal in our games ‘by hand.’ We do this by having the Objects drawn on screen in the correct order. That it, the Object that lies furthest away is drawn first; the next-furthest Object is drawn on top of it, and so on. Because closer Objects are drawn on top of Object behind them, they will (partially) obscure those the other Objects.

In Game Maker we can achieve this by setting the Depth for the different Object instances. Instances with a larger Depth are drawn before instances with a smaller Depth. See ‘That’s Deep’ sidebar.

2. Objects that lie further away appear smaller

You learned in Perspective that further away Objects are the smaller they appear. We can use this in Game Maker to create a very strong notion of distance and, hence, a better 3-D feeling.

This is achieved by changing the size of the Sprites depending on the distance. You can either make Sprites with different sizes or draw the Sprites with a scale factor (discussed further below).

For example, when an Object moves towards the viewer, it should become larger. This creates a very strong illusion of moving through a 3D world. Warning: If you don’t do the scaling right it gives the exact opposite effect.

3. Objects that lie further away appear vaguer

When Objects are ‘further away,’ you can’t see them as clearly. This works the other way around, in that close-up Object are very clear and detailed.

When an image appears vague our minds interpret it as being further away. Hence, adding a feeling of mist and/or blurring images a bit that are supposed to be further away gives a great illusion of distance. This can be achieved by using different Sprites for the same instance, depending on its Depth.

4. Object that are further away appear to move slower (and vice-versa)

An Object that is further away should take longer to traverse from the left to the right across the screen, while an Object that is closer moves much faster across your view. Varying the horizontal speed of Objects depending on their closeness to the viewer creates a great illusion about their depth. One particular aspect of this is parallax scrolling that that is featured in this tutorial.

Another consideration is that Objects moving away from you (or towards you) will hardly change position on the screen. So, an Object’s vertical speed on the screen (which is usually used to represent movement toward or away from you) should be slower than its horizontal speed.

5. Objects tend to have a shadow in a 3D environment

Ever since God said, “Let there be light,” artists have had to deal with drawing shadows. It is difficult to compute shadows on other Objects in a video game (which is why we have programmers), but it is relatively easy to have shadows on the floor (even in Game Maker) – and that should be enough to be getting along with.

Even if there is no shadow in your game, it is still a good idea to have a little dark spot around the bottom of an Object. This gives the impression that the Object stands on the floor. Make sure the shadows are consistent, that is, all Objects have shadows (or none do), and that they have the same size and project in the same direction (i.e., from the same light source).

For example, in the picture above, it is unclear where the left character stands. The middle character clearly stands on the ground, while the right one is jumping above it.

6. Parallel lines appear to meet in a point

As artists, you know that parallel lines in a 3D world meet in the distance at a vanishing point. For example, the two sides of a road meet in the distance. Stated more precisely, our view generates a perspective projection. Creating this illusion in a game distorts Objects depending on their depth, but this distortion is exactly what gives it a 3D feeling. Consider for example the following two images:

[pic]

The left image shows an overhead view projection without perspective. All of its vertical lines are parallel. Conversely, in the image on the right, you see a perspective projection. Its vertical lines will meet somewhere in the distance. The image on the right gives a much better 3D feeling.

Perspective projections are important for 3D games, but they are not easy to achieve with Sprites; sprite-based games rarely use perspective transformations.

Instead, sprite-based games commonly use a projection at a 45 degree angle. That is, the perspective they offer isn’t straight from the front, but a bit from the side. This view, called isometric, has the effect of its parallel lines is less prominent (so the viewer is less distracted by them). No doubt you’ve seen many games that employ an isometric projection as show below:

[pic]

If you look carefully, the lines are indeed still parallel (which is wrong) but still it looks a lot more 3D than the overhead view, above. We can create isometric view games in Game Maker as you will learn in these tutorial lessons.

TUTORIAL ONE

III. Parallax Scrolling tutorial lesson

As listed in #4 above, Objects that are further away move slower horizontally than objects that are closer. In this lesson, we will apply that illusion of 3D movement with a side-scrolling background and static Objects.

A. As we’ve done previously, you can add Backgrounds to your Rooms in Game Maker.

Very often a room has just one background but it is possible to have multiple backgrounds. Of course, to see those backgrounds they need to be partially transparent or cover just part of the room.

By giving deeper Backgrounds (i.e., those with a higher Depth value) a slower speed than the closer Backgrounds (those with a lower Depth value), you create the illusion that the deeper Backgrounds are further away.

B. Open up the Tutorial 5.1 Parallax folder and let’s start by creating a blank room for our masterpiece, and then two Background images.

1. Open a room and conform its settings to the values on the left. Make sure that the room height is only 320 pixels.

The first Background will be bkgd_mountains as shown below (with mountains at a distance):

[pic]

2. Create a Room and place this Background at the top of the room. (It will default as Background 0.) Set it to scroll left (to create the illusion of moving to the right) at the very slow Hor. Speed of minus one (-1). This image will be tiled horizontally but not vertically!

[pic]

3. For the second Background, you need to create is the small road graphic, bkgd_road (all the default settings are fine). Place it in the room as Background 1 by and it is placed at the bottom of the room by setting it to Y:250 and move this tile much faster at minus four (-4) speed horizontally only as shown below:

[pic]

4. Now create spr_car with Smooth edges and its Origin point at X:16, Y:27 (near the bottom-center). The slap this Sprite into a new Object, obj_car, with a Depth of 5 and as shown below:

[pic] [pic]

5. Place the car in the Room on the road in the right-lane (this is America, after all) near the left side of the screen. Run the game quickly and adjust the location of the car in the room until you are satisfied with its placement.

Note that the car does not need to move because the background are moving to create the illusion of motion, just as they did in our scrolling shooter tutorial, 1945. Note that because the road is moving faster than the mountains, you get the sense that the mountains are further away. This is the premise of Parallax Scrolling.

6. Now let’s add a bit more pizzazz to give the room more ‘depth’ with the inclusion of trees.

Make a Sprite for each of the three tree sizes. They should all have the Transparent box checked (the default setting) and their Smooth edges box checked (which is not the default setting) with each having its Origin point (X:, Y) at its bottom-center as shown below:

[pic]

[pic]

[pic]

Next, each of these trees needs an Object. Start with the small tree which will be furthest back (Depth: 20) and, for its first Event, create moving left slowly at speed two (2) as shown below:

[pic]

Now, we need one more Event, this time when the tree exits the room (Event, Other, Outside Room). When it does this, it should teleport back off the right side of the screen somewhere near the top. First, we’ll test the tree to make sure it’s moved off the left side of the screen by asking If a variable has a value, that is if ‘x’ is small than ‘0’ as shown below:

[pic]

If that’s true, we need to teleport the tree back of the right side of the screen, give or take a couple of hundred pixels, Relative to its current Y axis. That is, we don’t want to move the tree vertically, just teleport it horizontally off the right side some variable amount – x: 600+random(200) – as shown below. Be sure to use (parenthesis), not [brackets].

[pic]

Duplicate (copy) obj_small_tree to create obj_medium_tree, changing its Sprite to the correct size tree, and its Depth to ten (10) and its Speed to three (3).

Then copy it again to create obj_large_tree, changing its Sprite to the correct size tree, and Depth to zero (0) and its Speed to four (4), like the road.

7. In the Room, change the background color to a grassy green and drop in some trees, smaller in the background, larger in the foreground. Something like this:

[pic]

Run it, and you should see some nice parallax scrolling effects! You can find the demo in the file as parallax.gm6.

Parallax scrolling is very useful in both side-scrolling and platformer games. In a platformer game, you would have to make the speed of the moving backgrounds relative to the current horizontal speed (h_speed) of the player’s character.

TUTORIAL TWO

IV. Parallel Projections tutorial lesson

True 3D games should use perspective projections (#6 in the above list), but that is very hard to create. As another alternative to faking 3D, we’ll explore parallel projections.

A. In a parallel projection, parallel lines remain parallel and the size of the Objects stays the same regardless of their distance. Naturally, this makes it much easier to use Sprites because Sprites have a fixed size.

Although parallel projections give a distorted view, players can accept it because of the smooth gameplay it provides. To minimize the effects of this distortion we’ll prevent the player’s from seeing Objects that are too far away by limiting the height of the view window (giving it a ‘widescreen’ appearance); in this way, the player will not really notice the parallel projection ‘distance errors’ because the short room height prevents them from seeing anything in the window that is far away.

A parallel projection is achieved by ‘looking down’ on the world at an angle (normally about 45 degrees). Thus, our worlds that have previously consisted of squares would, in a parallel project, now look like rectangles, like this:

[pic]

Maybe seeing this as a background image might help. On the right is the standard, square-based, overhead ‘God view’ that you’re used to seeing in Game Maker. On the right is a parallel projection of the same image. It’s subtle, but you should be able to note the difference.

[pic]

To create a parallel projection image, we simply scale it in the vertical direction only.

Let’s create a small proof of technology demo using parallel projection. In it, we’ll have the player control an avatar that walks around an enclosed world with some trees in it. There are three major considerations when creating a parallel projection game:

1. Hidden-surface removal must be handled correctly, so that when the avatar is behind a tree it is drawn before the tree and thus appears obscured.

2. We have to deal with the speed of the character so that moving vertically is slower than moving horizontally.

3. And hardest of all, we need to deal with collision detection correctly.

B. Open up the Tutorial 5.2 Parallel folder and let’s start by considering hidden-surface removal.

1. Create a Sprite called spr_player_down and uncheck (i.e., turn off) Precise collision checking. One key for these Sprites (there will be four total, one facing the avatar in each direction) is to give them a common Origin point and Bounding Box.

As you know, every Sprite has an Origin point which is the single pixel location on that Sprite that is used by the computer to keep track of its location. That is, when you place an instance of an Object at a particular position (i.e., X, Y coordinate), you are actually put the corresponding Sprite’s Origin point at that position.

When you create a Sprite in Game Maker, its default Origin point is the top-left corner of the image. When dealing with a 3D world (as we are in these lessons), it is easier to manipulate that Sprite in the game by setting its Origin point to the position where it ‘stands’ on the ground. So, for all Sprites, we’ll set their Origin point to where they stand. For the avatar, set its Origin point to X:16 and Y:32 (i.e., the image’s bottom-center pixel).

Now, we’re also going to manually define a small Bounding Box around the avatar’s feet. Set the Bounding Box values to Left:8, Right:24, Top:28, Bottom:32. The reason for this you’ll discover in a bit when we concern ourselves with collision detection, but for now your initial avatar Sprite should look like this:

[pic]

Now, duplicate this Sprite three times to create spr_player_up, spr_player_left, and spr_player_right using the appropriate images. Don’t change any of the other settings; you want the same Origin point and Bounding Box on each of them.

2. Now create a new Object, obj_player. Set its initial Sprite to spr_player_up. The default settings are fine, but we need to think about its Depth. After all, this needs to be computed dynamically – that is, when the avatar walks behind a tree it needs to be drawn first, and when it walks in front of a tree the avatar needs to be drawn last (i.e., with the tree behind it). Thus, having a fixed value for the avatar’s Depth won’t give us the illusion of 3D that we’re after.

To dynamically determine whether the avatar is in front of or behind another Object, we need to check every Step what the avatar’s Y-coordinate is; this will tell us where it is vertically in relation to other Objects on the screen. Instances of Objects with a low Y-coordinate (i.e., those that are close to the top of the window) must be draw before (i.e., underneath) instances of Objects with a higher Y-coordinate. In other words, a higher Y-coordinate means a smaller Depth. We do this by creating a Step / End Step Event and setting the value of a variable ‘depth’ to ‘-y’ as show below:

[pic]

Let’s get the avatar moving. We do this in the same way that you did in Tutorial #3 (the maze game). Start by creating a Keyboard Event . There are two Actions. The first, obviously, is to Start moving in a direction (press the left arrow button and set the speed to 3). The second Action is to Change the sprite to spr_player_left with a Subimage:-1 and Speed left at the default setting of 1 as shown below:

[pic]

Of course, you need to Duplicate this for the , , and arrow keys, each calling the correct Sprite image. Important, the Speed setting for the and directions is only 2, not 3. Remember, the avatar must move slower vertically than horizontally because we’re using parallel projections – that is, the avatar is moving along a rectangular grid instead of a square grid.

Finally, we need to stop the avatar when no key is being pressed. We can do this in two Actions. First, have the avatar Start moving in a direction and press the square block in the center (for ‘stop’) and set its Speed to ‘0.’ Second, to stop the Sprite animation, Set the value of a variable using the variable ‘image_speed’ and setting it to ‘0’ (i.e., the same thing that we do when a collision occurs), as per the illustration below. See the sidebar on Subimage Speed for additional details.

[pic]

Note that these key press commands have little to do with faking 3D, save for the slight difference between horizontal and vertical speeds (of 3 and 2, respectively). That is, this is pretty much the way we would handle avatar movement in a lot of different kinds of games. When doing your own games, you’re probably going to need to experiment a bit with these numbers, but this lesson should give you an idea how to think about them.

3. Next, we must deal with collisions. Normally a collision occurs when the Sprites partially overlap. This is fine for a 2D game, but not for a 3D game.

When the avatar stands in front of a tree, for example, the Sprites overlap but we don’t want there to be a collision between them. So we need something else to define the collision area besides a box the size of the entire Sprite!

In a parallel projection (and other fake 3D) games, we would just consider the area where the instance of an Object touches the ground. In this tutorial, only when the feet of the avatar overlap with the bottom of a tree trunk would there be a ‘collision.’

The easy way to achieve this in Game Maker is to define a very small Bounding Box for all the Sprites at the bottom and not use precise collision checking, which is how we set up the avatar Sprites above. Since in Game Maker a collision is only reported if the Bounding Boxes partially overlap, this will create exactly the effect we want.

So, now we need to make the tree Sprite (spr_tree) as shown below:

[pic]

Notice the small Bounding Box where the tree touches the ground; that is half of what we’re using for collision detection to help us fake a 3D environment. The other half is defined with obj_tree, which you must now create, as shown below:

[pic]

Note that the Depth setting on the left defined as ‘0’ on the left, but in its Create Event, we Set the value of a variable, ‘depth,’ to ‘-y’ (i.e., negative Y), just as we did for the avatar. Of course, for the avatar, this was a Step Event since the avatar was moving all the time. For the tree, a ‘static object,’ we only need to establish this when it is created (i.e., placed into the game). By using this ‘depth’ variable based on the Object’s vertical (Y axis) position, Game Maker knows in which order to draw them so that they appear in front of and behind each other in a 3D-looking way.

4. The final ingredients we need to create our world are similar to those we used in Tutorial #4 (the platformer game). That is, we need a solid but invisible wall to define the boundaries of the world so the player doesn’t walk off the screen, and we need a pretty set of background tiles to make an attractive world from.

First, let’s create spr_wall with the settings shown below, left:

[pic] [pic]

Note that this Sprite has no Transparent pixels to worry about (so that box is unchecked), again we turn off Precise collision checking, and we set the Bounding Box to the Full Image so that its entirety will be used in defining a collision.

Next, create obj_wall (as shown above, right), but make it invisible and solid.

5. We need to finish the other Collision Events, one each for obj_tree and obj_wall. They both have the same two Actions: ‘Start moving in a direction’ using the center square (for “stop”) and setting the speed to ‘0.’ Then, Set the value of a variable for ‘image_speed’ to ‘0,’ just as you did for the No Key Event. That will stop the avatar and hold its correct image in place.

6. To make the room pretty, create a background image, bkgd_parallel and select Use as tile set with the settings shown below:

That’s everything we need to create the Room. This will work like it did the for platformer game – first we use the tile set to make a beautiful background, drop in some trees and the avatar, then we place the invisible obj_wall Objects around the edges and other places where the avatar cannot move.

First let’s get the Room Settings right. Create Room Parallel 1 in a 720 x 480 size and a grid of 24 x 12 pixels as shown below:

[pic]

We also need to tab to Views to make this a 3D-looking game. What we want is a ‘widescreen’ view (like at the movies) to help protect the illusion of 3D movement vertically. Set the Views tab as shown on the left. That is, check the Enable the use of Views and Visible when room starts boxes. Make the View in room and Port on screen sizes 400 x 200 pixels (to create our ‘wide screen’ view and thus enhance the illusion of depth). Finally, have the camera follow the avatar around with a 96 x 64 pixel buffer around it.

And now it’s art time! Select the Tiles tab and go to town. Each background tile takes up four rectangles, and if you find the right ones, you can make a ‘board’ that looks like this:

Then we add the avatar and some trees (including little clumps of forests with lots of trees) to get something along these lines…

[pic]

Then, finally, place obj_wall over the wall art around the perimeter and in the courtyard in the center of the play area (just as we did in the platformer tutorial), like so:

[pic]

And viola! You should be able to play your parallel projection proof of technology demo. Go ahead and walk the avatar around to see if you get a 3D world illusion.

TUTORIAL THREE

V. Scaling Images tutorial lesson

Parallax scrolling? Check. Parallel projection? Check.

The down side to parallel projection is that it really only works if we keep the view high up off the ground in a fixed orientation (we used a 45 degree angle point of view in the tutorial). In addition, we can only show a small part of the world at a time (the ‘wide screen’ look). In some cases, that’s good enough, but if you want to create a first-person perspective game of have a point of view that’s closer to the ground, you need a perspective projection (#6 on the list in the first section – where parallel lines meet in the distance at the ‘vanishing point’). That is, the size of Objects gets smaller when they are further away.

A. But how do you achieve varying the size of Objects based upon their distance? In the parallax scrolling tutorial, we used three different size trees. That’s fine if the trees will remain at a fixed distance, but in a real 3D game the player might walk up to them and, therefore, their size should continuously change as they are approached.

While we could create a lot of different Sprites (one for each size to represent the various distances away that they can be observed from), that would use up a ton of computer memory (the scarce ‘currency’ of programmers that is carefully allocated and spent when creating a game). While this might be a good idea for very important Objects in your game (because it provides the best art quality), for general items we use a Scaling Sprites technique to vary the size on an Object ‘on the fly.’

In this tutorial, you will learn how scale Sprites in a simple technology demonstration where the player must avoid trees while moving through a forest.

B. This technology demonstration begins by creating spr_tree (there will only be one tree Sprite, and we’re going to change its size dynamically during play). Turn off Precise collision checking and turn on Smooth edges. As in the previous 3D tutorials, set the Origin point to the bottom-center (X:64, y:123). Then manually set a Bounding Box at Left:48, Right:80, Top:96, and Bottom:120 as shown below:

[pic]

C. The other Sprite we’ll need is for the avatar. Create spr_player as shown below. The checkboxes and values are all set as indicated for the same reasons we did them with spr_tree.

[pic]

D. Next, we’ll be using the mountain background image again, so make bkdg_mountains (all the default settings are fine).

E. With the artwork in place, we need to create some Objects. Start by creating obj_player as shown below.

As you can see, we set the Depth to ‘-300’ and created the first Keyboard Event . Like many of the other games we’ve made in Game Maker, we look before we leap. In this case, we’re asking If a variable has a value and checking to see if ‘x’ is larger than ‘230’ (a very generous margin from the left edge, but then this is a very wide room), and if it is, we move two pixels to the left (x: -2, relative).

For the Keyboard Event, the variable ‘x’ is checked to see if its ‘smaller than’ ‘room_width-230.’ If so, we can jump two pixels to the right, as shown below:

[pic]

These 320 pixel buffer will keep the player from moving too far to the left or right during play.

We’ll finish obj_player for now with one last Event. This will be a Step Event where the only Action is to add a point to the score, as shown to the right. Since this is a game of survival over time, the longer the player lives, the higher their score will be.

Later, after we define obj_tree, we’ll come back and create a Collision Event for it so that, when the player collides with a tree, we will show the high score list and restart the game.

F. Next is the Object for the tree, which is where the dynamic scaling will be taking place so pay attention!

For a tree, we have a lot to think about. These trees need to appear in the distance and then grow larger as the player moves toward them (thus creating the 3D effect of scaling). So we need to think about their size, their position on the screen, and their depth.

Later on, we’re going to create a controller Object that randomly creates trees on the Y:180 line, and at the end of each Step we’ll scale each instance of a tree Object based on its Y-position using one of Game Maker’s built-in variables, image_xscale and image_yscale. That is, when the tree is back at Y:180, the scale factor will be very small; as the tree moves closer to the bottom of the screen (its Y value will be increasing every Step), the scale factor will keep growing.

1. Create obj_tree. All of the default settings are fine, and it only has one Event, an End Step Event with several Actions.

2. In the first Action, you’re going to learn something new: How to insert code into the Game Maker program. Mechanically, this is very easy to do; understanding what you’ve done is trickier.

Included with this tutorial is a MS-Word .doc file called ‘code for 5.3 Scaling.’ Open it and copy everything between the {squiggly brackets, including the brackets themselves} to the clipboard. Then find the Action Execute a piece of code on the Control tab and ‘paste’ in the code you just copied so that it looks like this:

[pic]

What have you done? You’ve established two new variables for tree Objects: ‘x offset’ and ‘y offset’ (i.e., ‘xoff’ and ‘yoff,’ in the parlance of programmers). While the specific definitions of these two new user-defined variables are expressed in the above code formulae, you can write it off as ‘technical mumbo-jumbo’ at this point, if you like, or look at the sidebar Decoding this Movement Code to the right.

What you really need to know is that there are a lot of these handy Game Maker codes laying around that do all sorts of marvelous things to make your game do what you want, and all you have to do is find them and copy and paste them into your game as you’ve just done here. Pretty cool, huh?

You should learn what the color of the text means. Blue text means you’re looking at a system variable that already exists within Game Maker (e.g., ‘X’ and ‘Y’). That is, a blue-text variable is not a user-defined local variable that you’ve defined yourself (e.g., ‘ammo’), but one that’s already hardwired into the basic game engine.

Green text, which begins with two slashes (i.e., //), is called comment text. It doesn’t affect how the program runs. Instead, it exists merely to let people know what the code is doing. Thus, whoever wrote this code has left you a trail of breadcrumbs to follow in understanding it – that is, what the code actually does and how you can use it. When code is well thought-out and commented (as this code is), it is called goody two-shoes code. This is the kind of code that programmers start writing games in. Under schedule pressures at the end of a project, however, code is often rushed out to fix some bug or other and it becomes sloppier and less commented, making it very difficult for those who might read it later to figure out. This style of late-project, slap-dash ‘whatever works’ expedient programming is known as hacker code.

3. That bit of code redefined the X: and Y: values of tree Objects a bit, and now it is time to put that code to use. The next action is If a variable has a value where ‘y’ is ‘larger than’ ‘320.’ If that’s true, then the tree has moved off the bottom of the screen – so the next Action is to Destroy the instance of ‘self.,’ as shown below:

[pic]

4. If, at the end of each Step an instance of obj_tree is not thus destroyed, now is the time to dynamically scale it to the correct size based on its distance to the avatar and then nudge it to the left or right of the avatar to create the perspective that is our 3D illusion. We can achieve these things in three Actions, in each of which we Set the value of a variable.

First, Set the value of a variable for the variable ‘image_xscale’ where the value is

‘(y-178)/100.’ Be sure to use (parenthesis) in that equation and not [brackets]. This will nudge the tree to the left or right (as defined in that piece of code we’re running, see the sidebar Decoding this Movement Code) as it gets closer to the bottom edge of the screen.

The second action is very similar in that you’re only changing ‘xscale’ to ‘yscale.’ Set the value of a variable for the variable ‘image_yscale’ where the value is ‘(y-178)/100.’ This will re-size the tree, as per the piece of code we’re running, so that its Sprite gets larger as it gets closer to the bottom of the screen.

And the third and final action in this trio is simply Set the value of a variable of ‘depth’ to ‘-y’ (i.e., negative Y:, as we did in the parallel project section of this tutorial). This means that as trees move closer to the bottom of the screen (i.e., get a larger y-coordinate value) we want them to have the illusion of becoming closer to the viewer to achieve our 3D effect. Setting this variable means that trees with a smaller Depth and are drawn on top of other trees that have a higher Depth, which is what we want.

When you have all this, here is what it should look like:

[pic]

If you have registered your copy of Game Maker (which you should have by now), an easier and more effective way to manipulate the Sprite image on the fly would look like this instead:

[pic]

This Transform the sprite Action can also be used to rotate or mirror the Sprite, but that is not a part of this tutorial lesson. Still, you’re free to experiment with this on your own and see how it works.

G. There’s one more adjustment to make in obj_player before it’s complete. Open up obj_player and create a Collision Even with obj_tree.

There are two Actions. The first is to Show the highscore table. Go ahead and use the mountains background image and, if you’re not feeling creative, try the color and font scheme shown in the illustration, below.

The second and final Action is to Restart the game.

[pic]

H. Then at last we need a controller Object that will generate an ever-increasing number of trees so that, eventually, the one will smite the player and end the game. You’ve made controller objects before, and this one is very much like them.

Create obj_controller and uncheck the Visible box.

There is only one Event, a Step Event. In it, we’re going to write a block of Actions that will randomly generate trees using a virtual ‘die roll.’ Start a block of Actions, and the With a chance to perform next action of 1-in-10 chance (i.e., you’re creating a virtual D10 die rolled every 30th of a second where one side of it means ‘do the next Action’).

Then Create the instance of an object, selecting obj_tree. Set ‘x’ as ‘view_xview+ random(view_wview),’ and ‘y’ as ’180’ as shown below:

What that ‘x’ variable means is that the tree will only be created horizontally within the defined game view – ‘view_xview’ (i.e., you don’t see the whole game at once, only a view of it, and we’re only going to place trees inside the view where we can actually see them). You’ve used this variable before in the platformer tutorial.

The ‘+random(view_wview)’ part means that tree will appear at some random x-coordinate between the left side of the Room view (‘view’) and the right side of the Room view called the room width (‘wview’ means the width of the Room view).

But how do we generate an ever-increasing number of trees? Well, we could do that as we did in 1945 and simply have them teleport back to the starting point, but here’s a better idea for this game. We’ll just make more die rolls to generate trees over time. Here’s how:

Select the Action Repeat next action from the control tab. This writes a rule for the game telling it how many times to do the next Action. The default value is once, but we want to make additional tree-generation rolls as the game progresses. Set the times variable to ‘1_score/300.’

Move this Action to be the first on the list, so it looks thus:

[pic]

This Repeat next action means that every step it will make 1 die roll to generate a tree. In addition, every time the player’s score reached another 300-point plateau, an additional die roll will be made. So, for example, if the player’s score was currently 900 points, each Step the game would make 1+3 = 4 die rolls to generate trees. You can do the math to see that eventually there will be so many trees generated that the player is doomed.

I. Finally, we’ll create the Room that this excursion into the heart of a forest takes place in.

Create Room Scaling 1 and adjust the settings so that it has a Width of ‘2000’ and a Height of only 320, as shown below on the left:

[pic]

That room size will neatly fit the entirety of our mountains background art, only this time we’ll be using it as stationary artwork only (i.e., they won’t be scrolling). Place bkgd_mountains in the room and have it Tile Horizontally. Pick a nice grass-green background color until you have this:

[pic]

Of course, we’re only going to be seeing a subset or view within this rather wide gameplay area, so tab over to views and let’s set the framing, shall we?

Check the Enable the use of Views and Visible when room starts boxes. Set the other for View in room, Port(ion) on screen, and Object following as shown in the illustration below:

[pic]

That establishes the game’s view, now we just have to drop in the last couple of Objects: the avatar and the controller. Note that we don’t have to initially place any trees as they will be continually generated during play.

Now place an instance of obj_player (the avatar) in the center of the room, near the bottom (i.e., in the green ‘grass’ area). Having done that, we need only place an instance of controller Object (obj_controller) anywhere in the room. It should look something like the illustration above.

That should do it. Test it out! You can use this tutorial as a basis for many of your own game ideas.

TUTORIAL FOUR

VI. Isometric Games tutorial lesson

Finally, we will create a faux 3D perspective game using the very popular isometric view. An isometric view is one where these is about a 60-degree overhead perspective and the Object tiles are all rotated at a 45-degree angle (as shown in the illustration on the right). Many popular games use an isometric view including Age of Empires, Diablo, Command and Conquer (except the last one), SimCity, and many other strategy and simulation games.

In principle, you can make games of that caliber with Game Maker, but realize that those commercial game products took years to create by dedicated teams of game development specialists!

A. The principle of an isometric game is that the 3D world is viewed at a fixed, 45-degree angle.

Once again, parallel projection is used to create this look – that is, there is no perspective (i.e., parallel lines will never converge at a far-distant ‘vanishing point’) and so Objects in the distance do not become smaller.

Assume the world consists of regular square cells as shown at the left of the picture below. An isometric view takes that square grid and rotates 45-degrees so that it will look like the ‘square’ grid on the right side of the picture. Thus, each square has become a diamond shape. To make lining up cells easy we typically use a 2:1diamond grid ratio (e.g., 32x16 pixels, 64x32 pixels, etc.).

[pic]

As an actual game background image, these would look something like this:

[pic]

The principle advantage of an isometric projection over a normal projection is that our mind immediately interprets the diamond-shaped tiles as ‘squares’ viewed at an angle. This creates and ‘instinctive’ a 3D image to the player.

The illusion isn’t perfect, of course. Clearly, it still causes some perspective distortions because the size of Objects doesn’t change with their distance. However, we can again limit this perspective distortion by showing only a small part of the world in the game view. If you think about it, most isometric games use only a limited view on the world on the screen.

B. As an example of using the isometric perspective in Game Maker, let’s make a simple isometric maze game. Although it is not very sophisticated, it will demonstrate the key concepts that you can use in making your own isometric view game.

Honestly, the first step is to design the game on paper. It’s very hard to improvise a maze while building it in an isometric view. Find some square-grid graph paper and make a maze in a room that’s 18 squares tall by 21 squares wide; include a wall along the entire outer edge of the room (just as you did in the maze game tutorial you did back in Prototyping).

Below is an overhead, graph paper-view, square grid, 2D version of the maze we’ll create in this particular tutorial lesson:

[pic]

C. In Game Maker, the first thing we need to do is create an isometric-shaped background ‘floor’ image for the maze. It must be big enough to fill the whole area covered by the maze.

Create the Background image, bkgd_game; all the default settings are fine. This 640x386 pixel graphic is the right size to fit the entire maze.

[pic]

D. Making Sprites and Masks.

If you’re not an artist, creating Sprites for an isometric view game can get a little tricky. Obviously, they need to be created with a pleasant 3D look from the proper 45-degree angle; they should also neatly touch the bottom (i.e., ‘floor’) of their drawing area so that they do not appear to ‘float’ in the game when placed on the grid. Creating isometric graphics is usually the most time consuming part of creating this type of game and will test the artist in anyone.

But it’s not enough to create pretty Sprites. They also have to make functional Objects in Game Maker. The key here is ‘collision detection’ – the avatar (a ball in this case) has to collide properly with the walls. Although we’re making 3D-looking Sprites for the ball and wall, we don’t want to set their collision points in mid-air as that could be imprecise and really mess things up. Instead, we’re going to give these Objects a ‘shadow’ on the floor and use that shadow for collision detection. This shadow is called an Object’s collision mask and so creating these Objects will require two Sprites each: one that is its pretty picture and another (its shadow) that will be assigned to it as its collision mask. See the sidebar on the next page, The Origin Point for Sprites & Shadows.

Go ahead and create spr_block. The default settings are fine except for its Origin point, which should be X:16 and Y:24 (i.e., centered horizontally and 8 pixels up from the bottom vertically) as shown below:

[pic]

Then create its collision mask (or ‘shadow’) called mask_block. Again, the default settings are fine except for the Origin point, which should be centered at X:16 and Y:8 (also 8 pixels up from the bottom), as shown below:

[pic]

Okay, now we need spr_ball. For this Sprite, check the Smooth edges box (to make it look better as it moves around the maze) and set its Origin point to X:12 and Y:20 (i.e., similar to spr_wall, it is centered horizontally and 4 pixels up from the bottom vertically) as shown below:

[pic]

And then the ball’s shadow must be created, mask_ball. Again, the default settings are fine except for the Origin point, which should be centered at X:12 and Y:20 (4 pixels up from the bottom), as shown below:

[pic]

Don’t worry, this will all make more sense when we use these to create Objects. Note that when making isometric games a single mask can often be used for many different Objects.

Now we’ll make the Sprites for a gate. The gate will take up three squares: a left ‘pole’ and a right ‘pole’ (which are just taller versions of the wall but in a different color), plus the archway piece between them (a block higher in the air that connects the two poles and will not need a mask since the ball can roll under it).

Create spr_gate_pole, the tall blue column. Like the block and its mask (which the pole will also use), the gate pole’s Origin point should be centered horizontally and 8 pixels up from the bottom vertically at X:16 and Y:56 as shown below:

[pic]

Duplicate spr_gate_pole to make spr_gate_arch. The only difference between these two Sprites is their name and image. You’ll notice that the artwork for this Sprite is just a blue block floating in the air. It will go between the two poles when we turn it into an Object and place it in the Room. It is important that the arch’s Origin point is still in the center of its shadow to make sure that it gets drawn at the correct Depth – you’ll see.

Finally, we need a finishing point, so create spr_finish using the good old checkered flag image. This Sprite will look better with Smooth edges turned on (checked). Set its Origin point so that it is centered horizontally (X:12) and, like the ball, 4 pixels up from the bottom vertically (Y:20) as shown below:

[pic]

That’s it for the Sprite and Background graphics. We will also make a victory sound that’s played when the maze is completed. Create snd_finish using all the default settings to complete our set of art and sound assets. Let’s make the game’s Objects now.

E. As we build the Objects for this isometric maze game, the key thing is to make sure that everything is drawn in Depth order to give it the proper 3D look. As in these previous tutorials, we’ll continue to set the depth of Objects to ‘-y’ so that they are drawn in the correct order on the screen.

Let’s start by creating the basic wall Object, obj_block. Check the Solid box (it is a wall after all) and define its Mask so that it is no longer but as mask_block. In other words, you’re telling Game Maker to use a mask for this Object’s collision detection, not its Sprite image as we have in every other tutorial game. In the wall’s Create Event, we Set the value of a variable for ‘depth’ to ‘-y’ as shown below:

[pic]

Then build the Object for the gate poles, obj_gate_pole. This Object is so similar to the wall that we’re setting obj_block as its Parent (in other words, it will follow all the same rules as its Parent, obj_block) as shown below:

[pic]

With the pole Object done, it is time to build the archway Object, obj_gate_arch. All of the default settings are fine: the archway is not Solid, needs no Parent, and requires no Mask since we want the ball to roll right under it without a collision. Its only Event is to make sure that it’s drawn properly. As with obj_block above, in its Create Event, we Set the value of a variable for ‘depth’ to ‘-y’ and that’s it.

Now we should build the finish flag Object, obj_finish to complete the set of Objects we need other than the avatar in this game (i.e., the ball). When we created the flag’s Sprite image (spr_finish), its Origin point was identical of that for ‘mask_ball,’ which is what you’ll be setting as the Mask for obj_finish. Also, like the other Objects being drawn in this game, in its Create Event, you need to Set the value of a variable for its ‘depth’ to ‘-y’ as shown below:

[pic]

F. Let’s have a ball by creating obj_ball, the player’s avatar in this game. As with the other tutorial games we’ve done in Game Maker, most of the game’s rules are written as Events and Actions for the avatar.

First, make sure that obj_ball is Solid and uses the Mask of ‘mask_ball’ (to make sure that Collision Events will work properly). Because the ball moves around, it is in a Step Event that we’ll Set the value of a variable for its ‘depth’ to ‘-y’ as shown below:

[pic]

And speaking of Collision Events, create one for obj_finish with the Actions shown below:

[pic]

Now we need the movement commands for the ball. Motion is a little weird in an isometric view game. First, because of the projection, horizontal motion should be twice as fast as vertical motion to maintain the 3D illusion – this is a lesson that we’ve learned in the above tutorials and it applies to isometric view games as well.

Second, when using the arrow keys to move the avatar, it is common in isometric games to let the arrows correspond to diagonal movement (along the sides of the tiles) rather than orthogonal (i.e., vertical and horizontal) movement along the corners of the tiles. Thus, when you press an arrow key, the ball moves a little bit in the correct diagonal direction, if the new position is collision free.

Here is how we achieve both of these in Game Maker:

Create a Keyboard Event to move the ball diagonally up and to the left. For the first action, we’ll ask the question If a position is collision free about the space that is 4 pixels to the left (‘x:-4’) and two pixels up (‘y:-2’) Relative to the ball’s current location, only looking out for solid objects, as shown below:

[pic]

By looking before we leap 4 pixels left and 2 up, we accomplish both of our goals. That is, we’re checking for diagonal movement (by moving in both the ‘x’ and ‘y’ directions, where orthogonal movement would be moving in one or the other direction) and we’re preparing to move twice as fast vertically (along the ‘x’ axis) than horizontally (along the ‘y’ axis). Pretty cool, huh?

Now all you need to do is the actual movement Action, which is Jump to a given location of ‘x:-4’ and ‘y:-2’ Relative to the current location, as shown below:

[pic]

Duplicate the Keyboard Event for the , and Keyboard Events, but change the ‘x’ and ‘y’ values for each as follows:

• To move up and to the right, use , the values are Relative to ‘x:4’ and ‘y:-2.’

• To move down and to the right, use , the values are Relative to ‘x:4’ and ‘y:2.’

• To move down and to the left, use , the values are Relative to ‘x:-4’ and ‘y:2.’

G. Making an Isometric View Room.

With all of the Object ready to be place in your room, you’re ready to lay out the parameters build it. Let’s start with the room parameters which are stet as as shown below:

[pic] [pic] [pic]

You’ll notice that the view is very small so that only part of the maze can be seen at a time. In this manner, the player has some exploring to do.

For placing Objects in the Room, set the grid size to Snap X:16 and Snap Y:8, then turn on the grid squares and change them to their isometric view.

[pic]

Note that it will be a lot easier to create your Room if you work from the top downward! If you make a mistake and end up putting one item ‘over’ another, there is a very useful button that is shown to the right. Pressing this button sorts all instances in the room by their y-coordinate value to insure that they’re drawn correctly to give your room a proper 3D look. While you’re building the room, I’m sure you’ll need this.

Another tip is to turn off the Delete underlying box in the bottom-left corner of the objects panel. Doing this will make it much easer to place new tiles where you want them without screwing up the tiles you already have ‘just right.’

You may also find it handy to ‘paint’ rows of block using the button + key combination. This will speed up the process of building the outer edge of your maze, for sure.

If you put an Object that’s not where you want it, or you just rather place an Object somewhere then move it exactly where you want it, use the button + key to drag it around the grid and drop it neatly into place.

Note that it’s okay to have your walls ‘overlap’ as you place them. They’ll still look fine and play properly. Just be sure to clean them up by using the Sort all instances by y-coordinate button.

H. A new feature: the ‘shiny’ ball.

Sometimes the ball can disappear behind objects in the maze and the player may want to know where, exactly, it is. We’re going to create a feature where the player can hold down the key and have the ball shine through whatever is obscuring it. Here’s how you do it:

Create a new Object called obj_shiny_ball. Use the Sprite spr_ball for its image and set the Depth to -10000 to make sure it’s drawn in front of everything in the game. Then establish a Creation Event where you Set the value of a variable for the variable ‘image_alpha’ to a value of ‘0.2’ as shown below. The image_alpha variable defines how much the figure of the shiny ball (which is bring drawn on top) will blend in with whatever object is obscuring it; by setting this to 0.2, you’ll see about 20% ball and 80% what’s obscuring it (which is enough to see where the ball is and gives the illusion of the obstruction becoming transparent so that the ball is visible). By adjusting this alpha value higher, you can see the ball more clearly and what’s obscuring less so.

[pic]

But where does this shiny ball get created? For that, we need a Step Event and place it wherever the ball Object happens to be (obj_ball.x and obj_ball.y) as shown below:

[pic]

Now go back and open up obj_ball and create a Key Press Event. The only Action is to Create an instance of an object for obj_shiny_ball using the default settings (this will place the shiny ball image directly over the regular ball image on the screen) as shown below:

[pic]

Now, since you don’t want that shiny ball on the screen forever, you must create a Key Release Event that will Destroy the instance of Object: obj_shiny_ball as shown below:

[pic]

H. More advanced isometric view games

An Isometric view is very well suited for many types of games. The hardest part, really, is creating (or finding) nice looking tiles (i.e., Sprites). Fortunately, there are many resources you can use to find isometric Sprite sets on the internet, including some art programs that help you. If you Google keywords such as “isometric tiles,” you will find some interesting stuff.

For the other 3D game styles you’ve learned in this tutorial, they really are easier than it might seem. The two things you must always keep in mind are setting the depth correctly and collision masks.

Here are a few more things to keep in mind as you make these 3D-looking games:

• When you cannot walk behind certain Objects (like mountains or woods), it is best to place them in the room as backgrounds.

• You can use invisible Objects to prevent moving Objects from entering that ‘space.’

• When an Object spans different tiles (e.g., the gate we created in the isometric view lesson), split it into several pieces to avoid problems with the depth.

• Another good trick is to put a Sprite’s Origin point at the center of its vertical projection. So, for example, a flying bird will have its vertical Origin point quite some distance below it. Note that it is not necessary to make the Sprite this long; the vertical Origin point’s center can lie outside of the Sprite itself.

VI. Concluding thought

After you’ve completed these this four-part tutorial lesson, you should be convinced that it is possible to make many different types of games using Game Maker and give them a clear 3D look. Like everything else with this programming too, the only limit is your imagination.

-----------------------

Age of Empires expansion pack; ‘old school’ 3D gaming

Hidden-surface removal;

what’s in front obscures what’s behind it.

That’s Deep

In Game Maker, Objects with a higher value Depth setting are “deeper” and, hence, drawn first (i.e., ‘behind’) Objects with a lower value Depth.

That’s why this setting is called Depth, not Height! You have to use programmer logic here, but higher values go deeper (and are drawn first), while lower values (such as negative numbers) go higher (and are dawn last)!

The asteroids in the rear are smaller; the one in the center is ‘closest’ and appears larger.

The ‘God’ View

The direct overhead view of a game is also known as the ‘God’ View.

The above illustration is a Perspective Projection.

Beep Beep

In this tutorial we will create a small example of a car driving sideways on a road. We’re not after graphic quality here (you can do that for your graded efforts). Right now, it’s just important that you understand this effect.

Prototype by Playing

Remember, you can press the green arrow and test this as you go along these tutorials to see how you’re doing!

Once you check the ‘Visible when room starts’ setting, the Background layer turns BOLD and is active.

The world view changed by 45 degrees in a parallel projection, ‘tilting’ squares so that they appear as rectangles.

Staying in Step

Setting the variable Depth to ‘-y’ for moving (i.e., ‘dynamic’) Objects (e.g., the avatar) has to be checked every Step. We’re using End Step Event for this to make sure that all other Events are processed before the Depth variable is determined.

Note that setting the variable Depth to ‘-y’ for non-moving (i.e., ‘static’) Objects (e.g., the trees), you need to do this only once in its Creation Event.

Collision Detection

All three of these Sprite settings have to do with collision detection. You’ll see why in just a few moments.

Subimage Speed

To get an animation of the Sprite while it is moving and no animation when it is not, we use the variable image_speed. This variable indicates the speed with which the subimages in the animation are shown.

Setting image_speed to 1 plays the animation at the normal speed. Setting it to 0 will stop the animation. Setting it at some fractional value between the two (e.g., 0.5) slows the image speed (when your animation is playing too fast).

So when the user presses an arrow key, we choose the correct Sprite and set its speed to 1. We use -1 for the subimage to avoid a change in subimage when the avatar was already moving in that same direction.

Collision Masks

For more complex shapes, a simple small rectangle at the bottom of its Sprite might not give us the correct collision area.

In that case we can use another feature of Game Maker by creating a Collision Mask.

That is, an Object can have a different mask than the Sprite used to represent the instance.

So we do is create a second (invisible) Sprite that has the shape of the collision areas we require and use that Sprite as Collision Mask.

We will use this technique in a moment when we create an isometric game.

When the avatar stands in front of a tree, the Sprites overlap but we don’t want a collision to occur.

We’ll be using this trick again in the next lesson: Scaling Images.

Information Panels for Cinematic Effect

In many games, this ‘wide screen’ effect is achieved by having an information panel below the scrolling world view. Thus, it is better to put the information panel for a parallel projection game alone the bottom of the screen then along the side.

At the top of the Room Properties form you will notice the magnifying glass icon. You should experiment with it as it can help you see the Room differently by adding and removing features so that they can be examined in isolation or combinations to suit.

Getting the room to look like it does here will take a little time and patience with the tiles. As you can see, however, the effect is terrific.

No Vertical

Note that the avatar cannot move up and down. That’s deliberate. It just moves left and right to dodge oncoming trees with the length of survival being the player’s score.

It is important to place the avatar in the Room at an appropriate depth to keep him at the correct position among the trees.

Note that the {brackets} define the beginning and end of a section of code.

A First Person Shooter

You can actually use this same mechanism to create a full-on First Person Shooter (FPS) game (which is the subject of an upcoming tutorial lesson, by the way).

In an FPS game, the player Object has a position and an orientation within the game world.

For all other Object instances in the game world, you must compute their position relative to the direction the player is looking and their distance from the player’s position.

The distance determines the drawing order and the size as we have just done in this tutorial.

(To avoid drawing too many instances in an FPS game, you normally only draw instances if they are close enough to ‘see.’)

Having said that, it is easier to use Game Maker’s 3D graphics functions found in the registered version.

Decoding this Movement Code

Controlling the movement of the trees is harder than it looks. We could let the trees move down the screen using a constant speed, but then they would appear to visually slow down – this is because closer Objects need to move faster than Objects that are far away to maintain our 3D illusion. So we must increase the tree’s vertical speed as it marches down the screen

(y += 0.2 + yoff * 0.02).

In addition, Objects move toward the sides as they get closer (because parallel lines meet in a point at infinity, as you learned in your perspective class). So, based on the position of the tree relative to the middle of the view (i.e., where the avatar is standing), we must also give it a bit of horizontal speed and nudge it slightly to the left or right (x += xoff * 0.015).

These numbers (0.015 and 0.02) have been created using the ‘anal extraction’ technique (i.e., they were pulled out of someone’s ass). You might want to experiment with them and tweak them a bit to improve the 3D illusion.

Color-iffic

This kind of code color-coding is common in most programming software packages, including the most common one used in the game industry: C++.

Doing the Math

What does (y-178) / 100 mean in these variables?

It means you take the tree’s Y-coordinate value (trees are ‘born’ on the Y: 180 row and move down the screen, thus increasing their y-value each Step), and subtract 178 from it. This will be an ever-increasing number until the tree disappears when its y-value exceeds 320.

Then you divide that difference by 100 to determine the current image_xscale or image_yscale percentage value. If you do the math, you’ll discover that the trees will be created at 0.02% of their Sprite size and leave the screen at 142% of their size.

You can play with this scale factor a bit; just make sure it’s always works out to be a positive value (you can’t have a negative percentage value).

Percentage Play

Remember, the value of ‘1’ here means 100%. Values less than 1 are a smaller percentage (e.g., 0.02 = 2%) and values greater than 1 are over 100% (e.g., 1.42 = 142%).

Transformation

Using the Transform the sprite Action is a better, more efficient alternative. It also performs a couple of useful graphic tricks: rotating (at an angle) and creating mirror-image Sprites.

This time the mountains are not scrolling!

Isometric

From the Greek prefix ‘iso’ meaning equal and ‘metric’ meaning measure. Thus, an isometric view uses lines of equal measure.

SimCity uses an isometric game view.

Creating Isometric Backgrounds

Creating background images using an isometric look can be done easily in Game Maker.

First, make a tiled background.

Next, edit the background thus:

• Enlarge the canvas,

• Rotate it by –45 degrees,

• Stretch (or actually shrink) it vertically to 50%.

Of course, you can always use a set of tiles that are already the correct size and orientation.

In the Room editor, you can also indicate that you’re using an isometric grid. This makes it relatively easy to put the game tiles in the Room at the correct places.

Above is a glimpse of what the 2D map on the right will look like when we complete our 3D isometric view of this Room. The ball above is what the player maneuvers through the maze; it is represented by the green square on our graph paper.

The diamond-shaped dashed brown line superimposed on our graph paper image approximates what part of it is in view in the isometric image above.

Open

Wall

Gate

Start

Finish

The Origin Point for Sprites & Shadows

It is always best to make the Origin point of the Sprite and its mask the center of the mask (i.e., the center of the Sprite’s shadow).

For example, below is an image of the Wall element we will use in our isometric maze tutorial game, along with its corresponding shadow / mask. Note that the cross-hairs on both are at the mask’s Origin point (i.e., its center).

[pic]

The mask in this case has exactly the size of one game board (i.e., Room) tile.

Collision detection based upon the shadows / masks of the Sprites works this way: The Sprites themselves are allowed to overlap, as long as their shadows do not. This is precisely what you want.

Thus, when the ball runs among the blocks, the Sprites can overlap to create our nice 3D illusion. But a collision occurs once the shadow / mask of the ball hits the shadow / mask of the wall.

•

This is the look and feel we’re after with the gate.

Stationary Objects Completed

That completes the stationary elements in our game.

You will note that each has its ‘depth’ variable defined as ‘-y’ in its Create Event; this helps ensure that they are drawn in the proper order (back to front) to give the correct 3D look.

Good Knight

Did you notice that ratio of 4:2 (which reduces down to 2:1) in terms of ‘x’ and ‘y’ movement? Think for a moment, what other gaming piece does that movement make you think of?

A Knight in Chess, of course! In an isometric game, the pieces move in the same ratio as a Knight in Chess.

The grid square and isometric view buttons.

The grid ‘snap’ coordinates.

Here you can see the shiny ball slightly ‘shining through’ the wall that obscures it. Setting a higher alpha value for the shiny ball make it more visible and the wall less so.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download