Menu

Recent Posts

Archives

Category: GML snippets

As mentioned in a previous post, Level 4 of the GPC was not a lesson, but rather a series of challenges meant to reinforce what was taught in Level’s 2 and 3. This time, I elected to create a new game rather than modify an existing one.

I settled on a top down shooter/adventure game and added features and flourishes as I went along. I used my earlier conceived true grid movement code, but this time, I used a switch statement instead of a series of if statements (or at least fewer of them):

That was my first time using the collision_line, which I don’t think is covered at all in the GPC, though it might be included in his how-to’s somewhere…I came across it after watching a tutorial video by “GM Wolf” on YouTube:

This would have solved a lot of issues for me…for instance, in a previous project, I had an idea to create a trap comprised of two moving blocks which collided into and bounced off of each other. While everything worked fine, it would occasionally cause the block to get stuck in a wall. This happened because it’s movement caused it to overlap before it detected the collision, thereby getting stuck inside the wall, unable to go anywhere.

I solved this before using the place_meeting function, but was never introduced to the End Step Event, which would have been the right way to do it. Nevertheless, I can think of other uses for collision_line and am glad I learned of it!

All in all, I spent about 2 days (most of the weekend) working on this little mini-game, and here are some of the features I included:

Destructible walls that advance in damage by manipulating the image_index

Enemies that can navigate mazes (using John Janeka’s code from Level 12)

Line of Sight for enemies with projectiles

Health, ammunition and keys global variables that persistent between rooms

Lock and key mechanism

A switch that reveals the exit when touched

Randomized muzzle flare and smoke when firing bullets

Randomized impact splatters when an enemy is hit

Different sounds for each impact

Randomized health power up sprites to add variety using a single object

Exits that allow you to advance to the next room

Capped health at 100%

What I not did include were:

Fail condition/game over when you run out of hitpoints

Start screen

Game Over screen

All in all, it’s a neat little game though unfinished, and good practice for more serious projects to come!

Shortcuts…

With my files recovered, I’m free to concentrate on getting back to my second run through the GPC. I’m back to Level 3, and bits and pieces of the GML syntax are coming back to me.

For instance, when calculating variables, the course suggests something like this:

hitpoints = hitpoints + 1

This works of course, but he also suggests that hitpoints = +1 does not work, which is true, however, if you reverse that (e.g. hitpoints +=1), it does the same thing with fewer characters to type. A small, but useful time saver.

###

A Hamburger That Fires Bananas (Improved)

In GPC 3-03-A, he introduces a function that randomizes an integer:

irandom_range(0,100)

This allows you use a random number generator (RNG) to decide the outcome of a particular variable within a specified range (i.e. 0 to 100 in the code above). This is used to manipulate the direction that a hamburger fires bananas, and the speed at which they are fired.

I took this a step further by adding the following step event (pun very much intended) to obj_banana:

image_angle+=speed*10

This (in my most humble opinion) makes the bananas far more interesting/exciting to watch as it causes them to spin through the air at a speed consistent with their velocity – i.e. a fast traveling banana rotates faster than a slower moving banana.

Try it yourself!

Aside:I couldn’t help but giggle at the silliness of this lesson – you wouldn’t think a burger that shoots bananas would be so amusing but you’d be wrong! Very entertaining stuff 🙂

Switching Things Up

In Level 3, “Challenge 2 – Random Generation,” the student is required to write a series of if statements to randomly move the player character in one of 4 orthogonal directions.

In my first time around, I recall touching on Switch statements, which can be a good way to handle this very scenario. Here’s how that would look:

This seems like a far more efficient and cleaner way to handle multiple (more than 3+) consecutive if statements, but is cheating at this stage as Switch isn’t covered in the GPC until much, much later*…

So why mention it now? Because I want to get in the habit of making my code clean and efficient.

And with that, on to Level 4!

*I can’t quite recall exactly where this was introduced, but I seem to recall where that was… For all I know, it may not have even been in the GPC, but if I do come across it later, I will update this post with where you can find it.

I just finished Level 12 out of 17 of the GPC. The momentum I built up going into Level 5 has been slowing to a crawl as I stumbled over structural incongruities, weak examples, bugs, and project file configuration issues.

The Groove (or Rhythm or Flow…)

I am most productive when I find my ‘groove’. This happens when I’ve overcome my learning curve, have developed a pattern of work, then get into a rhythm where I can knock out task after task by reusing the same steps.

Jimmy Diresta explains that first time you try something is the most difficult; you ‘go to school’ on the first one, and get progressively better and better – by time you finish, you’re an expert.

Matthew Inman made an incredible post on this subject, describing the agony and joy of creation…a few non sequiturs aside, he eventually gets to the meat of issue – how great and wonderful things can result from sweating over tasks that are often tedious and frustrating in and of themselves.

My problem is that I’m a perfectionist. If I encounter something that isn’t working to my satisfaction, I can’t ignore it – I have to ‘fix’ it. Maybe this is a characteristic of a good programmer, but it’s utterly frustrating when I’m working on it, and enormously satisfying when I get something to work properly…

The trouble, it seems, is that the content is getting thinner and thinner, and the issues referenced above that are breaking my ‘flow’ are getting more and more numerous. At a guess, I’d say that these last few videos were produced at a busier time than the others, and as a result, he simply didn’t have the time required to carefully plan and produce them as well as he’d like.

Whatever the reason, I have to remind myself that no matter how annoyed I get with this course, it’s still free of charge, and of far superior quality to any other GML ‘tutorials’ on YouTube. More importantly, distractions, bugs and problem solving (especially when the problem is more complex than it first appeared) are all part of programming – so I’d best get used to them 🙂 .

That said, on with the lessons…

###

Levels 9-11 (Doesn’t that look ominous?)

Level 9 was more or less a rehash of Level 7, focusing on instance IDs, along with another ‘cheat sheet’ from the resource folder. The two share a lot of parallels, and might be better off merged into one big lesson rather than two disjointed ones. There was even a loop snuck into one of the project files to create more enemies, but that wasn’t covered as part of the lesson.

Level 10 was one of the shortest lessons so far, and anyone who attempted to include a sound as suggested in Challenge 10-01 part C will discover that they’ll need to enable the New Audio Engine (Global Game Settings > General > Use New Audio Engine) before they’ll hear anything.

Level 11 was a letdown. I was really looking forward to Lists, but the only output method covered was the number of total items in the list (e.g. the ds_list_size function). The examples in the lessons didn’t really fit my concept of ‘inventory’ – that is, being able to output all the values in the list, or how many of each unique value there were (e.g. 2 Burgers, 2 Apples etc.). I suspect that this will be covered later in Level 13 (Loops).

###

This brings us up to…

Level 12: Grid Game Concepts

Grid games can cover everything from board games (checkers, chess etc.) to turn-based and real-time strategy games to classic video games like Namco’s Pac-Man.

In all cases, movement in a grid game is fixed rather than free form. GPC 12-01-A covers movement, and attempts to tackle the issue of getting hung on on corners due to the collision geometry.

The Lesson’s Solution:

Make the sprites equally sized (32×32 pixels in this case) and use a collision mask of 32×32 to ensure that they stay within the confines of the maze corridors. That’s a good start.

Next, he introduces how to manually code keyboard and collision events inside a Step event like so:

What the code is actually doing is checking to see if the player object will collide with a wall object (o_block), and if not (false), advance the player 4 pixels in the direction given.

Why this is an unsatisfactory approach:

Since are moving the player 4 pixels at a time, you have to manually tap back and forth until you are perfectly aligned or you will still get hung up on corners. This isn’t much of a problem when moving around 90 degree turns, becomes an issue when trying to get through ‘four-way’ and ‘T’ intersections.

How to fix it using only what we’ve covered so far up though Level 12:

When I set out to tackle this, the logic went something like so…

Find a location 32 pixels (one character or tile length) ahead of whatever direction I was going

Move to that location

Stop moving when you reach it

I tried using the move_towards_point function using a variable (e.g. target=o_player.x+32) in conjunction with distance_to_point but found that it target would always be 32 pixels further ahead, so it would never close the gap and would move in that direction infinitely. The solution would have to be something relative to, but external from the player object.

That’s when it hit me; why not use another object? So here’s what I did (coded in the o_player object)…

Press D-Key Event:

//create a new object as a waypoint for the player to move towards//move towards the target's coordinates at a speed of '4'
target=instance_create(x+60, y, o_target)
move_towards_point (target.x,target.y,4)

Collision with o_target Event:

//Destroy the o_target object on collision
with other {
instance_destroy()
}
//Stop the player
speed=0

Some of you may be looking at that code and scratching your heads – why 60 pixels? Well after lots of trial and error, I worked out that in order to move 32 pixels from where you were, you’d have to include the width/height of the player object (+32 pixels), giving you a total of 64.

When I tried 64, I found that I was stopping just short of where I needed to be, and worked out that the collision wasn’t actually detected when the edges of the two object met, but when the player object had overlapped it by the designated speed (4 pixels). So, 64-4=60, which places you at exactly 32 pixels over every time you press the key.

Once I had that working, it was time to clean up the code and put some utility conditions in it to prevent a keystroke from changing direction before you got to your destination, an additional event to stop you when you hit a wall, and to destroy any target objects you can’t reach (i.e. behind a wall) and some additional variables to be able to control the distance (pdist) and speed (pspd).

In the Press D-Key Event:

// check to see if character is moving
if moving=0 {
//set moving to true & destroy the old target
moving=1
with o_target {
instance_destroy()
}
//move target right by 'pdist' pixels at a speed of 'pspd'
target=instance_create(x+pdist,y,o_target)
move_towards_point(target.x,target.y,pspd)
}

Add moving=0 to the end of the o_target and o_block collision events and that’s pretty much it! Now using the Key Press event rather than just the Keyboard event will cause you to take a single step 32 pixels in whatever direction you are heading assuming you adjust the +/- pdist variable depending on whether you are going left (x-pdist), right (x+pdist), up (y-pdist) or down (y+pdist).

So once I got everything working, I swapped the WASD Events over from Key Press back to Keyboard and viola, true grid movement!

I’m up to Level 08, Lesson 03, and was working my way through the challenge that followed.

In playing through the game as-is, there a couple of notable bugs above and beyond what the challenge required:

The collision event for the potion was missing altogether – easy fix

givePlayerHealth(25)
with other {
instance_destroy()
}

The “health bar” didn’t accurately reflect the current hitpoints! Take a good look at the screen capture from his preview video below:

Look closely and you can clearly see “HP: 5” yet the health bar is nearly 1/3rd full! That doesn’t look right… so what’s wrong with it?

This one was a bit more tricky because neither draw_rectangle nor var have been covered yet…granted, the challenge was to change the color of the rectangle based on the # of hp, not to create a hitpoint bar from scratch – even so, it bothered me that it was broken and I wanted to see if I could troubleshoot and fix it…here’s the original code:

It’s no accident that my code is absent the healthBarWidth and maxHealth variables – since my healthbar is 100 pixels in length, the simplest solution was to shorten the bar. The reason those are included is size the fill rectangle proportionately to the amount of hp you have remaining so that you can name the hp bar longer or shorter depending on your needs.

But you can’t use the code from the original project file as-is…

First, you’d need to set minimum left-edge of x2 to match x1 for your filled rectangle. So instead of:

draw_rectangle(150,50,200+hp/maxHealth*healthBarWidth, 60, false)

You’d replace 200+hp… with 150+hp…:

draw_rectangle(150,50,150+hp/maxHealth*healthBarWidth, 60, false)

Secondly, you’d need to change maxHealth proportionate to the total amount of your hp (100) with respect to the overall length of your rectangle (150). This would give you 100/150 or 2/3rds (66.6% repeating).

Since hp is evenly divisible by the length of the health bar, this presents a problem as putting in var maxHealth=66 is pretty close, but not a pixel perfect fit inside the border rectangle (it’s about 4 or 5 pixels off).

Nevertheless, if I just had to make a health bar bigger or smaller than 100 pixels, I’d try to use something that divides evenly, hide it using depth and alpha channels, or leave off the border altogether. There may be more elegant ways to solve it, but it’s nearly 2am here and I think I’ve learned what I wanted to from this exercise 😐 .

Today I worked through Level 05 of the GPC. Level 03 introduced the irandom_range function, and provided a few examples of how I could throttle when actions occured – remember that in GML, action happens according to game speed (30 by default, or 30 steps/second).

This time, instead of leaving something up to random chance in hopes that it falls on the correct number or number range, we learned how to guarantee that the action occurred at a specified interval. This happened one of two ways:

Using a counter – declare an instance variable in the create event for an object and set a value:

//"counter" is the name of the variable,
//you could call it anything you wanted...
//we set it to 0 so that it could count up
//in the STEP EVENT later
counter=0

Then create a step event (an event that cycles x# of iterations, 1 for every point you’ve set the game speed to):

//add + 1 to the counter every time the step runs,
// 30 times per second by defaultcounter=counter+1
//when the counter reaches 150, or 5 seconds,
//do something
if counter >=150 {
...code whatever you want to happen here...}

Using Alarms – a built-in counter you can use. Each object can have up to 12 different alarms in it. They work like this:From another event’s code, enter:

//where 0 is the alarm # (0-11) and 90 is the
//# of steps to wait (3 seconds)alarm[0]=90

When the alarm #0 goes off, you can execute a piece of code by adding an Alarm Event for that specific alarm #:

//e.g. create an explosion in a random location
//on the screen
effect_create_above (ef_explosion,irandom_range (100,600),irandom_range (100,600),0,c_orange)//makes the alarm reset to 3 seconds
// comment out of if you want it to
//only happen once.alarm[0]=90

###

Level 05, Lesson 3: Getting Out of Sync

I’d like to preface this by acknowledging two points:

a. It’s FREE…I didn’t have to pay for ANY of this, yet all of it represents his own time, effort and money (i.e. hosting fees for his website, cost of recording equipment and software and so on).

b. John Janetka is teacher first and foremost – the GPC website, his YouTube channel and all the content therein are done in his spare time, and shared with me, you and everyone else who’s interested because he can and wants to, and with a ‘best-effort’ LoS.

Up to this point, I’d worked out that I needed to go to the website first, read the lesson, watch the video(s), then go back to the website to complete the challenges.

This pattern held true until you get to Level 05, Lesson 03. The first thing he asks you to do in Part A is to read the notes on “L05-03-Reading01.pdf”. There isn’t a link to it on the website, or anywhere!

Then he asks you to watch the video 05-03-A to review said notes, but again, there is no such video on his YouTube channel!

Further down, he asks you to go through the questions in L05-03-ConceptQuestions01.pdf, which, like the notes, aren’t linked on the page or anywhere else…

So where are they? Well, after doing some digging, I found the word document versions buried in the Lv05 resource folder that was included in the zip file from his resources page (the link labeled “Course Resources For All Levels”).

While I could have sworn that he’d touched on &&, || and != somewhere in one of his previous videos, they aren’t covered in any of the Level 05 videos up GPC-05-03-X1Preview. Not that it matters much as the lesson notes do a pretty good job explaining what they each do and when to use them.

By and large, the questions did a good job of reinforcing the lesson up to Part C, where the answers didn’t really follow the format he specified in his instructions…

SPOILER ALERT: Part C Questions and Answers

The question is phrased as follows:

Condition

Is it ‘always true’ or ‘always false’?

if x>20 || x < 10

if points<20 || points>10

if life>=100 && life>50

if life>=100 && life<=0

if (points>10) && (points<20)

My answers were:

Condition

Is it ‘always true’ or ‘always false’?

if x>20 || x < 10

Neither

if points<20 || points>10

Always True

if life>=100 && life>50

Neither

if life>=100 && life<=0

Always False

if (points>10) && (points<20)

Neither

His answers were:

Condition

Is it ‘always true’ or ‘always false’ ?

if x>20 || x < 10

not always true

if points<20 || points>10

always true since one of the conditions must be true

if life>=100 && life>50

not always true (ex. life is 25)

if life>=100 && life<=0

not always true (ex. life is 50)

if (points>10) && (points<20)

not always true

“Not always true” implies that it is sometimes false, when if fact, in some cases (e.g. if life>=100 && life<=0) it is ALWAYS False.

To check my answers, I wrote a test program which used the i_random_range function to generate a number every step between 0 and 200 (all of the examples above fall in that range). From there, I ran each condition separately and had it display the result (true, false or both) each cycle, proving them correct.

…and yes, I probably spent waaaay more time on this than I reasonably should have, but it’s all good practice, right?

Later still in the same lesson, he tosses in some functions not previously covered (e.g. room_exists, room_goto_next etc.). I hope these will be covered in more depth later as this was the first time we’d played around with a project that had more than one screen.