Congratulations! Your game has evolved into Alpha!

Up until today, Gonna Catcha was nothing more than a collection of protoypes, loosely connected together and couldn’t work together as a whole game without changes to the hard code. 
Well that ends today. 
I’ve taken care of all the little things and filled up the holes to make Gonna Catcha a playable alpha (yes, I know I’ve called the previous versions of the game “alpha builds”; in hindsight I think that was jumping the gun a bit). It still has some game-breaking bugs, but at least the game progression is there now:

And just in time for Ghost Month, the 7th month of the lunar calendar, which starts tomorrow I believe. According to the various superstitions surrounding Ghost Month, I shouldn’t be working on Gonna Catcha at all for the next 30 or so days, unless I want to be pestered by evil spirits.  Well, if anything goes wrong in the coming month, such as me losing all my work or my computer catching on fire, then I’ll have a convenient scapegoat:

On the 15th day of Ghost Month is the Ghost Festival. During the festival, the Heibai Wuchang 黑白無常, the Black and White Guards of Impermanance, supposedly appear and give people free money.  Depending on your cultural background, you may know them by different names:

  • Fan Wujiu and Xie Bi’an, 范無救  謝必安
  • Qiye and Baye, 七爺 八爺
  • Da Boye and Er Boye, 大伯爺  二伯爺
  • Pohena Das and Donum Dono 魄伊娜・達斯  當納睦・當儺
OK, I made that last one up. 😛
There’s more to Ghost Month and the Ghost Festival than that, but I’ll save it for another day. Also, the ROM Game Jam is next weekend; I need to brush up on my HTML5 GameMaker skills.

P.S.  I updated Gonna Catcha’s info page with a new screenshot and the video above.

Copyright © Quadolor Games. All rights reserved.

You have encountered Abstract Art.

Has it been two weeks already?  Tracking the Steam Summer Sale and playing around with shaders in GameMaker: Studio can really make you lose track of time.
Sometimes I tweet stuff on Twitter if the aforementioned stuff isn’t substantial enough to be turned in a full blog post.  If you haven’t done so already, you can keep track of those tweets on the sidebar on the right side of this blog or follow me on Twitter.
If you have been following on Twitter, then you’ll probably already know that I signed-up for and got into the ROM Game Jam, the first ever game jam to be hosted by the Royal Ontario Museum (ROM) in Toronto on August 9-11.  I am part of the same team that was making That Which Binds Us.  I say “was” because we’re focusing our efforts on the ROM Game Jam now, so That Which Binds Us has been put on hiatus for now.
Another tweet I made was about shaders.  Wait, I already mentioned that above. Anyway, I downloaded some shader scripts from this forum post on the Game Maker Community forums and, just for fun and curiosity, applied them to Gonna Catcha‘s drawing code. Although it wasn’t its main purpose, but the graphics code modifications I had previously done also allows me to apply a shader to the entire screen, but I wanted to do that anyway.  Two birds with one stone I guess.  

Here are the results of my shader experiment:

Once you’ve regained your composure from watching the trippy and completely unnecessary graphical effects, you may notice something new in the video.  The game randomly places rocks in the maze that act as destructible walls. (Rocks?! I thought they were just blobs!) This is to slow the player down and allow the spirits to better disperse throughout the maze.  However, the rock impede the spirits as well, making the whole thing kind of pointless.  Of course, they’re spirits; so my plan B would just have them, you know, pass through the rocks unimpeded. Preta can stay impeded by rocks, being corporal beings like the players.

One other big change I made to the game that might not be obvious in the video is the player movement code/rules.  Previously, the players had free movement; now their movement is restricted to the grid much like the spirits and preta are.  I did this to make turning around corners easier for the players. My previous solution had the players snap to a corridor if they were “close enough” to turn into one; it looked a bit weird and was a bit finicky.

Re-writing and messing around with the movement code did produce some amusing bugs in the process, something that hasn’t happened in a while.

(Wow, this post was longer than I thought. And I was worried that I wouldn’t have anything to write about! Harumph!)
Copyright © Quadolor Games. All rights reserved.

So much to talk about, so little time to write about it.

I seem to be falling behind on my plans to update this blog once a week.  Every time I implement an idea and am in the middle of writing about it, another idea comes to mind.  I end up holding off writing my post to execute the new idea so that I can put that into the post too.  I need to a way to synchronize my blog cycle and ideas cycle together…
Yeah, I  don’t think that would work very well with only one person.

For the same reasons, this update is just another text + screenshots update instead of the video update I had planned earlier, which would have shown the game as it is now in action and demonstrated the audio as well (mostly the newly added sound effects).  I guess that will have to wait for another time.

Anyways, there are four things I would like to talk about today:  New HUD, Title Screen, Vector Stuff and Shaders.


First up, I’ve made some changes to the gameplay and HUD (the two are related).  Below is a screenshot of the current in-game display:

HUD 3.0

You will see that the HUD now takes up both the topmost and bottommost portions of the display, making the levels themselves slightly shorter.  First, let’s have a closer look at the top HUD:

New top HUD

And for comparison, let’s throw up the old HUD here as well:

Old HUD is old.
Aside from the different colours and the fact the second player isn’t active, there two main changes to the new HUD, which also reflect changes to the gameplay:
  1. A score counter is now where the life counter used to be in the top-left.  Previously I wanted the score to be tallied at the end of each level (in the style of games such as Battle City and Ice Climber).  However, I’m making some changes to the scoring system that would make that tally system impractical, such as rewarding more points per spirit returned to the shelter/jail in a single trip (think along the lines of Pac-Man‘s scoring system when you eat multiple ghosts in a row).  I may still have an end-of-level score tally for bonus levels.
  2. Remaing spirit counters are now where the round counter used to be in the top-center (not to be confused with the in-hand spirit counter just below the score).  In the original round flow, all the “target” spirits you needed to capture for a particular round appeared at the beginning of that round.  There was a maximum of 5 spirits you needed to capture per round; I felt that this number was too low and made each round too short.  Increasing the maximum number made the level too crowded when you also take the “nuisance” spirits (i.e. the ones that you don’t need to capture) and hungry/vagrant ghosts into account. Also, it was also balanced out by the spirits clumping together, making it easier to capture more in a single “trip”. My solution for this is to have a 4-5 on-screen spirit limit and then spawn more when the number on-screen falls below the limit (much like Pengo and Battle City, again).  The remaining spirit counters show how many spirits have yet to be spawned.  

Now let’s look at the bottom HUD:

New bottom HUD
This is the new home of both the lives and round counters.  Also, the lives counter uses character icons now rather than hearts.

Title Screen

Next up, I’ll briefly show and describe the title screen, which is still under development:

What? It didn’t say “Coin chute required” in the system requirements!
I want my quarters back!
There are still a few things I need to add to it:

  1. A graphical title to put up top rather than just having “G O N N A   C A T C H A”
  2. in plain text.

  3. a score table (so player will know what is worth what in the game).

Vector Stuff

Next, have a few vectorized spirits:
Two down, four more to go.


Finally, if you haven’t figured it out already,

Shaders are coming coming to GameMaker: Studio 1.2, which is just around the corner.  I can wait to see what kind of 2D graphical hijinks I’ll get into when it does, such as better CRT monitor simulation. (Maybe?)

Well, so long. See ya next time.
Copyright © Quadolor Games. All rights reserved.

Come gather ’round people, and listen to two tales of programming lore…

The time between the last post and this one was longer than I expected.  I wanted to make a post earlier, but then I started on something neat and decided to hold off posting until I gathered my thoughts about it.  The result is a very long post about two topics: old display simulation and an audio engine update, complete with anecdotes of projects I did in the days of yore.  Brace yourself.  At least there are lots of pictures to look at.

Old Display Simulation

I’ve experimented with a few graphical overlays that will make the game window of Gonna Catcha look like an old CRT display.  As with the audio capabilities of Gonna Catcha, this is something new to me, so it will require some research.  I’ve already found some blog posts that talk about it, but the methods shown used pixel shaders, which GameMaker: Studio doesn’t support (well, at least not yet).

To get technical, you could code up your own pixel shader functionality into a GameMaker application using the draw and get pixel functions, but it will be very, very computationally expensive (i.e. it will make the game run very slowly).  I’ve done something similar with GameMaker before…


I’ve created a raytracer that renders several spheres on the screen in real-time without using GameMaker‘s 3D functions, just the 2D functions and mighty 3D geometry and trigonometry powers.  It could render at low resolutions fine (like less than 50×50), but once it goes beyond that point, it slows to a crawl:

This 50×50 scene runs at 8 frames per second…

…and this full-resolution frame takes about 18 seconds to render.
Yeeeah, I think I’ll stick with the built-in 3D functions for now.

*flash forward*

As interesting and colourful as my raytracer is, we should be going back to Gonna Catcha now.  Since I currently can’t use shaders, I’ll just have to make due with using foreground overlays and GameMaker‘s blending modes.  Below are some screenshots of the game with and without the various experimental overlays.  Click to magnify the screenshots, as the effects can’t be seen in the thumbnails.

Baseline (no overlay)
Scanlines only 
“LED billboard???” (Scanlines +   High contrast RGB dots)
“LCD???” (Scanlines + Low contrast RGB dots)
And here are some close-ups:
Baseline (no overlay)
Scanlines only 
“LED billboard???” (Scanlines +   High contrast RGB dots)
“LCD???” (Scanlines + Low contrast RGB dots)
So far, I like “LCD???” the best, followed by having scanlines only, but both are still not quite the CRT look I’m looking for.  Nevertheless, I’ll continue to soldier on.

Audio Engine Update

In other news, BASS, the audio library I’m using for both Gonna Catcha and That Which Binds Us, has been updated to version 2.4.10, and I’m three and a half months late to the party.  This meant that I needed to update BASSGMS, my wrapper library that makes BASS and GameMaker understand each other, as well.  Oh, and I know very well the troubles that can occur with incompatible libraries due to version differences.  Yes… very well.


When I was doing my Master’s at UOIT, I used BASS and a precursor version of BASSGMS for one of my projects.  One day, my project kept crashing on my lab machine, yet it ran perfectly fine on my home computer.  I spent a long time looking over my code and even inserted test and debug functions into it to make sure the outputs were correct, but no matter what I did, the program still kept crashing in the lab but not at home.  I forgot what gave me the idea, but after several hours I decided to look at the version numbers on the BASS DLL on both the lab and home computers.  It turned out that the DLL on the lab machine was a few revisions behind, so I downloaded the latest version of it and, lo and behold, the program stopped crashing.  And then I was enlightened.

*flash forward*

So anyway, I fired up Visual C++ and recompiled BASSGMS, no problem here.  I also took the opportunity to give GameMaker more control over BASS by add more functionality to BASSGMS.  In the end, I created a GameMaker:Studio application to test out the new and improved BASSGMS 0.3, which does things that are probably not even needed in my current game projects, like tempo control and monitoring CPU usage, but it’s still nice to have them there for future projects.

Not captured in picture:  animated, cycling rainbow effect.
Most likely not need in either project.
Copyright © Quadolor Games. All rights reserved.

Time really flies you’re eagerly awaiting something.

I haven’t been working on Gonna Catcha as much this past week, mostly because I was distracted by the Toronto Game Jam that is happening next weekend: coming up with ideas and eagerly awaiting the confirmation email.  Today, I received note that my team was still on the waiting list of participants (they received ~100 more registrations than spots available).  Here’s hoping that additional spots will become available in the coming week.

I’ve been working on some ideas for the theme music for the TOJam project, this is what I have so far:

Now back to our regularly scheduled programming…

The last thing I was working on for Gonna Catcha was the pathfinding for the Vengeful (left) and Bashful (right) spirits.

As described in this post, Vengeful spirits move toward the position of the player while Bashful spirits move away from the player.  For the former, GameMaker has built-in functions for grid-based pathfinding.  “This will make my job a whole lot easier”, or so I thought. *DUN DUN DUUUUN*
It turned out that the grid-based pathfinding system makes some assumptions on how you’ve setup you sprites, objects and levels (the wording in the documentation does hint to this).  To get the best results, you’ll need to design your game to accommodate the pathfinding system.  Unfortunately, Gonna Catcha is not one of those games.  It bows down to no one.

Below are some screenshots of different test cases with the pathfinding system.  I varied different attributes such as grid cell size and sprite origins.  The paths the Vengeful spirit takes are drawn in white (click to expand):
One of the major issues that I saw in the tests was that the Vengeful spirit sprites were overlapping the walls as they moved through the maze.  This is because the pathfinding algorithm doesn’t take the size or origin of the sprite into account when finding the optimal path.  I did manage to find a combination of sprite settings and cell size that eliminated the overlap (in the bottom-right image), the latter happened to be the old 16×16 cells that I previously abandoned for stifling my creativity.  
There were other nit-picky things that didn’t make the built-in pathfinding system suitable for Gonna Catcha, so I ended up coding my own.  It’s not as sophisticated as the built-in system, but it gets the job done.  In addition, it solved the problem of coming up with a pathfinding algorithm for the fleeing Bashful spirits (which GameMaker doesn’t have natively).  All I did was invert the Vengeful spirits’ algorithm.
Copyright © Quadolor Games. All rights reserved.

Fighting file corruption and tightening up graphics

One of the biggest annoyances I face when coding something is when your program suddenly stops working for no apparent reason.  It happened this weekend when I was working on Gonna Catcha.

I was just going abut my usual business when all of a sudden the game would no longer run after compiling.  My guess was that the project got corrupted somehow, so I decided to make it anew.  GameMaker: Studio‘s ability to easily transfer resources between projects and the fact that the projects themselves are just large collections of image, audio and XML files made this relatively painless.

In the graphical department, I made some major changes.  Not being much of an animator, I had a lot of trouble doing the side walk cycles for each character.  As of my last post, I had something that looked like walking, but it still looked awkward.  After reading this tutorial (which I had previously encountered during my undergraduate studies in game development in the days of yore), I realized that I was missing a “Passing” frame in the walk cycle, and that I made it overly complicated.  So after much tweak, this is the end result:

I haven’t even finished Level 3 and I’ve already tightened up those graphics a little bit.

You may also notice two other changes in the above image: 1) I reduced the amount of arm swinging in the gun-away walk cycle.  I think I’ll reserve that amount of swag for a special occasion :), and 2) After doing a bit of research on the video capabilities of old arcade games (read: Pac-Man, mainly here and here), I’ve modified all the sprite palettes so that instead of each having 4 colours from a 16-colour palette, i.e, this:

I think I need to fix my graphics drivers.
(Source: Wikipedia)

They each have 4 colours from a 256-colour palette, i.e. this:

Ah, 256-colour.  My arch-nemesis in Microsoft Paint back in the 90s. Still dithering?
(Source: Wikipedia)

That should make things a little more, uh, colourful.  Yeah…

Before I finish this, I want to share a few interesting articles and whatnot I came across as I was doing research on ancient video game graphics.  I’ve already introduced three of them above:  a tutorial in animating a walk cycle: idleworm: animation tutorial – walk cycle part 1; and the two articles about the hardware used in Pac-Man machines:  Pacman hardware and Aaron’s MAME Memories Part 3.

Some other things I’ve encountered are this handy Color Bit Depth Reducer, which converts 24-bit TrueColor RGB or web hex values into the nearest values in other bit-depths and back again, and this old but free e-book about game graphics:  Designing Arcade Computer Game Graphics.

Hey, I can’t believe we got jobs doing this.
(Not intended for residents of anywhere.  Offer void in Nebraska.)
Copyright © Quadolor Games. All rights reserved.

Gonna Catcha: In-Game Testing

Status report:

Here’s some in-game test footage of Gonna Catcha, featuring Donum Dono as the test subject:

The video shows some tests on changing between animations depending on the state of the player:
  • Gun out or holstered: 2 states
  • Walking or standing:  2 states
  • Facing direction:  4 states
  • Total combinations:  16 states
It also shows some projectiles and the death sequence, which I will never get tired off (*Not a guarantee, I guarantee.)  You may have noticed that Donum sometimes jumps in position whenever he hits a wall.  That’s just my squeeze-the-player-around-the-corner code that still has some bugs to work out.  At least it’s better than what I had initially:

Outside of coding and pushing pixels, I’ve cleaned up and coloured in the sketch of Donum from my last post.  Now he’s no longer confined in a 64-pixel prison.

“*gasp* I’ve been vectored and coloured!”

I also made him the temporary face of my YouTube channel and Twitter:

“Uh, I don’t feel right about accepting this position without asking Pohena first.”

Enjoy it while it lasts; I might have other ideas about branding in the future.

Copyright © Quadolor Games. All rights reserved.

Gonna Catcha – An arcade-style maze game [Updated 4/3/2013]

UPDATE 4/3/2013:  This page is deprecated.  Here’s the more up-to-date page:

UPDATE 3/17/2013:  Woo!  Coloured portraits!

The time has finally come; allow me to introduce my new game project.

Game Info

The game is called Gonna Catcha, an arcade-style maze game where the player(s) assume the role of one of two psychopomps in their duty to get spirits to where they belong.  What’s a psychopomp?  You know, those guys that guide spirits of the dead into the afterlife.  You knowthese guys.

The names of the two player characters are Pohenas Das (left) and Donum Dono (right). Pohena is in charge of collecting evil spirits while Donum is in charge of collecting the good ones.  Each psychopomp will have different game mechanics reflecting their different jobs:

  • Pohena must subdue evil spirits before collecting them and take care to not get defeated by them or accidentally attack good spirits (who serve as obstacles).
  • Donum must attract good spirits to come to him and take care not to accidentally attract or get defeated by evil spirits (who serve as hazards).

In 1-player mode, the player will alternate playing as Pohena and Donum between stages (or sets of stages). 2-player alternating will essentially be the same thing, except with two game sessions intertwined.  Finally, 2-player co-op will have each player taking the role of one psychopomp and may involve a different set of stages.


Right now, I have the following options:  Windows, HTML5 and Android.  Windows is the easiest, so I’ll target that first.  With a few tweaks, I can get it running on my website as an HTML5 game; Android might take a while longer.


I’ve introduced the main characters briefly above, but I’ve written some more detailed character bios on a page linked below.  It will be updated as time goes now and I flesh them out some more.


Below are some concept sprite art.  I chose to use a 4-colour palette for each character to emulate the look of old arcade games.  I also included a 16-colour sprite for each character to demonstrate their actual colour palettes.


And last, but definitely not least, the theme music.  Since I have an arcade-style game with arcade-style sprites. why not go the whole nine yards?

Release Date


That’s all I have to say for now.  Stay tuned for updates!


Copyright © Quadolor Games. All rights reserved.

Stopgap Post

I wanted to make this post after I had gotten all of the stuff I wanted to say organized, but it was taking far too long.  And the fact that I haven’t made a post in a long time, I decided to post what I have so far.  Don’t worry, this blog isn’t dead yet.

I have good news, bad news, and better news.

The good news is, the font caching bug is now fixed:

Hurrah, hurrah

The bad news is I’m suspending the development of Sticks and Stones until I can think of a new theme for the game, as I don’t like the one I had in mind anymore.  Even if I can’t come up with one, at least I have the beginnings of a 2D adventure game engine that I can use for other projects.

The better news is I’ve got a new project idea, one that is more traditional and less experimental.  Once I gather all the information, I’ll post it here.  Stay tuned for updates!

Copyright © Quadolor Games. All rights reserved.

Go home Font Caching, you are drunk.

I didn’t expect myself to post so much in such a short time frame, but this is too amusing to pass up.  I was just messing around with Stick and Stones for a little bit when suddenly this happens:

Have you been hanging out with Zalgo?
The newest update of GameMaker: Studio (v.1.1.805) changed the way fonts are handled.  As I understand it, instead of caching the font at compile time, it now caches it whenever you make and save any changes to the font resource within the project (e.g. changing the font itself, size, style, character set included, etc.).  This way, if you have multiple people collaborating on the same project on different computers, only the person who created the font resource needs the original font file; everyone else will just use the cached font on the texture page(s):

“Somebody please put me out of my misery.”
(Note: Black background added for clarity)

As you can see, this new method still has some bugs to work out, and for my project that’s entirely text-based, this is an obvious problem that needs to be addressed.  Fortunately, the devs have taken note of this and are working to fix it.  The workaround they suggested is to recreate the font resource and delete the old one every time you make a any change to it, which is a bit of a bother.

Copyright © Quadolor Games. All rights reserved.