Welcome back! Did I tell you I love comments? Very few people write... Be original :)

This is the second chapter of the RPG game programming tutorials (click and drag inventory and action). Get the GM source code: right-click, save target as. If you just got here you should start there!

We’re going to go one step further into elaborating dynamic inventory management. So far, we were able to open a bag using an inventory icon and drag that bag around the room. Now that bag will include items you’ve found playing the game.

Of course this requires that it be possible to find items in the game, so that part is covered as well.

Part I: What is new – taking game programming into new perspectives.

Just like the first time, let’s start by running the game. Put the source code  in the same folder you put the first one, then double click on it to run it with GM. Run the game by clicking Run the game.

It starts just the same as it did before, but now when you click on space when you are near the table there is a reaction.

At this point, we are using GM’s built-in dialog boxes. We can make our own from scratch, or customize those somewhat. That will come in later tutorials. For now, we are programming game interaction using those.

This game interaction will lead to finding items that will automatically be added in the player’s inventory. In this case we find cookies and a watergun (hey, this is rated PG!)

Run through the options and when you’ve found the cookies and the gun, check your inventory.

You do this by clicking the bag icon on the right. This is what you see:

Click on the black top bar and hold the left mouse button down.  Move the mouse around and you see the panel, as well as the newly included objects, move accordingly. 

Click on the head or bag button again and the corresponding  panel disappears.

We are one step further into interactive inventory management. Let’s look in the game programming code and see how we got it to work.

Game Programming tutorial – Making RPG games chapter 2, part 2.

Before we look further into actual programming, it is very important that we dedicate just one small part to organizing your work.

As the game grows, things can quickly get messy. The scripts add up, as well as the other components when we get further into the game.

First we’ll see how you can organize. Then we’ll see how that organization needs to be based on the game loop.

Make games efficiently by organizing the components – game programming success depends on workflow!

To organize components efficiently, you’ll need to put them into folders, or groups. Some of these groups will also have sub-groups.

Let’s see how the scripts are organized.

Scripts are quite simply grouped by function. When something happens, the first to run is character_control(). It will check if there is something to do where the player is located because he pressed Space. If it determines there is nothing to do, it will run the nothing_to_do() script.

Other player actions will lead to other scripts. The inventory management scripts are located in the inventory folder. Scripts that react to game interaction in room0 in the game reactions by room group.

Taking the time to name groups and sprites with long, descriptive names is worth it. SnS has 164 scripts. As your game gets larger you can very easily waste a lot more time looking for the right script to work on than the time you dedicated to writing explicit names.

The same goes for all other components (sprites, sounds, backgrounds, paths, fonts, time lines, objects and even rooms if you have a large game world that can be cut up by geographic location. We will see that some rooms can be created for a whole other purpose than showing a part of your game world, and such rooms belong in a separate folder as well.

You might be able to get by without paying attention to this part for a small game, but game programming gets interesting, fun and profitable when you start making games large!

Game Programming tutorial – Making RPG games chapter 2, part 3.

Efficient game programming requires that you keep track of your game loop when you make games.

Keeping your game loop in mind is a good way to not get lost or have to spend hours figuring out where to add new code to get a new feature to work.

Our sample game’s game loop is already getting a bit complex. That can be intimidating, but it shouldn’t. If you keep good track of it, you’ll realize it is just a series of logical steps that slowly build up as your game develops.

Things that happen to the character (events such as draw, left key, up key…) cause actions (executing code, running scripts). The scripts and codes can start new events of their own by creating new objects (instance_create()) for example. Scripts can also call new scripts (if certain conditions are met by using an if statement, or without conditions at all).

The game loop restarts at each step. How long a step lasts depends on the room speed you choose in room settings. Default is 30 steps per second, which means a step lasts 1/30th of a second. In this game I changed it to 60 so that the cursor would stay on the topbar. I’ll change it back in a later tutorial though… There are other ways.

At each step the room is restarted. All possible events are either checked for (key events) or executed every time (step events, draw events).

Game programming events generated by existing objects.
Each object can potentially generate events, just by existing. The step event happens at every step, as well the draw event. Nothing special has to happen.

The main character object events.

main_ch is the name of the main character object. If you open its object properties, you’ll see four keyboard events, an O key event, a draw event and a space release event.

 If one of the arrow keys is pressed, this is an event that main_ch will respond to by carrying out the list of actions on the right. Arrow key actions for main_ch are execute a piece of code, which adjusts the direction the character is heading (global.heading), its coordinate (x or y depending on the key that is pressed) and checking if nothing is in the way:

(if instance_position(x-10,y,all)=noone x-=4
else if global.space_mess=0 global.space_mess=1;

This translates as: if no object (noone) of any type (all) is at instance position (my x coordiante-10, my y coordinate) or 10 pixels to my left, then my new x coordinate is x-4 (x-=4) so I will move 4 pixels to the left. Otherwise (else), if global.space_mess=0, then change that global variable (global means it will be recognized in other scripts maunched by other objects) becomes =1.

global.space_message is a variable that will be used to determine if a message is shown on the screen later in the loop. This prepares for that message to be shown, if another object is on its way to the left.

 The O key event starts a dialog box you can use to rename Hobo.

 main_ch is drawn. If space_message=1, it shows a message informing the player that the space key will show what options he has at any given point in the game if he is facing something.

The sprite associated to the object is drawn, in conformity with the global.heading value.

Takes the x and y “local” values and copies them into global values that can be used anywhere (global.posx and y).

Runs the script character_options() if a variable value is equal to 1.

 Space is released. This changes a variable that will be used in the next main_ch object’s draw event. The variable changes if there is anything in one of the four directions, 10 pixels away. If not, it “sleeps” for 1/1000th of a second for each direction and then runs nothing_to_do(), another script that says there is nothing to do.

Now let’s move on to another object.

Game Programming tutorial – Making RPG games chapter 2, part 4.

Making games in GML: object oriented game programming.

Many objects besides the main character will make up a game. In this sample, there are the inactive objects that will be detected by the main character. There is the table, which, recognized as such, will cause specific reactions (see previous part). The doors will soon act appropriately using the same method. You previously read that the main character reacts to key prompts (arrow keys for movement and heading, O for renaming, space to see available options)

You can imagine countless options such as other characters to talk to, monsters to shoot, closets to explore, doors or windows to open…

There are the interface objects that react to mouse clicks or hovering (NoButton). Those are the character and inventory objects on the right (they react by creating or destroying the corresponding panels, as well as the objects they contain, by running the open and close inventory scripts), the two topbars and the squares.

And then there are item objects that are created when the right variables are set at the right values (the topbars are as well), and stored in their own inventory slots when they are picked up. That’s all they do for now, but they will soon react to mouse events as well.

Objects are the core of your game. They make the game loop continue. When all object events have caused the assigned actions, the next step begins and the loop is restarted, ready to react to new events by running new actions.

Making scripts run in your game.

We saw that the space key causes a check for close objects, and a variable change if it finds something. This is done by using the if statement and instance_position(). Once that variable is changed, you get reactions by making sure that variable is checked at each step. You do that by assigning that verification in an action (a script or execute a piece of code). This action results from an event that happens at every step. Draw is one of them, and it is the one you must use if what happens next involves drawing text or images. If it is just variable value updates, the Step event will work fine. If you aren’t sure yet, then just use the draw event to be sure.

In the main character draw event, if global.checking_character_options=1 character_options(); launches the script character_options because Space was pressed, causing the if condition here to be true.

Other variables determine if, ultimately, the gun and cookies end up in your inventory, and where. global.just_taken=10; in get_cookies() is a variable used to determine which object was just taken (item 10 is the cookies). This is used in the inventory scripts. First, add_to_inv() will determine what slot it will go in (the first available). Then when the inventory is open, open_inventory() draws the cookies inventory objects at the same coordinates as the square it was assigned to. Since the cookie’s inventory object has a lower depth than the inventory square, it appears on top, giving the illusion that it is inside it.

Arrays are used to do this quickly. This allows you to update values using single or double “for” loops. Take a look at the open_inventory() script in the inventory folder. You’ll see this is extremely useful (you can’t make a decent game without it!)

Most Important Articles So Far

Underworld     Reverse Insulin Resistance     Personal Project Management Freeware
Free Weight Loss Plan     Be More Creative... Play!
Finding Your Passion

There are many more! Better health, creativity, productivity, lifestyle and... games!

Strength | Creativity | Productivity | Lifestyle | Games


First time here? Read about the free software, tools and content that will make you stronger, more creative and more productive on the 2-0 home page!

Let's connect!

Oh, and if you enjoyed this page, please share it using your favorite service below. Just about every option made easy!