Porker Let’s Play Campaign – Post Mortem

In the wake a half dozen or so key requests on WeaselZone.com which yielded no Let’s Play videos, I decided to do a post-mortem on my advertising campaign to evaluate what went right and what went wrong.

###

It’d been a little over a year since I programmed Porker: The Quest for Tastiness. That little game was never intended to be a serious endeavor, but rather a means to get some experience creating and publishing a game.

All of that changed on on February 12, when I’d noticed a couple of kids had:

  1. Found that obscure little game on GameJolt
  2. Installed it
  3. Played it
  4. Posted it on YouTube

They did this all on their own, without any prompting, incentive or instruction.
I was so inspired and encouraged by their Let’s Play that I decided go ahead and expand the game significantly into a fully-featured game.

It took about 2 months to finish the game, and I was very proud of the result. We started looking at ways to advertise and I’d settled on engaging the YouTube Let’s Players community. After all, that’s where it all began, right? What follows is how I went about it and what I learned from the experience in hopes that this may help another fledgling game developer…

###

The Popularity Paradox

Although I did not coin the term, “Popularity Paradox,” as far as I am aware (as evidenced by the entire 2 minutes of Google Fu I spent looking) I’m the only person who has applied to the term to this context:

…many indie games become popular because they receive a lot of YouTube coverage from Let’s Players, but Let’s Players tend to only review games that are already popular…

Therein lies the rub! While I sent keys to the usual 1M+ subscriber Let’s Players, I doubted any of them would ever see, let alone play my game. My research seemed to indicate that their backlog of Let’s Play games was dictated by their audiences, usually by popular request via Reddit or some other medium.

So instead, I focused on smaller to medium sized channels, who I hoped would be willing to do a fellow small-fry a solid. Here are the numbers…

 

I started with the [now defunct] YouTuber Gaming Megalist, a spreadsheet of over 5,000 YouTubers and their demographic information. As I went through the list, I was able to pre-qualify about 100 or so potential YouTubers, spending about 5 minutes each on their channels to answer the following questions:

  • Do they post frequently (at least once a week)?
  • Do they cover small indie games, or just the ones everyone else is playing?
  • Does their ‘about’ page encourage developers to contact them, or state that they play indie/random/rage games?
  • Do they have an email address?

If I could answer, “Yes!” to all of these questions, they received a..

  1. Personalized message, tailored specifically to them (no mass-mailing)
  2. Game key for Porker to use for a Let’s Play video
  3. Let’s Player’s guide (PDF)

Of those original 100 or so emails sent out, 25 clicked the link to view their key, and of those, 14 claimed their key. Of those, only 3 went on to make Let’s Play videos.

So how do those figures stack up? Well according to Mail Chimp’s Email Marketing Benchmarks*, the Games industry average was a 19.71% open rate, and a 3.19% click through rate.

Since I emailed my recipients by hand, one message at a time, I can’t really say how many of the 100 odd that I emailed a key to actually opened the message, so instead I’m going to consider “key views” to be my open rate and “key claims” to be my click through rate.

Using those metrics, my open rate is 21% higher than the industry average, and my click through rate is nearly 4.5x greater than what I should reasonably expect.

I suppose that a 21% conversion rate (i.e. ~ 1 out of every 5 people who claimed a key made a video). That’s not terrible, but that was result of about 80 hours of work on my part…

I don’t have a full-time PR person, and have no way of distinguishing between people who are serious about exchange services and helping each other grow vs dishonest scammers who just want something for nothing.

Going forward, if I do hand out keys, I will use a service like distribute() to do it.

Changes

“Time may change me, but I can’t trace time.” – David Bowie

About 8 weeks ago, I celebrated my 1 year anniversary in my new role. A week after that, my manager resigned and I was tapped to take his place. Since then, it’s been a whirlwind of changes and new responsibilities.

By all accounts, this is old hat for me, but the demands on my time have increased significantly, becoming greater and greater as I unravel years of mismanagement and willful neglect.

While I’m very happy in my new position, I am busier than ever, and even less inclined to do anything productive when I get home after 10-12+ hours of skull sweat…

Pressure requires a release valve, and lately, my pressures had been relieved by playing games rather than making them. What’s worse is, these games introduced a whole-new set of pressures and demands on my time – so much so that it felt like a second job, albeit one which I wasn’t being paid to do.

###

While playing games can be fun and interesting, that part fades quickly. What keeps me interested is the social interaction; meeting and spending time with new “friends”. What I found was that for the people I was spending a great deal of time with, the opposite was true – they had no interest in camaraderie, just a person to occupy a seat at the table so they could carry on their game.

Maybe it’s the age gap speaking here, and relationships have given way to instant gratification – maybe I found myself surrounded by the “single serving friends” of Chuck Palahniuk’s Fight Club…

So what did I do? I withdrew…

 

Credits: featured image, “Butterflies” by M.C. Escher

The Fourth Level

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):

switch (keyboard_key)
 {
  case vk_left:
  case ord("A"):
     sprite_index=spr_player_walk_left;
     if moving=0 {
       moving=1
       instance_destroy(obj_target) 
       target=instance_create(x-64,y,obj_target)
       move_towards_point(target.x,target.y,4) 
      }
      break; 
 case vk_right:
 case ord("D"):
    sprite_index=spr_player_walk_right;
    if moving=0 {
      moving=1
      instance_destroy(obj_target) 
      target=instance_create(x+64,y,obj_target)
      move_towards_point(target.x,target.y,4) 
     } 
     break;
 case vk_up:
 case ord("W"):
    sprite_index=spr_player_walk_up;
    if moving=0 {
      moving=1
      instance_destroy(obj_target) 
      target=instance_create(x,y-64,obj_target)
      move_towards_point(target.x,target.y,4) 
    } 
    break;
 case vk_down:
 case ord("S"):
    sprite_index=spr_player_walk_down;
    if moving=0 {
      moving=1
      instance_destroy(obj_target) 
      target=instance_create(x,y+64,obj_target)
      move_towards_point(target.x,target.y,4) 
     } 
     break; 
 }

While trying to figure out line of sight, I came a new function:

collision_line(x,y,obj_player.x,obj_player.y,obj_barrier,1,0)

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!

GPC Level 3 Revisited

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:

Instead of this:

num=irandom_range(1,4)

if num=1 {
direction=0
speed=4
}

if num=2 {
direction=90
speed=4
}

if num=3 {
direction=180
speed=4
}

if num=4 {
direction=270
speed=4
}

You could do something like this:

speed=4
switch (irandom_range(1,4)) { 
 case 1: direction=90; 
 break; 
 case 2: direction=0; 
 break;
 case 3: direction=270; 
 break;
 case 4: direction=180;
 break;
}

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 when this was introduced… 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.

Here I Go Again on My Own

It’s been over 6 months since my last post. I’ve settled into my new role, and as the year winds to a close, I’ve been getting the itch to return to game making. Unfortunately, circumstances are such that I’ll be going it alone as Eric has retired from V-Toad Games.

Game programming and design is difficult, frustrating and greatly rewarding… but it’s not for everyone. What I learned from last go at it was that programming is not painting by the numbers. Being able to complete an exercise no more makes you a programmer than following a recipe makes you a cordon bleu chef. There are core skills you have to master, and to do that, you have to be passionate enough to stick with it.

Eric really tried – I sincerely believe that. Nevertheless, I know all too well that bills must be paid, and can’t blame him for not having the energy to go home and learn something that he just wan’t passionate about.

So why is being a solo project a problem for me? Many game developers, past and present, were/are one-man shows. I suppose it’s because I like feedback; I like to share what I’ve learned and bounce ideas off of other people because this helps me to reinforce and retain that knowledge.

As a consequence of my hiatus, I’ve all but lost everything I learned about GML, and will need to go through the lessons again to get back in the saddle. This time around should be much quicker, albeit lonelier.

“…Here I go again on my own…” – David Coverdale, Whitesnake

Get on with it!!!

Conflicting Priorities

I spent most of last week preparing for a face-to-face interview, pouring over the job description and reviewing every detail so as to be prepared for whatever the interviewer might bring up – this meant putting just about everything else on hold and using every waking moment to study.

The interviewers seemed pleased with me, and I was disappointed to learn that the job descriptions were erroneous; most of what were listed as, “required skills” weren’t required at all! What a waste…

Earlier this week, I received a call back from the recruiter explaining that they elected to go with someone else. In short, a week wasted and nothing to show for it but a heaping helping of disappointment…

###

After about a day of laying about and feeling sorry for myself, I decided that what I really needed was to focus on something productive… the game I’d set aside to study up for the interview was sitting there, 90% done, waiting for me to cross the last mile…

“If you know where you’re going, you can get there very fast.” – Grandmaster Henrik Danielsen

The most time consuming part of making any game is getting a clear picture of what you want to do. This is true for every component, whether it’s creating artwork, making sound effects, writing music or programming.

Of these, artwork is probably the most difficult (for me) and time consuming…  Often times, I may not have a clear mental picture of what I want to do, and haven’t developed a good system for working through ambiguity yet – but once I do break through, things move very quickly!

I’ve accomplished more in two days than I have in the last 2 months, and the end is in sight! All that’s left is just putting in the time I need to spend to get through the last few pieces, a few days more to test, then on to distribution!

With luck, I’ll have a successful YouTube marketing campaign and will sell enough copies to support myself until I finish Beaster’s Dungeon.

Losing Steam, Second Wind

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 incongruitiesweak 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:

if keyboard_check(vk_right)=true and place_meeting(x+4,y,o_block)=false {
 x=x+4
 }
 
if keyboard_check(vk_left)=true and place_meeting(x-4,y,o_block)=false {
 x=x-4 
 }

if keyboard_check(vk_up)=true and place_meeting(x,y-4,o_block)=false {
 y=y-4 
 }

if keyboard_check(vk_down)=true and place_meeting(x,y+4,o_block)=false {
 y=y+4 
 }

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…

  1. Find a location 32 pixels (one character or tile length) ahead of whatever direction I was going
  2. Move to that location
  3. 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!

 

Image Credit: Don Quixote, oil on canvas painting by Jean-Baptiste-Camille Corot, 1868.

A Challenge Within a Challenge!

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:

  1. The collision event for the potion was missing altogether – easy fix
    givePlayerHealth(25)
    with other {
         instance_destroy()
    }

     

  2. 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:

var healthBarWidth=100
var maxHealth=100
draw_set_color (c_white)
draw_rectangle(150,50,200+hp/maxHealth*healthBarWidth, 60, false)
draw_set_color(c_black)
draw_rectangle(150,50,200+healthBarWidth, 60, true)

The syntax for the draw_rectangle function is as follows:

draw_rectangle(x1, y1, x2, y2, true or false) where

x1=the x location of the upper left-hand corner of your rectangle
y1=the y location of the upper left-hand corner of your rectangle
x2=the x location of the lower right-hand corner of your rectangle
y2=the y location of the lower right-hand corner of your rectangle
true=filled with whatever your draw_set_color is
false=empty (transparent) with a 1 pixel border

Confused? Well here’s an illustration I made to visualize it better:

Now lets apply that to the code above. Working through his arithmetic for the filled (false) rectangle, here’s what you get for the x2 values if you substitute the variables for their numbers:

200+0/100*100=200 (0 hp)
200+100/100*100=300
(100 hp)

Expressed in code, it would look like this:

draw_rectangle(150,50,200,60,false)//0 hp
draw_rectangle(150,50,300,60,false)//100 hp

…and output like this (assuming you include the border rectangle):


The left edge (x1) starts at 150 pixels in, and the right edge ends at 300 pixels, giving you an overall length of 150 pixels (300-150=150) along the x axis.

When the player has 0 hp, the left edge is not 150, but 200, leaving you with a 50 pixel (1/3rd) wide rectangle, which is exactly what you see in the screenshot above.

So I dug into the code and came up with the simplest solution. This was the result:

Notice that it says “HP: 50” and the bar is exactly half way!

So how did I fix it?

Simple – move the left edge over by 50 pixels, giving the overall length of both rectangles to be 100 pixels rather than 150, removing the 50 pixel lead:

//health bar draw code - the first rectangle draws the filled color
//the second rectangle draws the border
draw_set_color (getBarColor())
draw_rectangle(200,50,200+hp,60,false)
draw_set_color(c_black)
draw_rectangle(200,50,300,60,true)

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 😐 .

Time!

Happy New Year, and Happy Birthday, Eric!

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:

  1. 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 default
    
    counter=counter+1
    
    //when the counter reaches 150, or 5 seconds, 
    //do something
    
    if counter >=150 {
    ...code whatever you want to happen here...
     }

     

  2. 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.

I’ve provided it here, feel free to use it if you’d like.

…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.

Welp, on to the rest of the lesson! Stay tuned for more…

 

Image Credit: Don’t Hug Me, I’m Scared 2

Stepping Stones and a Clear Path Forward

Building on an Unstable Foundation

As we draw closer to a working prototype, it’s become increasingly more apparent that there are some fundamentally flawed issues with the way we’re going about implementation.

Eric is new to both programming in general (save for some college level coursework a few years ago), and GML. All in all, he’s got about 4 or 5 weeks worth of experience in total, but no formal training. As such, he doesn’t have a solid foundation of knowledge to build on, forcing him to seek out tutorials (usually YouTube videos) which give him ideas as to how a thing can be done.

The most popular videos are more akin to “Let’s Plays” with little (if any) structure, and even fewer explanations as to why the developer elected to go about doing things a certain way.

This forced Eric to look at what the other developer did, attempt reproduce it, then reverse engineer it without understanding what each piece’s purpose – trying different arrangements and configurations until it worked (or at least appeared to).

What troubled me was that sometimes I’d ask for a seemingly trivial feature only to find that he was unable to work out how to program it, and compromised with an implementation that wasn’t up to spec.

For example, instead of using keys 1-6 to toggle a different weapon type, and Ctrl to fire,  he mapped weapon type 1 to key 1 because from a logic standpoint, he had no idea how that would work, let alone how to frame the problem so that he could look it up.

Another example was the breakable wall from my prototype specifications in the last post. What I asked for was for wall, when placed, to take damage when it collided with the enemy, and update it’s animation frames to show progressively more damage before being destroyed.

Because he didn’t understand how variables worked, the wall was killing the enemy rather than the other way around – my suspicion was that he didn’t use the “with other” construct to indicate that it was the wall taking damage, not the enemy as they both had an instance variable called “hp” (i.e. hitpoints).

After a few more hours of working on it, he came back and this time the walls were taking damage, but being destroyed after only a second or two. This was because he was using the image_index property to advance the frames of damage to the wall sprite, destroying the object when it reached the end of the animation, foregoing hitpoints altogether.

Since the room speed was set to 30 (i.e. 30 cycles/second), the enemy was colliding with the wall 30 times a second, causing the wall to cycle through each frame of its sprite sheet within a fraction of a second. While this “appeared” to work, it in fact did not follow my design specifications (no hitpoint system) and was therefore not fit for purpose.

I suggested how this could be solved in pseudo code, but he insisted he tried that and it didn’t work – again, probably because of which object he was calling the variables from, but I didn’t know that either at the time.

So where could we go from here?

You Don’t Know What You Don’t Know…

The root of the issue was that while I understood the basic logic I wanted to use, I didn’t have the syntax for it, and neither did Eric. We needed to take a step back and learn the basics before trying to implement big, hairy, complicated features.

So again, I took to YouTube – we’d watched several of the Let’s Learn GameMaker: Studio channel’s videos, lots good information covering what was available and what options there were for each feature, but there was no practical application of those lessons; at at the end of the lesson, there was no example of a typical use case for that feature in your game

A Clear Path Forward

Just when I was about to give up, I managed to stumble upon another channel aptly named, Gamemaker Game Programming Course.  The channel is a bit confusing (the playlists in particular) until you work out that it’s actually just a video repository for his website:

www.gameprogrammingcourse.com

Start there, download the resource packs and project files, then start with the playlist labeled: Level 02 [ GameMaker Basics Sprites Objects Events ].

The site and videos were created by computer programming teacher named John Janetka for his high school’s computer science program. The quality of the content and structure of the lessons are the best I’ve come across on YouTube thus far.

By the end of Level 02, I was able to solve both of the programming issues Eric was struggling with above, and created two games in the process. Simple as they were, the experience was valuable.

I’d asked Eric to place his programming efforts on hold to go through this course with me. I asked him to try not to think of this as a step backward, but rather rather a stepping stone forward toward better, more stable code. He agreed, and will continue to check in every day or so to share what we’ve learned.

###

Image Credit: “Martyn B

Disclaimer: I have no affiliation with any of the websites, applications or YouTube channels referenced above.