Purgatory Purgers: Simple Music Control

Background

In past projects, I controlled music using the room creation code, e.g.:

audio_stop_all();
audio_play_sound(snd_music1,100,true);

This would stop all previously playing audio and start the new music track, looping it until the next room was created.

Functionally, this works fine, but I wanted a more centralized way of handling this so that if I wanted to make a change, I didn’t have to do it N number of places, equal to the number of rooms I created.

How It Works

I created an object called “obj_sound” and placed it in the first room, then I flagged it as ‘Persistent’ so that it would carry forward from room to room.

I added a Room Start event with the following code:

if room==rm_level1 {
audio_play_sound(snd_lvl1,100,true);
}

if room==rm_level2 {
audio_play_sound(snd_lvl2,100,true);
}

At the start of the room, it checks to see if the name of the room matches “rm_level1” (the name of the first room/level), and if it does, it plays the sound “snd_lvl1” at a priority of “100”, and sets looping to “true.”

Once that was working, we needed to be able to stop the previous music track before loading the next one. This can be done using a Room End event:

audio_stop_all();

This stops all audio before the next room is loaded, preventing tracks from playing over each other.

Conclusions

There are other ways this could be handled, however…

  • It works for what I need it to do (starts a looping music track that’s definable by room name).
  • It’s centrally controlled.
  • It does this in the simplest way I know of, and more importantly, I understand it!

Beaster’s Dungeon Revisited: Part III

When I last left off, I managed to get the trap placement mechanic working as designed. Of the core mechanics I needed to get working, the last one remaining was enemy platform pathfinding…

Platform Pathfinding Challenges

As previously stated, the game’s object is to ward off hoards of enemies trying to navigate their way to your treasure vault by placing traps and barriers in their way.

The player can navigate the environment by moving left, right, jumping, and falling.  I wanted to give the enemy a similar capability:

In this scenario, an enemy character can walk left or right and can clear obstacles up to two squares (32x32px tiles) high and three across. Each scenario is numbered and represents the following:

  1. All possible ‘jump’/walk movements from a platform (1-3 across, 2 up)
  2. Walk left or right 1 square
  3. Drop down left or right
  4. Jump up left or right 1 square
  5. Jump up left or right 2 squares
  6. Jump up left or right 2 squares, illustrating that the platform might be floating (i.e. allows free movement beneath it)
  7. Jump across left or right 1 square and up 2 squares
  8. Jump across 2 squares (same height)
  9. Jump across 2 squares and up 1 square
  10. Jump across 2 squares and up 2 squares
  11. Dropdown 1 square left or right from any height to a platform below (this is implied in 3, but I wanted to illustrate it explicitly)
  12. Drop down to a platform of any height, 1 square left or right across
  13. Drop down to a platform of any height, 2 squares left or right across

While I found a couple of examples of this working/implemented in GML using a modified version of the A* Search Algorithm, I could never get them to work within my project. I discussed the problem with my friend Jason, who created a working prototype for me that met all of the design specifications. But not fully understanding how the code worked, I failed to integrate it.

Now that I have the time to troubleshoot it, I’m reluctant to do as I fear that I don’t understand it well enough to support it. Instead, it might be better to build something simpler…

Possible Solutions

Thinking through the problem, there are many other ways I could have solved this. Wrecking Crew for the NES comes to mind:

Enemies (and the player) in Wrecking Crew use ladders to navigate up and down platform levels. Why couldn’t I implement a similar feature?

Ladders

For example, instead of trying to make the enemy AI smart enough to navigate obstacles with a preset of constraints/scenarios, I could have them wander left and right across vertical planes, moving up or down when they reach a ladder, depending on whether the vault was above or below them.

Alternately, rather than placing ladders in fixed places, perhaps some enemy types could create erect them?

Stairs

Another option would be to use teleportation in the form of background staircases:

In this example, the enemies could access specific floors using “staircase” objects that would move them from point A to B and B to C, and vice versa.

Either scenario would necessitate creating two extra animation frames for each enemy sprite. Not a deal breaker, but something to consider…

Revisiting the Triple Threat

About ten years ago, I distilled video game development into three core skillsets (i.e., the triple threat):

  1. Art
  2. Music (and sound effects)
  3. Programming

I’ve always been interested in art (drawing, sculpting, and to a lesser extent, painting). I taught myself how to play simple melodies on a cheap Casio keyboard in my teens. I learned to use, repair and maintain personal computers in the early 90s out of necessity (I didn’t have much money, so my choices were to fix it or do without).

Eventually, I started entertaining the idea of combining my love of art, music, and computers to try my hand at making video games instead of just playing them. Thus began my journey of self-discovery.

Art

I’d always been able to draw relatively well by hand. I lightly scribbled rough shapes, then fleshed them out with strong lines. As technology became more accessible, I’d digitize my art using a flatbed scanner.

I even purchased a digital camera and some clay in the early 2000s to sculpt models and photograph them from different angles in much the same fashion as Adrian Carmack did for DOOM. I could never get the hang of 3D modeling or translate these analog skills into digital media. In time, I abandoned that track in favor of pixel art.

At first, I was terrible at it. But by studying examples, watching tutorials, and practicing, I developed proficiency using Pyxel Edit. I started with a 16-color EGA palette, then later expanded this to the 52-color NES palette.

This has become my niche and primary medium for artwork creation. Tile sheets are relatively quick to make, which is important when you’re a one-man operation. There are 40 years of examples to draw upon for inspiration.

Music

I’ve been writing music for almost 30 years on the Amega Module format, beginning with tunes written on Fast Tracker II using samples ripped from other people’s files. Later, I sampled some high-quality instruments – these were used in the publication of my first album.

Unfortunately, the songs and samples used were lost to time, but I still have a 20-year backlog of my previous work,  dating as far back as 1997, all written for games that existed only in my imagination.

These days, I use a Windows port called “Skale Tracker.” It’s based on FT2, can export to .WAV and .OGG formats, and supports up to 64 tracks (although I rarely need more than eight these days and write chip tunes with half that). I’ve mixed and mastered my exported works in Audacity and have been very satisfied with the results.

Programming

Programming has always been my biggest weakness. I’ve never been the kind of person who can read a book on a subject and put that knowledge into practice. At best, I can look at examples, then adapt those to my needs once I understand how.

Someone once told me that DOOM was programmed in C++ and that I could do likewise. I remember seeing a boxed copy of Borland Turbo C++ at the local Best Buy, retailing for $300. I remember thinking then that if only I had the money to buy it, I’d have everything I needed to program my own version of DOOM. I was woefully ignorant back then…

Many times over the years, I’d hoped to get around my limitations by using a game creation engine,  my first exposure to this was around 1995. I’d gotten ahold of the Pie in the Sky Software’s 3D Game Creation System for MSDOS.

It was a 2.5D game engine capable of creating games slightly beyond Wolfenstein 3D (floor and ceiling textures, angled walls) but fell short of DOOM (no height variable). While I had limited success designing very simple levels, I didn’t understand its limitations or advanced features and gave it up in frustration.

In my late teens to early 20s, I experimented with 3D Game Studio.

I could create primitive shapes, texture them, and use those objects as building blocks to create a castle out of modular pieces. I could render the map and fly through it, but I had no idea how to use its scripting language. I continued to toy with it for a couple of years, but again, I got discouraged as my imagination outpaced my ability.

In 2014, I picked up GameSalad, and created this website. I had no idea what I wanted to create, so I groped around aimlessly in the dark, bumping into bugs and lacking support.

At the time, GameSalad was primarily marketed to Mac users, and the Windows version lacked many core functions. By the time it caught up to the Mac version, they had stopped offering the Standard Edition for free and switched to a subscription model. I didn’t feel comfortable paying for something I wasn’t entirely sure I could learn to use, so I abandoned it and moved on.

I discovered Game Maker Studio in the spring of 2016. I teamed up with my old friend Eric, and we set out to learn the engine. Eric volunteered to do the programming, I would do everything else (artwork, music, design, documentation, project management).

In the early days, YouTube tutorials were our primary source of GMS programming information. Later, I would compare these to “let’s play” videos rather than proper lessons. Thankfully, I eventually discovered John Janetka’s Game Programming Course (GPC). This was a game changer for us (well, me anyway). While the second half of the lessons became disjointed, it was enough to see me through the creation and publishing of my first game.

Unfortunately, I’d run out of time (and money) and had to start working again. Work became all-consuming, and after spending 10-12 hours of skull sweat a day on technical matters, I didn’t have the energy or drive to devote to game programming when I got home. On the weekends, all I wanted to do was sleep.

I tried to pick it back up several times but couldn’t get back into the habit…

When Stars Align

That all changed this year. I have…

  • Started a new job with a pension, so now I have a future and retirement to look forward to.
  • Rid myself of $117,000 of student debt.
  • Nearly paid off my mortgage (8 months to go).
  • Lost 43 lbs. of excess weight through diet and exercise, and I am on track to be back to my ideal weight by the end of the year.

I’ve finally reached a point in my life where I can resume my pursuit of game development now that I have the time, energy, and resources to do so.

More to come…

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 prequalify 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 exchanging services by helping each other grow versus 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.

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.

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.

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.

Finding a Direction

I hope the Holidays are going well for everyone!

As I mentioned in my previous post, Eric and I are working on our first game. We, like many other beginners, set out with a vague and nebulous concept of the feeling of the game we wanted to make.

So, I went off and worked on creating artwork with some very general design specifications:

  • 2D side perspective
  • 32×32 pixel character sprites
  • 16×16 pixel tiles (orthogonal)
  • Variable length traps (divisible by 16px)
  • 16 color EGA palette (CGA backwards compatibility)
  • Medieval/Fantasy Theme

Eric went away and started working on the programming:

  • Basic keyboard movement (left, right, jump)
  • Basic enemy movement (chase the player when in range)
  • A simple scenario where a specific enemy type (Torch wielding peasant) triggered an flammable barrel that exploded a bridge tile when he got near it
  • A water obstacle that enemies and the player fell through

The astute reader will pick up on the obvious item we missed: designing the game. What wasn’t immediately apparent to us was that we weren’t really building a game because we hadn’t defined what the game was – not even the basic object (i.e. how you win or lose) let alone the rules and mechanics…We were diving into polish (animations, effects etc.) before we even agreed on the scope of a working prototype!

###

Why this happened…

It’s a common mistake for beginners like us to go into too much elaboration too quickly because it feels good to see a result that resembles a finished (read: polished) product. What we were doing wasn’t play testing because there wasn’t a game to play – instead, we were simply validating pieces of code.

The fact is, a game doesn’t need fancy graphics, particle effects, sound effects and background music to be a game (e.g. Pong).

What we did next…

At this point, I halted work and called for a meeting with Eric to hammer out the game mechanics, then create a working prototype.

Eric comes from a creative writing background and isn’t troubled by ambiguity; he never questioned why or how the exploding barrel would get to the bridge, and what tactical or strategic purpose destroy a bridge would serve in the context of the game. Instead, the novelty of this scenario was self-evident to him and required no explanation.

When I asked him to describe the game to me, and what I got, while interesting from a story/scenario perspective, was conspicuously lacking a clear definition of what the game was.

So I took stab at it instead:

Beaster’s Dungeon (my working title for the game) is a 2D platforming game where the player must stop oncoming hordes of peasants and heroes from reaching your treasure by collecting resources and plans needed to create and place deadly traps and obstructions in their path.

That’s a pitch – it tells you everything you need to know about how the game fundamentally works, and Eric agreed. From that pitch, we can distill this into a basic objective:

The player “wins” by destroying all enemies before they reach the treasure, and advances to the next level. The player “loses” by either dying (taking too much enemy or environmental damage) or one enemy reaches the treasure.

So, from that would derive several essential components:

  • Obj_Beaster: We needed an object to control the player character on screen. The object must be able to navigate in a 2D environment (move left, right, jump, collide with other objects).
  • Obj_[EnemyName]: We needed at least one test enemy that followed a set path to the treasure, stopping only to attack obstructions that got in it’s way. For pacing reasons, enemies would need to give the player a 90 second head-start to collect resources and place obstructions/traps.
  • Obj_Wall_Destructible: This was an afterthought, but seemed like a good way to allow the player to control the pace of the enemy horde(s) to give traps more time to kill them. The wall would take x# of hits before crumbling and allowing the enemy to continue on it’s path.
  • Obj_[TrapName]: We needed at least one trap that damaged an enemy that collided with it. The player would be able to place traps when he had collected both the trap’s “plan” (recipe) and a sufficient number of resources to build said trap.
  • Obj_[ResourcesName]: We need at least one resource object that, when collected, adds +1 to a resource counter. When a trap that utilizes that resource is placed, it adds -1 to the counter.
  • Obj_[PlanName]: In order to create a specific type of trap, the player must first possess the “plan” for that trap.  This object would update the player’s inventory to establish whether or not the player is able to place said trap.
  • Rm_TestLevel1: GameMaker studio utilizes “Rooms” to create environments where objects, backgrounds and tiles exist. You can think of these as the “level” where all of action is taking place. The level would need to have a clear path from point A (the origin of the enemies) to point B (the treasure) with enough room for the player to set up his gauntlet. It would need at least 1 trap plan, and be populated with sufficient resources to construct enough traps to kill all incoming enemies.

Once these components were present and behaving as described, we would have a prototype to test the basic functionality of the game.

Notes, Influences, Theories and Rationale

Looking at the game above, what we have described is essentially a “Metroidvania”, Lemmings in Reverse tower defense game. Sound extraneous? Perhaps, but that’s what the Prototype is intended to test. Let’s break that down into phases and game play:

Metroidvania refers to 2D platform exploration. This is where resources and plans come into play; they are placed in such a way as to encourage the player to get off the beaten path and explore to sprawling dungeon. Since the game happens in real-time (not turn-based), the player has to manage the tasks of collecting resources and placing traps while the enemy is slowly advancing toward the treasure.

Note: The game has gravity (i.e. not a top down 2D game, such as Legend of Zelda) so the player falls when moving off of a platform.

To keep the player from getting into an unwinnable/unloseable game, the enemies would have to follow a set path while allowing the player freedom of movement the enemy doesn’t have. To that effect, the player and move left, right, jump up onto platforms to get to areas above the enemy, and drop down from specific platforms to those below the enemy (think Contra).

Lemmings in Reverse is the notion that it was more fun to deliberately kill the Lemmings than steer them to safety, and is key to bridging the gap between a classic 2D platformer and a pure tower defense game.

If the enemies were left to freely roam the dungeon looking for the player or the treasure, it becomes possible for them to wander into a place they can’t get out of, rendering the level unwinnable (and unloseable).

Tower Defense is the most ubiquitous description for the idea of using “traps” or turrets to destroy oncoming enemies. We felt that this genre had been done to death, and wanted to introduce the exploration component as a way to add challenge and depth to an otherwise dull experience.

###

Predictions? Too early to tell, but once we have a working prototype, we can determine how pacing will work. From early “play tests” we’ve done, I can already tell that we will have to have some kind of mini-map or other visual indicators to let the player know that the enemy is attacking and where. It’s too easy to get lost in the labyrinth of the resource floors (i.e. platforms outside of the enemy path) and not know where the enemy is and if you are in danger of losing the level.

There’s got to be balance between the exploration and trap setup portions so that the player has to do both and will be rewarded for good time/space management.

Where to Begin?

Before one can build something, there are a few basic questions to answer:

  1. What do you want to be build exactly? (2D? 3D? Puzzle? Action? be specific)
  2. What tools/resources will you need?
  3. What skills will be needed to create resources/use tools to accomplish your purpose?

Since I want to jump in and create something, my aim is to gain experience. I know that I’m not going to create a perfect game on my first attempt, so I want to start with something simple and portable. That last time I attempted this about 12 years ago was with a tool called “3D Game Studio“. While I was able to create a few “working” 3D environments, and learned a lot about textures, sprites, blocks etc., I was never able to get a handle on scripting.

Also, given that I had no experience working with 3D modeling tools (would have been 3D Studio Max at the time), I had no way of creating models for actors, nor did I know anyone who was capable doing so.  While I might be able to teach myself, this is a highly-specialized art that takes a lot of time and skill to master.

2D sprites on the other hand are something far more familiar to me as I can draw, and I am very comfortable with Photoshop (I ought to be, having used it for the last 18 years or so).

So going back to the questions above, here’s what I’ve got:

What do you want to be build exactly? (2D? 3D? Puzzle? Action? be specific)

A simple, 2D game with basic mechanics (right now I’m leaning toward a “Diabolika” clone)

What tools/resources will you need?

I’ve been researching non-programmer friendly game engines and came across GameSalad. It’s PC version is a bit buggy, so I’m hoping it’s just user error and not a reflection of the quality of the application.

What appeals to me about it is that I can use for free as long as I like, and will only incur a cost ($300 USD/year) if I elect to publish with it.

Edit: GameSalad went to a subscription model around June of 2015, and no longer offers a ‘free’ version.

This seems like a reasonable investment given that I’d have the ability to publish to Android, Apple and PC (HTML5) markets without having to do any porting.As to other tools, I already have Photoshop, and will be picking up a Wacom tablet to draw sprites with (I own one already, but that’s back in the US, and I’m currently working in Saudi Arabia).

As to sound effects and Music, I have a decent microphone, and have been creating electronic music on Skale (a windows-based version of Faster Tracker II) for almost two decades, and have literally hundreds of pieces (some finished, many not) of original music I’ve composed myself, and can use as source material.

What skills will be needed to create resources/use tools to accomplish your purpose?

Of all the tools listed above, the only one that’s new to me is GameSalad. Thankfully, there are a lot of Tutorials on YouTube that explain the basics, as well as other resources provided by GameSalad and others to help me get started. I’m currently working my way through a series of tutorials  created by “Matt P”.  From what I can tell, this appears to be part of a formal game creation class as he’s also included links to the source material in his comments (sprites, sounds, music etc.).I’ve watched and followed along with 3/9 of the videos so far, but I’ll write more on that in my next post…