#gamemakerscript

Should work in GameMaker:Studio 2 (all versions).

This tutorial is written for GameMaker:Studio 2.

Problem

Oftentimes we want to be able to check multiple optional keys to perform an action. This might be to control a character both with WASD and with the arrow keys, or maybe to allow pausing on both the P key and the Pause key. I see a lot of people handling it like this:

if (keyboard_check(vk_left) || keyboard_check(ord("A"))) { // Do something }

This is of course fine in many cases, but it can turn into some very long conditionals sometimes. Also, if we want to change the controls at some point (or want to allow the player to do so), it becomes quite an inconvenience.

Solution

In GameMaker:Studio 2 you can define arrays like this:

var _array = ["index0", "index2", "etc."];

It is an easy way to pack multiple values into a variable. This does of course not help us directly, as keyboard_check(); does not accept arrays as their argument, but what if we make our own script? A keyboard_check_ext(); script? This would allow us to do something like this instead:

var _left = [vk_left, ord("A")]; if (keyboard_check_ext(_left)) { // Do something } // OR if (keyboard_check_ext([vk_left, ord("A")])) { // Do something }

Would that not be nice? We can even use a global or instance level variable to hold the mapped keys, changing them whenever we want to. But how would such script look?

First and foremost, we want to be able to use the script with singular input as well, so we start off the script by checking if our argument is an array, and if it is not, then we simple do a regular keyboard_check();.

var _array = argument0; if (!is_array(_array)) { return keyboard_check(_array); }

This also allows us to do a Ctrl + Shift + F in our project, and replace all uses of keyboard_check(); with our new script, without anything breaking.

Next we get the length of the array and loop though it. For each element in the array we do a keyboard_check();, and if it returns true, then the loop ends there due to our return. After the loop we make sure to return 0, to let the user know that none of the keys are being pressed. A full script would look something like this:

/// keyboard_check_ext(array_with_keys); /// @desc Is one of multiple keys held down? /// @arg array_with_keys var _array = argument0; if (!is_array(_array)) { return keyboard_check(_array); } var _length = array_length_1d(_array); for(var i=0; i<_length; i++){ if (keyboard_check(_array[i])) { return 1; } } return 0;

Of course the exact same thing can be used for keyboard_check_pressed();, keyboard_check_released();, keyboard_check_direct();, mouse_check_button_pressed();, etc., simply by replacing the function used in the script.

I hope this script and tutorial helped you making even more awesome games, and please share it, if you know someone who could learn something from it.

Should work in GameMaker:Studio (version 1.1.1013 or newer). Should work in GameMaker:Studio 2 (all versions).

This tutorial is written for both GameMaker:Studio and GameMaker:Studio 2.

Problem

Sometimes you want to do a place_meeting(); test for multiple objects. Sometimes a parent object can help you do this, but other times you may want more control over, which objects or instances you are testing against. It is the latter, I wish to offer a solution for.

In this tutorial I will focus on the place_meeting(); function, but the concept is applicable to every single, other collision function out there.

Solution

First part of the solution is how we best compile a list of various objects. Here I suggest an array, since these are easy to overwrite and clean up. "But wait!" I hear you say. "place_meeting(); does not accept an array as an argument!?"

Should work in GameMaker:Studio (all versions). Should work in GameMaker:Studio 2 (all versions).

These scripts are written for both GameMaker:Studio and GameMaker:Studio 2.

Introduction

Something I use often when making games are timers and countdowns. Sometimes it is enough to do a simple my_timer++; in the Step event, but sometimes I need more precision. It is for those times I have made the following scripts for easily making timers and countdowns!

The timers and countdowns are initiated like so;

my_timer = timer_create(); my_countdown = countdown_create(10000);

They both function similarly, and are based around milliseconds. Only difference: Timers count up and countdowns count... down.

To update a timer or coundown, which you normally would do once every step, you simply use timer_update(my_timer); or countdown_update(my_countdown);, and to get the current time of the timer or countdown you use timer_get(my_timer); or countdown_get(my_countdown);. This will return how much time has passed for the timers, or how much time is left for the countdowns, both in milliseconds. Divide this with 1000 to get the value in seconds.

A.K.A. my time implementing delta timing in Tale of Omni.

The Starting Point

After about half a year of development on Tale of Omni, I thought it was about time to think about adding some delta timing. Best thing would have been to make delta timing part of the project from the very beginning, but at least the game had not yet grown to a size, where the addition would be completely unfathomable.

Delta timing, for those unfamiliar with it, is a term used about the time between program iterations (or “steps”), and GameMaker: Studio has a handy, built-in variable delta_time to get this timing in microseconds. When I say, that I wanted to “add it to my game”, I am referring to the usage of delta timing: Making lag less visible.

Normally, when a game encounters lag, the game will continue as-it-was, and the lag will be very noticeable, and planning your movement can become quite hard. To make up for this, you can use delta timing to calculate how far you should have moved in the given time span. If the current step was twice as slow as it should have been, then you need to move everything twice as far!

The Solution

The first part of the solution, is one I think most people ready for delta timing can think up: Changing the delta_time value to a scalar. My game was up until this point made to run at 60 fps, so all my values was made for this speed, and this was the factor I needed to measure against. Fps stands for “frames per second”, and there goes a million microseconds to a second, so first things first I simply had to figure out, how many microseconds an ordinary step at 60 fps should take:

var __rd = 1000000/60;

Now, dividing the time since the last step (delta_time) with this value will then give us our scalar:

DELTA = delta_time/__rd;

This needs to be recalculated once per step! (I do it in the begin step event)

The simplest part is now done. We can multiply speed, image speed, and a lot of other values with this variable (better make it global), but you will quickly run into trouble when you begin multiplying it with gravity, friction, or other accelatory values. I know I did.

Thing is, these types of values affects OTHER values, and not linearly. Let’s say we jump by setting our vertical speed (vspd) to -10, and that we have a gravity (g) of 1. We add one to our speed, then moves, then add one, then move, then add one, then moves... You get the idea. This might look linear, since we add one each step, but the amount we move will be altered each step exponentially! Take a look at this for proof:

Step 0: We move up 10. Total moved: 10. Applies gravity. Step 1: We move up 9. Total moved: 19. Applies gravity. Step 2: We move up 8. Total moved: 27. Applies gravity. Step 3: We move up 7. Total moved: 34. Applies gravity. Step 4: We move up 6. Total moved: 40. Applies gravity. Step 5: We move up 5. Total moved: 45. Applies gravity. Step 6: We move up 4. Total moved: 49. Applies gravity.

If we just multiply both speed and gravity with the DELTA scalar (and the scalar is 4), then we should have a speed of 40, and a gravity of 4. Subtracting the gravity from the speed then gives us a movement of 36 - but wait, if done step-by-step this should be 34 (step 3 is the fourth step)?

At step 1 the gravity (applied after the previous step) has affected the speed by 1. At step 2 the gravity has affected the speed by 3, not 2. At step 3 the gravity has affected the speed by 6, not 3. At step 4 the gravity has affected the speed by 10, not 4. And so it goes on...

So. When we work with accelerations we need a different multiplier, though this multiplier should still be dependent on the DELTA variable!

After doing some math

(I could not get any solutions from around the web to work, so I had to do it myself), I came up with this:

DELTA_ACC = (.5*DELTA*(DELTA+1));

These two scalars ended up being all I needed for my game’s physics! When I add acceleration, I multiply the acceleration with DELTA_ACC, and for other things I multiply with DELTA - simple as that!

..though.. I then found I needed more. I use the lerp() function a lot, and none of these multipliers worked for that. Luckily, that one didn’t take too long, and I came up with this script:

///lerp_dt(amt); return 1-power(1-argument0,DELTA);

Where I normally would write lerp(x,100,.1), now I would simply write lerp(x,100,lerp_dt(.1)) to add the proper amount of lerping.

The End

So far, I have not needed anything else for implementing delta timing, than these three bits of code, and so far it works beautifully! I have tried to keep this post close to the bone, but if you have any questions, feel free to ask!

Hope you enjoyed the read.

Some quick notions:

Spine animations’ image speed is not depending on the room speed (so they need special care)!

Be careful with just subtracting DELTA from alarms - make a script to do this, which runs the alarm’s code if it goes below 1.

In lue of Star Wars: The Force Awakens, I made a script for GameMaker: Studio, allowing you to draw very customizable lasers like those seen in the Star Wars universer. Now I have written this small, explanation post about it. The script is used like this:

sw_laser(x1,y1,x2,y2,w1,w2,c1,c2,a1,a2,a3);

And could look something like this:

You draw the laser as a line going from (x1,y1) to (x2,y2). You then select a inner width (w1) of the normally white, opaque part of the laser. You can, however, change the color of the core (c1) and the opacity (a1) should you like it. Then you set the width of the glow (w2), the color of it (c2), the alpha where the core and the glow meets (a2), and the alpha at the end of the glow (a3). A regular, blue laser could thus look something like this:

sw_laser(x,y,x,y-100,16,8,c_white,c_blue,1,1,0);

The fully drawn laser will in this case be vertically straight, with a length of 100+16+8+8 = 132 from end of glow to end of glow, and a width of 16+8+8 = 32. You see, the core width is the full width of the core, but the glow width is existing on both sides of the core, thus you need to count it twice. 

First thing that happens in the script, is simply assigning the arguments to variables, and making a couple of our own:

var _x1, _y1, _x2, _y2, _w1, _w2, _c1, _c2, _c3, _a1, _a2, _a3, _s, _amt; _x1 = argument0; _y1 = argument1; _x2 = argument2; _y2 = argument3; _w1 = argument4; _w2 = argument5; _c1 = argument6; _c3 = argument7; _c2 = merge_color(_c1,_c3,.1); _a1 = argument8; _a2 = argument9; _a3 = argument10; _dir = point_direction(_x1,_y1,_x2,_y2); _s = max(1,ceil((_w1+_w2*2)/16)); _amt = 90/_s;

As you can see, we make a third color, which is a slight mix of our two other colors. We do this simply so that the core is not completely white all the way through, which is a personal preference of mine. Secondly we make the variable _dir, which is the direction of the laser beam going from (x1,y1) to (x2,y2). Thirdly _s and _amt is simply to calculate how smoothly we need to draw the laser, depending on the size of it - the bigger it is, the more points we need to draw to make it smooth-looking.

Then, using primitive-drawing and a series of for-loops, we first draw the core of the laser:

//Inner draw_primitive_begin(pr_trianglestrip); { for(var i=0;i<=_s;i++){  draw_vertex_color(_x1+lengthdir_x(_w1/2,_dir+180+i*_amt),_y1+lengthdir_y(_w1/2,_dir+180+i*_amt),_c2,_a2);  draw_vertex_color(_x1,_y1,_c1,_a1); } for(var i=0;i<=_s;i++){  draw_vertex_color(_x2+lengthdir_x(_w1/2,_dir-90+i*_amt),_y2+lengthdir_y(_w1/2,_dir-90+i*_amt),_c2,_a2);  draw_vertex_color(_x2,_y2,_c1,_a1); } for(var i=0;i<=_s;i++){  draw_vertex_color(_x2+lengthdir_x(_w1/2,_dir+i*_amt),_y2+lengthdir_y(_w1/2,_dir+i*_amt),_c2,_a2);  draw_vertex_color(_x2,_y2,_c1,_a1); } for(var i=0;i<=_s;i++){  draw_vertex_color(_x1+lengthdir_x(_w1/2,_dir+180-90+i*_amt),_y1+lengthdir_y(_w1/2,_dir+180-90+i*_amt),_c2,_a2);  draw_vertex_color(_x1,_y1,_c1,_a1); } //End draw_primitive_end(); }

The four loops are the four “corners” of the laser.

Afterwards we draw the laser’s glow. This is done in the same manor - look how our mixed color _c2 is used as the meeting point of the core and the glow.

//Out draw_primitive_begin(pr_trianglestrip); { for(var i=0;i<=_s;i++){  draw_vertex_color(_x1+lengthdir_x(_w1/2+_w2,_dir+180+i*_amt),_y1+lengthdir_y(_w1/2+_w2,_dir+180+i*_amt),_c3,_a3);  draw_vertex_color(_x1+lengthdir_x(_w1/2,_dir+180+i*_amt),_y1+lengthdir_y(_w1/2,_dir+180+i*_amt),_c2,_a2); } for(var i=0;i<=_s;i++){  draw_vertex_color(_x2+lengthdir_x(_w1/2+_w2,_dir-90+i*_amt),_y2+lengthdir_y(_w1/2+_w2,_dir-90+i*_amt),_c3,_a3);  draw_vertex_color(_x2+lengthdir_x(_w1/2,_dir-90+i*_amt),_y2+lengthdir_y(_w1/2,_dir-90+i*_amt),_c2,_a2); } for(var i=0;i<=_s;i++){  draw_vertex_color(_x2+lengthdir_x(_w1/2+_w2,_dir+i*_amt),_y2+lengthdir_y(_w1/2+_w2,_dir+i*_amt),_c3,_a3);  draw_vertex_color(_x2+lengthdir_x(_w1/2,_dir+i*_amt),_y2+lengthdir_y(_w1/2,_dir+i*_amt),_c2,_a2); } for(var i=0;i<=_s;i++){  draw_vertex_color(_x1+lengthdir_x(_w1/2+_w2,_dir+180-90+i*_amt),_y1+lengthdir_y(_w1/2+_w2,_dir+180-90+i*_amt),_c3,_a3);  draw_vertex_color(_x1+lengthdir_x(_w1/2,_dir+180-90+i*_amt),_y1+lengthdir_y(_w1/2,_dir+180-90+i*_amt),_c2,_a2); }

//End draw_primitive_end(); }

And that makes the whole laser! Hope you find the script useful, and that you are learning something from it. Feel free to tweet me how and where you are using it at @blesshaygaming

So, I just made a new script for GameMaker: Studio:

lines_intersect(x1,y1,x2,y2,x3,y3,x4,y4);

It is something I have wanted to do for a long while, but I had a hard time figuring out the math - after digging up the ol’ trigonometry everything fell into place though.

The x1, y1, x2 and y2 arguments are the two points of the primary line, and x3, y3, x4 and y4 of the secondary line. The script will return -1 if there is no intersection between the lines, or a value between 0 or 1 if there is an intersection. This value is telling where the intersection point is on the primary line, if you do something like this:

intersection_x = lerp(primary_line_x1,primary_line_x2,the_returned_value); intersection_y = lerp(primary_line_y1,primary_line_y2,the_returned_value); 

The first part of the script, is simply initializing the variables, and finding the directions from the two lines’ starting points toward both their own end points and the other lines end points.

var _x1 = argument0, //Line 1, point 1    _y1 = argument1,    _x2 = argument2, //Point 2    _y2 = argument3,    _x3 = argument4, //Line 2, point 1    _y3 = argument5,    _x4 = argument6, //Point 2    _y4 = argument7;

var _dir1 = point_direction(_x1,_y1,_x2,_y2), //From line 1, point 1    _dir2 = point_direction(_x1,_y1,_x3,_y3),    _dir3 = point_direction(_x1,_y1,_x4,_y4),    _dir4 = point_direction(_x3,_y3,_x4,_y4), //From line 2, point 1    _dir5 = point_direction(_x3,_y3,_x1,_y1),    _dir6 = point_direction(_x3,_y3,_x2,_y2);

Then we can do our first test: if the secondary line’s end points are on the same side of the primary line (like, both end points are on the left of it, relative to the primary line’s direction), a collision is not possible.