Gw Temp


Tutorial - 'Making the Jump to Game Maker: Chapter III' by Kuro

An item about Gamemaker posted on


The final, and latest article on getting into the know how of Game maker!


Making the Jump to Game Maker: Chapter III

First thing. If you haven't downloaded Game Maker 5 yet, do it now. This program, in every way conceivable, can make any type of game, from

platform, to racing, to fighting, even rpgs. Even though, you could do all of that stuff with GM4, GM5 just makes it easier, with the

addition of Time Lines and Health Bars.

After spending some time with GM5, I've thought about how I should explain the creation of a Game. I'm going to do this article different

from my others by explaining the uses of GM's features. I suggest you download my premade program so you won't have to struggle with your

own. Click here to download it NOTE: You won't learn GML coding (or not a

lot) so read the Help file packaged with the Game. This is mainly to get your brain started on really using GM.

Slap your monitors and readjust your calibration, here we go!

Lesson... what are we up to now??? 8?: Health Bars Parameters

The newest (and second best) feature to be implemented in GM5 is preprogrammed health bars. In other versions of GM, it was up to the

creator of the game to program his own bars (it was kind of... hard) but now all lazy people can rejoice!

To implement a health bar, three (actually two) things must be assured before you'll see anything on screen.

1. The code for drawing the bars must be in the draw event of any object.
2. The x and y coordinates must be set within the screen limits (negative numbers don't work in most cases).
3. The health value must be updated every draw event.*

The third item is not necessarily true, but I'll get to that later.

Now on to the use of health bars. There is a catch to the health bar. While you can make it any size you want (x and y), you are restrained

to making the value of the bar between 0 and 100.

"But I want my character to have over 100 HP/MP!"

Yes there is a way. Think of the range (0-100) as a percent. (heck, that's what it is!) So if you wanted to display "Alex's" HP, simply


alex.hpBar = (alex.hp / alex.maxhp) * 100

Dividing alex.hp into alex.maxhp will give you a percent of what alex.hp is to alex.maxhp! And you thought math was just nap time?!

Lesson 8.5: How to use a health bar

Even though it clearly explains how to do this in the help file, I'll tell you so its easier to understand. For non-coders, open up your

game (or if you don't have one, download the one at the top) and scroll down to the object "Alex". Take a look at his events.

NOTE: when drawing health bars, realize how large the screen will be when you draw it. Also, know that the bars will only flow horizontally,

as far as I know.

Go ahead and see how the dialog box looks when you choose those actions. Everything should be simple enough for anybody to understand.

x1,y1,x2, and y2 are the points for the rectangle (praying you know how to do this).

"Hey, is it possible to draw two health bars, say one for magic power"

Of course! You can add as many as you want because GM is only drawing the health bars, not putting anything but variables and arrays in

memory. So just add the code again in the draw event (copy and paste time) and modify the code to work with whatever variables you're using.

But don't overload one object with too many health bars! Remember to try and keep things simple and organized.

* For certain events, you may not want to update the health bar. Adding an 'if' statement should do the trick.

Lesson 8+1: Choosing Sprite Sizes

This took me a long time to understand. While GM provides all those little spiffy icons to speed up dev time, no icon will ever surpass

GML-coding. Its like javascript and php, rolled into one. And its great because those icons can get messy when building a big object. So

the purpose of this lesson is to show how sprites can be so easily manipulated with little effort.

I'll start by explaining how you should build your sprites. Right now, dump all knowledge of my previous tutorials, except how to import

sprites using "Create from strip" and "Add from strip". The easiest way to understand how sprites are done is by thinking in terms of poses.

Each sprite has some kind of pose. Whether it be walking, running, smiling, laughing, sleeping, killing, slashing, or eating, its considered

a pose. Each pose has some length to it. Walking poses in Rm2k were technically 3 frames, but the program was built to loop back to the

middle sprite frame every other frame. Plus it was limited to 24x32 sprites sizes. But GM is different. You can define your sprite size

when you create it, and it can be just about anything. The best sizes to use are as follows (this is my opinion and I could be wrong with

some but whatever)

- 16x16px (small, 20x15 tiles)
- 24x32px (regular character size)
- 64x64px (large, 5x3.75 tiles "Not used very often, unless scrolling")

- 32x32px (small, 20x15 tiles "Good for small items")
- 64x64px (regular 10x7.5 tiles "Great for scrolling")
- 72x96px (regular character size, "My Standard character size")
- 128x128px (large tiles, "Nice for special effects")
- 256x256px (large, 2.5x1.875 tiles "Stay away from this")

- 80x60px (small, 10x10 tiles "Nice, but bad resolution")
- 64x64px (large, 12.5x9.375 tiles "Stay away from this")
- 128x128px (characters)

As you can see, 640x480 has the best options available, but not always the best. Anything higher than 800x600 screens are pretty uselsess,

as most users' computers can't handle it. (unless you use views) Anyway, the demo file runs at 640x480 with 72x96 sprites.

Lesson 10: Organization Skills

Now on to the real stuff. (Hope I didn't lose ya back there) There are two ways to organize your animations. One way is to give each

sprite its own file (like the Alex-RunRight animation would have its own sprite file under the sprite folder). This is the way I suggest,

because its easy, but for big games, it can get a bit messy if it isn't organized properly. The second way is to put all the animations for

one character into a single sprite. This way is much harder, and can lead into some problems concerning special poses that are too big for

the dimensions of the sprite file. (ex: you have sprites of 64x64 and along comes a special sprite that's 72x96) But this method pays off

in respects that it will drastically lower the amount of sprites you'll have in the GM sprite folder.

Lesson 11: The Final Lesson

Game Maker is a very versatile program, but explaining all of it is best left for other people. I tried to stay on topic the entire time,

but its quite hard to explain. To wrap it all up, I'll explain the idea behind the ABS system.

To start, you need to sketch out a few things.
- How many players?
- How many characters fighting
- What's the unique thing that sets your Battle System apart*
- Entirely, does your Battle System flow with your game?

Ask yourself these questions first, then when you have them answered read below

- How many players -
Generally, these games should be one player. ABS's are fun with two, but unless you have experience with GM, don't bother.

- How many characters fighting -
This is where GM gets fun. Essentialy, when making a Battle System, most code is used over and over. AI for computer players is simple

(find tutorials on the internet, it isn't hard) and can be copied and modified for certain characters (fighters run in to attack, while mages

sit back and cast spells)

* What's the unique thing that sets your Battle System apart *

If there's nothing to hook a player in to playing your game, what's the real point? Find something new to explore, and don't overuse cliche

things like 'using AP to buy skills' and stuff like that.

- Does your Battle System flow with your game? -

ABS's arent for all games. What would've happened if they made Chrono Chross an ABS... Wait, that's a bad example.
What about Final Fantasy Tactics? Obviously not! If your game is a war-type game, don't make it an ABS, make it a RTS! Find what flows

best then execute.

# Epilogue #

This is the end of this series of tutorials. I know this didn't explain much other than what you probably already know, but it is essential

to develop a thought process other than 'ok, ill name this event "groundhog" and set it to AutoStart"'. If you're looking for an actual

tutorial on how to make a Battle System, you'll have to wait for the next series of tutorials:

Battle Systems 101

Peace Outside!