Create an original RPG game: Chapter 1, part 4.

 

You should start here to have a good idea what this is about, and do things in order!

 

Game programming – click and drag inventory and action components!

 

This is what stands out at this point.  Having control panels that can be dragged around the screen.

 

 

 

These are made up of two main elements:  the topbar (black) and the brown surface that “follows” the topbar wherever it goes.  Then there are the squares, or item slots.  There is something very particular about these that we will discuss a bit later.

 

Creating and destroying the panels.

 

The first step is creating the panel.  This happens when the left mouse button released event occurs for the adequate object (either the blue button for the character panel or the bag button for the inventory panel).  Left mouse released doesn’t happen when the player clicks, it happens when he releases the button.  Almost the same but not quite.

 

 

 

The code starts by checking if the topbar exists already.  If it doesn’t, the if condition is met so it reads variable values, which will be used to define where the topbar is located. tbx is topbar x coordinate, tby is topbar y coordinate.

 

Then it will assign the location for the brown inventory box (just below it) and the item slot squares.

 

Then it will create the two, and since they are always a fixed distance from each other, when the topbar is clicked and dragged, the brown box follows.

 

But we still have to make the topbar react to clicking and dragging. 

 

This is done in a very similar way, by using the No button mouse event on the topbar object, which is triggered when the mouse runs over the topbar without clicking.  When this is active, it calculates the x and y distance between the mouse cursor and the top-left pixel of the topbar.

 

These variables are recalculated at every step (1/60th of a second according to Room Properties.)

 

When the mouse is clicked on the Topbar (Left Button mouse event), the variables stop changing and can be used to determine where the topbar is located at every step.

 

And the inventory box called equiped follows, as well as the squares.

 

A bit more detail about the code:

 

When the mouse is over the topbar and no button is pressed, this generates the “no button” event.   What happens then is a constant recalculation of the distance between the mouse and the topbar’s “origin”.

 

Note that the origin can be set in the sprite’s settings.  It can be the center of the topbar, or the top left corner (x=0 and y=0) or any coordinate you choose.  This doesn’t matter much, as long as it is the same for all the objects involved.

 

This is how the distance between the mouse and the origin are calculated at each step:

 

    global.tb_correct_x=mouse_x-x;

    global.tb_correct_y=mouse_y-y;

 

tb_correct_x stands for topbar correct x (for the x coordinate).  That’s a variable name I chose.  Always be explicit with variables so that you can recognize their function when debugging, or reviewing your code for whatever reason.

 

mouse_x is the built-in variable for the mouse’s x coordinate.

 

x is the topbar’s built-in x coordinate.  Note that it doesn’t need to be global since it is only used for the current object (topbar).

 

global.tb_correct_x and global.tb_correct_y are respectively the horizontal and vertical distance between the topbar’s top left corner (origin) and where the mouse is during that step.  Those are global variables because I will use them later to determine where the topbar needs to be at each step.

 

When the left button is pressed over the topbar, this generates the Left Button mouse event for the topbar.  The following code is then applied:

 

x=mouse_x-global.tb_correct_x;

y=mouse_y-global.tb_correct_y;

 

 x and y stay at a constant distance from the mouse because since the no button event is no longer occurring, the recalculations aren’t happening.  This means that global.tb_correct_x and global.tb_correct_y aren’t changing.

 

When you move the mouse, the topbar just “follows” as long as you keep the left button down.

 

 global.equiped_x=x+global.equiped_correct_x;

global.equiped_y=y+global.equiped_correct_y;

 

 This keeps the brown square at equal distance between the topbar’s origin (x and y), which means it “follows” as well.

 

 global.square100_x=x+global.square100_correct_x;

global.square100_y=y+global.square100_correct_y;

 

This keeps the item slot square at equal distance between the topbar’s origin (x and y), which means it “follows” as well.  This is included in each square’s step event (recalculates position at each step).

 

The same can be done for any other object.  More item slot squares of course, but also any number of tabs, buttons (…).

 

Frequent problem.

 

If you look at the room settings you’ll see I changed the room speed (default = 30, I set it to 60).  If it is too slow, the mouse keeps popping out of the topbar space because your mouse runs at system speed (much faster).

 

Changing the speed, however, also speeds up all the objects in the game.  Your character walks faster for instance.  Setting it too high would make the click and drag work better but you’d need to slow down the game with a sleep() command at each step.

 

Room speed being 60 means 60 steps occur per second instead of 30. There are better ways to fix this but I’ll leave it at that for now.

 

Back to Game Programming 

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

 

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.

 

 Back to Game Programming.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

 

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!

 

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.

 

Back to Game Programming.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.