Update on Feast for the Senses

I didn’t have a substantial amount of stuff to talk about in the past month, that is until last week came along and really pushed that amount over the top. So here’s my long post updating you on the progress of Feast for the Senses:

New Monster Types: Taste-class and Smell-class

The game’s title “Feast for the Senses” came from the idea of all the enemies being based on the five traditional senses (sight, hearing, taste, smell, and touch). I had finished implementing the Sight- and Hearing-class monsters for a long time now and demoed them in my various gameplay test videos. However, I got sidetracked by working on other features of the game and left making the rest of the enemy types on the back burner, especially the poor, half-done Taste-class monster.

Taste Testing

The Taste-class monster is immobile, so it relies on spread a network of detectors to find the player. My initial implementation had it growing a maze-like network of tongue-like appendages to detect the player’s location and shoot directly at that spot hoping to hit them. Unfortunately, I encountered many bugs and other issues with how the tongue-growing algorithm (it was essential a maze-generating algorithm running inside an already labyrinth environment YO DAWG, I HERD U LIKE MAZES…) and decided to put it on the shelf so I could focus on other things. After several months, I eventually got around to working on them again and re-worked them with a simpler detector-spreading algorithm. Instead of tongue-like appendages, they now spread “buds” in a haphazard fashion around themselves. They do the exact same job, but with better and less buggy coverage. I also changed their method of attack from a straight shot to a lobbed shot. Their buds can potentially grow around walls, in places where the monster would not have direct line-of-sight (er, line-of-shot?) with the player. Lobbing the shots would outcome this problem.

Click to see an animated version

Stop and Smell the Réiltín

This past week I’ve worked on the beginnings of the Smell-class monster. They use a simpler, modified potential field algorithm to find the player’s position, inspired by some similar techniques used for some monsters who track the player by scent in traditional roguelikes I found by trawling the internet.

The map is divided into a grid of nodes; each node has a value representing the strength of the player’s scent. Every step, the node the player is floating above is incremented by a constant; the surrounding nodes are also incremented but by a smaller number. Then, at the end of every step, the scent at every node undergoes decay; reduced by a certain percentage. If an idle Smell-class monster is standing on a node above a certain threshold, it would go into chase mode. In this mode, the monster will check all neighbouring nodes and move towards the one with the highest scent value, until it reaches the player and goes into attack mode or loses the scent and goes back to idle mode. Compared to the Sight-, Hearing-, and Bearer-class monsters, who all use GameMaker:Studio‘s potential field algorithm for pathfinding, the movement of Smell-class are clumsier and more predictable, but (to my surprise) they are able to track the player over longer distances and behind obstacles much better.

Click to see animated version


For an extended look at the tests, watch the following video:

Transitions and Other Interface Improvements

On the interface side, I made some additions:

  • For all menus, I added some simple fade-to-and-from-black transitions between menus and the game rooms to visually ease the switching between and added some sound effects to that play when interacting with the menus. All in the name of feedback principles, UX design, etc., blah blah blah.
  • A new menu was added where you choose the level you want to play in Arena mode, now separate from the main menu. Each level now has weapon restrictions or loadouts, represented by the icons on the right side of the screen.
  • Finally, I added a pause feature during gameplay. This was necessitated by the newly-added transitions mentioned in the first point. Otherwise, the game would behave weirdly when moving from a game room back to the arena menu. In the video above, the reason I’m pausing seemingly willy-nilly is to make sure the audio cuts and resumes properly and that nothing disappears or breaks during the pause.

Gamma/Brightness Correction

When I took a look at the histogram of a screenshot of the game in Photoshop, I noticed that the range of luminance values was narrower than I expected. For a long time I had thought the game’s graphics were a bit dull, possibly due to all the colour mixing that goes on with the lighting engine. That inspired me to add a simple shader that changes the gamma level of the application surface. I’m experimenting with it to see if increasing the default gamma a bit will make the game look better or ruin the atmosphere. So far it seems like an improvement.

Left: Original gamma level (1.0). Right: Modified gamma level (1.2).

Holiday Post thing

Whoa, it seems like forever since my last post. Since the Bit Bazaar ended, I’ve been focusing my attention on many things, some regarding Gonna Catcha and some not. But there’s no time to explain them all here, so I’ll pick the most important one.

As I mentioned in my last post, Gonna Catcha was played in an arcade-style environment at the Bit Bazaar on December 7. Players weren’t be able to read the manual to figure out how to play the game, as it wasn’t available to them. So in an attempt to minimize confusion, I added the instructions screen below, which was shown just before the first round started.

Crash course in spirit catching.

It explained the basic rules and goal of the game, i.e. what you can and can’t touch, what you should and shouldn’t shoot and how to progress.

I didn’t arrive at the Bit Bazaar when it started, so I might have missed some of the early birds playtesting the game. The first people I saw playing didn’t seem to have too much trouble figuring out what to do, but as the day went by and more people played, it became apparent that the instruction screen wasn’t doing its job very well. My guess that it was too brief and too detailed at the same time, and that confused people about the rules of the game. It presented all of the shooting and touching rules for each NPC type all at once, but due to the lack of space, the descriptions of each rules were too laconic. By the end of the day, I was back to my old ways, explaining the game myself and skipping the instructions screen, and things went by a lot smoother.

In retrospect, the instructions screen was more of a band-aid solution than a real fix to the problem. Since it was a bust, I figured that I need to go to Plan B, which is to use demonstration cutscenes to explicitly show how the game is played. As such, on my to-do-list I’ve promoted “Demonstration cutscenes” from “Optional” to “Necessary”. I also grouped it together with “Attract mode” because the two have one thing in common: the ability for the game to play itself. But before I get into that,

Or kicked upstairs, whatever.

Ahem. So anyway, I’ve started working on the new instructions delivery method: new tutorial cutscenes that will replace the old instructions screen. Here is a screenshot of what it looks like so far:

Don’t fear him.
Essentially, it’s just a half-size level that plays itself to teach new players how to play the game. And speaking of playing itself, I’ve also started on making the autoplay system too. I think I’ve got the playback system working pretty well, the recording system on the other hand, which is only here to help me record gameplay to be played back by the autoplay system and may not be part of the final product, has a few bugs to work out. For starters, it generated a 500+ MB output file when it was only supposed to be a few kilobytes in size.

I feel bloated… ugh.

The recording code is working much better now. I’ll go into more detail about in a later post, because this one really needs to get out there. I don’t know when, because it’s the holiday season, with the whoop-de-do and hickory-dock. And don’t forget to hang up your sock, ’cause just exactly at 12 o’clock, he’ll be coming down the chimney, down.

P.S. Now that I think about it, Donum and Pohena bears some similarities to Sinterklaas and Krampus of Alpine folklore.  Krampus punishes naughty children while Sinterklaas rewards good children. Pohena and Donum does the same with spirits, according to the supplementary material.

Copyright © Quadolor Games. All rights reserved.

Two-player action!

This week, I switched gears and went back to mainly working on Gonna Catcha, in particular the co-op mode. Things have been more difficult than I imagined. You’d think that with a game that screams “CO-OP GAMEPLAY!!! (Oh, and you can play solo too.)” I would have designed and coded the co-op part first or at least made the single-player mode in a way that would be easily expanded to co-op gameplay.

Well apparently I didn’t.

For the sake of simplicity, I designed and coded many of the features in the game around the single-player mode. It turned out that the code was so intimate with the single-player mode that it made coding the co-op mode difficult. To give you an idea of what I had to do, I pretty much had to tear out the code for various features from the game, smack the co-op version of that code onto them, then shove them back into the game. The results seem to be working so far, aside from a few hiccups:

But now the code design isn’t as pretty. Oh well, so much for my idealism.  It probably won’t matter in the end; I don’t think Gonna Catcha is resource-intensive enough for a few pieces of unoptimized code to have any impact on the performance of the game. When the co-op mode is working properly (for the most part), I’ll upload a video it, but for now, I give you the above. 

In other news, there was some footage of a “whoopsie doodles” in the development of Rise & Fall that I forgot to upload last week. I think this is a rather common graphical glitch, but I find it amusing nonetheless:

Copyright © Quadolor Games. All rights reserved.

Where Is That Thing You Were Working On Several Weeks Ago Now?

Okay, I’ve held off publishing this post for two days now, time to stop writing and actually do it.

(But there just this tiny little thing I want to ad-)

Nope. We’ve live. Wait, who are “we”? I’m talking to myself again. Anyway…

On this episode of Where Is That Thing You Were Working On Several Weeks Ago Now?, or W.I.T.T.Y.W.W.O.S.W.A.N.? (“Witty Woss Wan”?), we have a gander at Rise & Fall. You know, the thing I worked on as part of the team Robots Mashing Keyboards for the ROM Game Jam. (Oooh, that thing.)

Quite a few things have been added or changed since the ROM Game Jam prototype. The biggest change is the inclusion of jump-through platforms (i.e. platforms that can be passed from below but not above). The original prototype only had completely solid platforms, but to have a greater number and density of platforms in the level, my team decided that we need to have jump-through platforms as well. Seeing how something like this should be Game Programming 101, I should have learned how to do a long time ago, but never did until now. Still, I had to learn it from the source code of this demo by Bill23. Even then, it took me two attempts to get it working right. Other changes are relatively minor, such as adding mercy invincibility, or bug fixes. We will also be changing up some the graphics and adding more levels before the playtest session at the ROM on October 19.

During the development of Rise & Fall, I had encountered the weirdest glitch I’ve ever seen in all my time using GameMaker, even weirder than the ones I’ve seen while working on Gonna Catcha. Furthermore, I don’t think it was (entirely) my fault:

It looked as though GameMaker didn’t rebuild the asset cache after I deleted some objects from the project, so the game ended up drawing the wrong sprites and even creating the wrong objects (i.e. the projectiles seemed to have been replaced with experimental wall section object I had been working on). Clearing the asset cache and rebuilding the game once more fixed everything.

Speaking of Gonna Catcha, nothing visually interesting has happened with it since the last update, so no video or screenshots for you. However, I did completely overhaul how the game handles round progression, now incorporating the NPC speed multiplier I talked about last time. Alright, that another task down for Gonna Catcha, what left? I really should make a list of these things.

Copyright © Quadolor Games. All rights reserved.

They’ve gone to plaid!

Today is the Mid-Autumn Festival and also various other full moon-related holidays in other parts of the world.  I thought it would be appropriate to post something about Gonna Catcha today because:

Mid-Autumn Festival –> harvest festival –> harvesting of souls –> psychopomps –> Pohena and Donum
Full moon –> werewolves –> wolves –> Pohena and Donum

Actually, I lied; this has nothing to do with any holiday, it’s just a coincidence. Anyways…

A week ago I posted a video of gameplay from the playable alpha of Gonna Catcha, and since then I’ve gotten some useful feedback and suggestions. One of them was the to increase the speed of the spirits and pretas as the game progresses. I thought this was a good idea, so I did just that: put in some code that allows the game to scale the enemy movement speeds:

16x speed is the maximum the game can handle; any higher will cause the spirits and pretas to break free from their imprisonment of the maze and shoot off into oblivion. However, anything higher than 2x just becomes too difficult and frustrating to play (even 2x was pushing it for me).
With this, I now have two ways of increasing the difficulty of the game:

  1. Increasing the speed of NPCs, and 
  2. Increasing the number of NPCs required to be captured and avoided in a round.

With the former, I think I won’t have to rely on the latter as much to scale the difficulty as the game progresses, I can ramp up the latter much quicker and make the early rounds less boring.

P.S.  On a serious note, today is also a sad day with the passing away of former Nintendo president Hiroshi Yamauchi: http://www.bbc.co.uk/news/technology-24160150
As someone who started gaming on the Famicom and Game Boy and now the owner of a Wii U and 3DS, this news hit me hard. May he rest in peace.

Great, now I feel awkward for publishing this post today.

Copyright © Quadolor Games. All rights reserved.

Home stretch to the playable demo!

The last gameplay video I showed of Gonna Catcha was kind of boring since it only showed the game at it’s easiest (since I only wrote the round data for the first few rounds). Yesterday, I uploaded a new video showing the latest version of the game played at a moderate level of difficulty, moderate-hard for the bonus rounds: 
Some changes since the last video:
  • All the pretas (“ghosts”) are now in action, each with their own unique behaviours:
The Hungry Ghost will seek out and consume any items it finds.  If not, then it will just wander around the maze aimlessly.
The Vagrant Ghost prioritizes shelter over hunger.  It slowly drags itself towards the shelter or jail.  Once it gets there, it will enter the shelter/jail and scare away/release two spirits (who go back into reserve), disappear for a while, then respawn to repeat the process.  The player can shoot the Vagrant Ghost to temporarily chase it away from the shelter/jail.
This guy, the Vile Ghost, is new.  Like the Hungry Ghost, it will seek out items and consume them. However, unlike its gluttonous cousin, it will chase after the player if it can’t find any items.  They are mainly found in Pohena rounds as an implacable danger much like evil spirits are to Donum.  The good spirits’ slowing effect on Pohena makes it easier for the Vile Ghost to catch up with her, so better stay away from all of them.

  • Re-evaluated the point system.
  • Implemented a “three strikes” system in regards to shooting good spirits.  If the player (as either character) shoots a good spirit, they will be penalized:  -500 points for the first offence, -1000 for the second and one life for the third.  The strikes reset whenever the player loses a life.

The only thing the game needs before I release it as a demo are additional mazes and data dictating what spirits and preta spawn for each round. The end is in sight!

In other, related news, I made a few updates to the Gonna Catcha and related info pages…

…and here’s a black wolf staring into your soul…

“You should be drawing more.”
… and a white wolf who somehow managed to clone himself accidentally:
Copyright © Quadolor Games. All rights reserved.

ROM Game Jam Day 3 Report – “Rise & Fall”

The ROM Game Jam is over and my team, Robots Mashing Keyboards, actually managed to create a fully-functioning game prototype by the deadline.  The fruits of our labour is Rise & Fall, a 2-player dueling action game based on two ancient cultures (which was the topic of the jam).

In Rise & Fall, one player takes the role of  Roman soldier while the other takes the role of an Egyptian soldier…
…who fight by launching projectiles at each other.  They each have four broken artifacts on their side of the arena.
If either player gets hit three times, they “die” and the opposing player gets a point. Each point half-fixes one of the player’s artifacts.  In the picture below, the pottery on the Roman (left) side is half-fixed.
When an artifact is fully repaired, it can interact with foreground objects, i.e. players are impeded by and can stand on it and it can block projectiles.
When an artifact is fully repaired for the first time, it’s name pops up on screen so you’ll know what it’s called and you can recognize it when you see it at the Royal Ontario Museum (that was their idea, by the way).
To win, a player must attain nine points: eight points for a full set of repaired artifacts…
…and the ninth point from the “coup de grâce”.
To the victor, goes his/her soldier running across the screen.
Here is a breakdown of who did what for Rise & Fall:
Idea guys (Game concept):  All of us
Pencil-, paper- & pixel-related tasks (Concept art, pixel art):  Shmuggly, Goombaguy

Computer keyboard masher (Programmer):  M.S.T.O.P.

Electronic keyboard masher (Music and sound effects):  M.S.T.O.P.
With us in spirit:  Saffy

We received lots of positive feedback from other jammers and, to my delight, the archaeologists that were helping us with the historical details of the ancient cultures we were making games about.  They all got really into it.  Also, due to all the hubbub in the room and the crappiness of my laptop speakers, the game’s music wasn’t heard very well. Here it is for you listening pleasure:

So what’s next for the game?  Well, the Royal Ontario Museum said they would like to demo all the games made at the game jam to museum patrons in October, giving us two months to work on and polish our games further.  Given the positive feedback we received, we are interested in pursuing this further. During the playtesting, we found a few bugs and gameplay balance issues that need to be ironed out, so it looks like we already have an idea on how to move forward with the project.  🙂
Copyright © Quadolor Games. All rights reserved.

ROM Game Jam Day 2 – So Very Tired

Oh man, today was a tiring day, I didn’t even have the extra energy to use Twitter to document my team’s process. Not to mention the confusion and delay when I was taking the subway to the ROM.  Oh well.

I was going to create another demo video of what we have so far, but then some new sprites arrived in my email and I just had to put them into the game and test them out.  It’s late and I don’t feel like re-recording and editing the video right now, so here’s a screenshot:

Roman guy vs. Egyptian guy
It’s too bad I’m not able to show you a video; the sprite animations and foreground objects are coming along nicely.  As you can see, we have a Roman guy and Egyptian guy dueling each other.  The Roman throws spears pilums (the archaeological experts at the ROM said the latter was more historically accurate) while the Egyptian shoots arrows. They fight each other to restore their own ancient culture’s artifacts for some unexplained reason and in some unexplained manner.  This has baffled and intrigued archaeologists for many minutes.  Tomorrow, we’ll finish off the rest of foreground objects, the backgrounds and whatever is left over (well, we have to since it’s the final day).

Copyright © Quadolor Games. All rights reserved.

This thing doesn’t have Free Play yet. Got any quarters?

Alright, it’s the moment you’ve all been waiting for. …Okay, some of you. …Okay, mostly me.

Here’s a video update of Gonna Catcha, showing the game in it’s current glory:

After playtesting the game for a bit, I’ve come to realize that the Pohena rounds are too easy.

Chasing around the fleeing Bashful Spirits (above left) while avoiding Vengeful Spirits (above right) provides a good challenge in Donum rounds, however the behaviours of the same two spirits make Pohena rounds a breeze. Bashful Spirits generally stay out of your way, reducing chances of friendly fire, while Vengeful Spirits home in on Pohena like lambs to the slaughter.  I haven’t put in the Hungry and Vagrant Ghosts in the game yet, but I don’t imagine them making Pohena rounds that much more difficult (they are designed more to be nuisances than threats).  In light of this, I made have to add additional types of spirits, one for good and one for evil, to balance out the gameplay.

Find out on the next exciting episode of Dragonba-  err, I mean Quadolor Dev Blog.

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.