Gonna Catcha: Steam Greenlight and future plans

I’m pleased to announce that Gonna Catcha is now on Steam Greenlight! If you would like to see the game on Steam, be sure to vote “Yes” on the Greenlight page.

In light of this occasion, I’ve fixed up the trailer for the game:

Regardless of the status of the game’s Greenlight process, I plan on restarting development on Gonna Catcha some time in the future, adding new features and game modes. Here’s a summary of what I plan to do:

Score Attack mode

Gonna Catcha’s current gameplay has you play through a series of increasingly difficult rounds to see how far you can get and what is the highest score you can reach. In the planned Score Attack mode, you’ll play only one time-limited round to try to get the highest score possible. My plan is to make it come in three flavours:

  • Single-player: one person plays, self-explanatory.
  • Co-op: two people play as Pohena and Donum, working together.
  • Versus: two people play as the same character (two Pohenas or Donums), working against each other.

Change in Graphic and Audio styles

Currently Gonna Catcha sports an art and audio style defined by limitations inspired by the Namco Pac-Man hardware. While it has it’s own charm, I am prepared to push these limitations higher, perhaps forward half a decade to turn it into something from the latter half of the 1980s. (My baseline is a style like Bubble Bobble.)

Additional Mazes

The game in its current state has four mazes spread across 16 rounds, which cycle endlessly. I plan on adding new mazes to the game, though I still have to figure out how these new mazes will fit in with the current game progression.

Copyright © Quadolor Games. All rights reserved.

Eaten… by some… Linux, or something.

Gonna Catcha v.1.1.1 has been released! And much sooner than I expected. This version also marks the first release of Gonna Catcha on Linux (so far only tested it on Ubuntu-based Linux Mint).

Minty fresh.

On the technical side of things, I overhauled the graphics code to make the game’s codebase compatible with GameMaker: Studio 1.3. Up until release, Gonna Catcha was written with GM:S 1.2. When I tried to run the game in 1.3 (which was released as a beta) for the first time, I was greeted with this:

Gonna Catcha is now F2P.
You get the other 8/9 of the screen as paid DLC.
$10 for each ninth.

One of the big changes in 1.3 was the major changes to how it drew stuff on screen. I naturally assumed that the update broke my graphics upscaling kludge code.

#GameMakerStudio 1.3 changed up the 2D graphics engine, breaking my game slightly. Good thing I didn’t delay the release any further.
— Quadolor Games (@QuadolorGames) March 15, 2014

Since I had read that the changes to the drawing engine in 1.3 made it much easier to upscale graphics pixel-perfectly and therefore made my workaround obsolete, I decided to rewrite Gonna Catcha‘s graphics code in accordance to the new method of upscaling.

About an hour later, I had finished the rewrite. I tried running the game again, hopeful that the problem was solved:

*cue losing horns*

Thank you internet!

Well, that was a bust. The 1.3 update didn’t break my old graphics code after all. After another hour of probing my code, I finally found what was causing the problem. It seems that the function that toggles between windowed and fullscreen modes was preventing the window size from being changed. Not knowing if this was a bug or feature at the time, I just implemented workaround to get around it. Yes, I wrote out a workaround from my game just to write in another workaround. Based on other people’s reports on the problem, now I’m beginning to think that it’s a bug.

The rest of the updates are just bug fixes and interface improvements:

  • Fixed a bug where movement keys would get “stuck” if they were pressed or released while the game was paused.
  • Fixed a bug where lives were not being counted correctly after one player borrows a life.
  • Factory Reset now properly resets [Borrow Life] for both players.
  • Default key for [Borrow Life] (Player 2) moved from the 2 key to the 9 key (only takes into effect if you install a fresh copy of the game or do a Factory Reset).
  • Credits screen can now be exited by pressing any key or Start, Back or A on a controller (formerly just Esc).
It seems that by solving one big problem, the life-borrowing mechanic create a few small ones. Also, I moved the default key that allows Player 2 to borrow a life from 2 to 9 because it didn’t make much sense for it to be on Player 1’s side of the keyboard.
Copyright © Quadolor Games. All rights reserved.

Hey buddy, spare an extra life?

Gonna Catcha 1.1.0 is out now! Short version, here are the changes since v.1.0.0-B:

  • Added life-borrowing in co-op mode. If one player has lost all their lives but the other has some in reserve, then the first player can borrow one and resume playing the current round.
  • Added “Online Help” in Service Mode. Opens an online copy of the documentation in a web browser.
  • When player(s) die due to the timer expiring, their spirits-in-hand are released one at a time instead of all at once. This makes it consistent with the game’s other death scenarios.
  • Background music in tutorials now loop.
  • Reduced startup time for Preta tutorials.
Looooooooong version…
  • Added life-borrowing in co-op mode. If one player has lost all their lives but the other has some in reserve, then the first player can borrow one and resume playing the current round.

In many of my co-op mode playtests, I would often see the following scenario: one player would lose all their lives quickly due to inexperience while the other managed to keep on trucking and finish a round by themselves, allowing the other player to come back. However, the first player would lose their “continue life” very quickly and would have to again wait for the other player to beat the round by themselves before they could come back. And the cycle repeated. This seemed like a very boring and passive experience for the inexperienced player, but at the time I couldn’t think of a way to alleviate it.
It wasn’t until it happened again a few days after v.1.0.0-B was released, during a playthrough with me playing with someone new to the game, that the solution came to me: allow life-borrowing between players. It was so simple and done many times before in other games; I was surprised that I didn’t think of it sooner. Now if one player loses all their lives, they can borrow (read: take) a life from the other, provided that they have extra lives in stock, and continue to play the current round.
But take note, just because you have the opportunity to borrow lives doesn’t mean it’s always tactful to do so. If one player borrows a life and then both players finish the current round alive, the player that borrowed a life won’t get a “continue life” in the next round (or the “single point of shame”), because they are only granted to players in a “game over” state, i.e. is dead and have no lives remaining. So think carefully about the pros and cons before you borrow one of your partner’s lives. Or not.

I added this to future-proof the game, if I decide to bring the game to platforms that don’t allow or don’t have easy access to an external manual file on a local drive, e.g. HTML5, Steam Workshop. It also adds redundancy for the platforms that have local help files, which is… good…. in this particular case? I think.

  • When player(s) die due to the timer expiring, their spirits-in-hand are released one at a time instead of all at once. This makes it consistent with the game’s other death scenarios.

This was an oversight of a rare occurrence; the timer rarely went down to zero in all my playtests, so I didn’t notice that a death in that case resulted in the (really) old spirit-releasing behaviour.

  • Background music in tutorials now loop.
Small bug fix.

  • Reduced startup time for Preta tutorials.
I noticed that nearly all first-time players skipped the first preta tutorial (the one after the first bonus round) by mistake. My best guess as to why this was happening is: there were several seconds of inactivity at the beginning of the tutorial, which made it look like the game was frozen or required some kind of player input to start. This lead to players pressing random buttons to try to “fix” the problem but it only lead to them skipping the tutorial completely and have no idea how to deal with the pretas. Hopefully by speeding up the start of the tutorial, I can prevent people from accidentally skipping it.
Copyright © Quadolor Games. All rights reserved.

Going Gold [Updated 3/14/14]


That’s right, Gonna Catcha is being officially released at the end of this week! Available now!

It will be available on itch.io starting tomorrow (March 14, 2014).

Even though I did get the game working on an Ubuntu virtual machine (Linux Mint) a while back:

Meanwhile, on #Linux. #gamemakerstudio #ubuntu pic.twitter.com/zNyA5IlKCn
— Quadolor Games (@QuadolorGames) February 15, 2014

I still need to do some more work to prepare the game for distribution on that platform, so the game will be Windows-only for the time being.


What else…? Oh right, the issue of payment. The exchange of money for goods and services. Gonna Catcha will be available as a pay-what-you-want title with no minimum.


Whoa, it’s being a while since I posted here. I’ve been so busy getting Gonna Catcha ready for release that I haven’t had the time to make posts. Well, I tried but the post got so long that I got bored of writing it.

There was a video I wanted to accompany another post I wanted to write, but I think I’ll just show it here. During the development of the game, I noticed that the attract mode demo would end in one of two outcomes seemingly at random, despite there being only one set of input files and a fixed seed for the random number generator. Eventually, I discovered what determined which outcome would occur, whether controller input was enabled or not.



That was okay.
I did fix a bug that allowed a player to control/interfere with the attract mode demo using a controller, but this glitch didn’t go away. Here’s the kicker: even non-deterministic elements of the game, the ones influenced by the RNG, i.e. the paths the Wandering and Straying spirits take and the random item that appears near the bottom of the maze are also different between the two outcomes, even though the RNG seed was fixed. Oh well, I think I’ll leave it in; it gives the game character.

Can we go now?

Copyright © Quadolor Games. All rights reserved.

Excellent, it’s all falling into place.

Gonna Catcha 0.9.2rc is available for download. The “rc” is for “really cool!”. Actually, no, it stands for “release candidate”, meaning it’s ready to go, barring it destroying the world in the next few days somehow. You can find the download link on the game page.

For now, the download is only available on IndieDB because I got tired of Comodo Dragon (Chromium-based) and Internet Explorer (lol) telling me the downloads from my domain (quadolorgames.com) and Dropbox are “dangerous” because they’re new kids on the internet block. Firefox doesn’t seem to care though.

I haven’t had time to prepare a proper blog post to describe the release of v0.9.2rc in detail; I had been going out and getting people to playtest the game. And no, I don’t feel like getting in a debate about whether this post is technically “proper” or not. In any case, I’ll be making another soon, which will include something peculiar I’ve noticed about one part of Gonna Catcha.

While I wait to see if Gonna Catcha will trigger the apocalypse, I’ll be focusing on trying to increase the marketability of the game. In other words, the description pages of this game on this blog and IndieDB are a mess and really need to be updated and cleaned up. That should be fun.

Copyright © Quadolor Games. All rights reserved.

Spit shinin’ the ol’ game, make ‘er all nice and pretty.

Gonna Catcha v.0.9.1 is now available for download from the game’s info page. It is largely a “polish” update; I’m tweaking things here and there to start finalizing the game. Here is a summary of what was updated:
Improved movement around corners, as discussed in my previous post.
Bumped up the score requirements for getting extra lives, from 20k/40k/60k… to 20k/50k/80k… I felt that getting extra lives was a bit too easy in previous versions, especially in the later levels where points are more abundant. Players are reminded of the requirements on the title screen.
Updated the user interface. If either player gets more than 5 lives, the lives counter just draws one icon and then the number of lives. (Shown in above screenshot, sort of. Just imagine a number beside Donum’s icon on the lower-left.) Before it would keep drawing icons the more lives a player has, eventually intruding on the space of the round counter and the other player’s life icons. I was surprised it took me this long to realize this problem. In addition to that, I’ve added small indications that appear when a player picks up a power-up item (P): “LOnG” for the first pickup that extends shot range, and “DBL” for the second that gives the player a double shot. Before this friendly reminder, the power-up item was the only item that did not obviously indicate what it does.
Rewrote the help manual and changelog as a Compiled HTML Help file (CHM). Now in colour! Images, links, and an index! Multimedia for the win! But seriously, the manual looks much better and easier to use now.
Lastly, I updated the “Starring” screen to include the new, and possibly finalized, Chinese names for the characters. This time I opted for a transliteration than is biased towards the pronunciation of each Hanzi rather than the meaning,, using this chart as a basis. 
Pohena Das: 波伊娜 ・ 達絲 (Trad.) / 波伊娜 ・ 达丝 (Simp.)
Mandarin (Pinyin): bo1 yi1 na4   da2 si1
Cantonese (Yale): bo1 yi1 naa4   daat6 si1
Donum Dono: 多南姆 ・ 多儺 (Trad.) / 多南姆 ・ 多傩 (Simp.)
Mandarin (Pinyin): duo1 nan2 mu3   duo1 nuo2
Cantonese (Yale): do1 naam4 mou5   do1 no4
The problem I had with Pohena’s old name (魄伊娜) was that the Cantonese pronunciation for it didn’t sound very nice (paak3 yi1 naa4), and being the Chinese dialect I grew up with, it was gnawing at the back of my head. It does work very well in Mandarin (po4) though and its meaning is relevant (魄 = “soul, spirit”), but still. As a compromise, her name is now 波伊娜. I had a similar problem with Donum old name; actually, it was much worse: 當納睦 ・ 當儺, dong1 naap6 muk6   dong1 no4. I also decided to simplify his name and came up with 多南姆 ・ 多儺. Fun fact: his last name, 多儺, can be interpreted as “many exorcisms of evil spirits”. It would fit Pohena better, but meh.
I plan on rewriting the bio pages on this website, not just to update the names, but because the info on there is out-of-date. The lore of the Gonna Catcha universe has changed since I put that page up. I’ve also considered incorporating it and the other extended descriptions of the game linked on the game’s info page to the manual. That will be part of my next update.

P.S. The Japanese transcriptions for their names are unchanged for now: ポイナ・ダス (Poina Dasu) and ドナム・ドノー (Donamu Donō). I don’t know why I decided to put that out there.

P.P.S. Wish I knew something about transcribing to Korean Hangul… and Vietnamese.
Copyright © Quadolor Games. All rights reserved.

Today: Improving movement around corners in Gonna Catcha. Tomorrow: Humour check-up

In my various playtests of Gonna Catcha, I have noticed that many players were having difficulty trying to turn at intersections, going from one corridor to another perpendicular corridor. The solution I came up with was simple, yet I still managed to write this whole blog entry about it, so here goes.

Gonna Catcha uses a smooth, grid-based movement system, as in, even though the players move smoothly, they will always be aligned with the grid that divides the play area when stopped. This is to facilitate players in lining up properly intersections and going around wall corners, instead of having the player painstakingly line themselves up with pixel-perfect precision. Even with this alignment aid, I’ve noticed in my playtests that players were still having problems negotiating those corners.
To explain this better, below is a figure showing five different cases where a player is approaching an intersection (click on it and any other figure to expand):

Figure 1. Five cases of a player approaching an intersection

The figure shows two horizontal corridors linked by an opening between them. In cases 1 and 5, the player is not aligned with the opening; in cases 2 and 4, the player is partially-aligned, and in case 3 the player is fully-aligned.

The next figure shows what happens when the player holds [Up] to try to move upwards in each case:

Figure 2. Results of holding [Up]
As expected, in cases 1 and 5 the player cannot move upwards since they are completely blocked by the wall; and in case 3, the player is free to move upwards since there are no obstructions in the way. The problematic cases are 2 and 4; where the player is partially obstructed by a wall, which for all intents and purposes counts as being fully-obstructed by the game. In most of my playtests, players end up in cases 2 or 4 when they try to turn too early, and they end up getting snagged in corners, which was a bit frustrating to them.
For a long time, I’ve thought about whether to fix this problem, or just leave it in as a “quirk” of the game’s movement system that players need to get used to in order to get good at the game. Many games in the 1980s did have control schemes that had quirks or little annoyances that players needed to learn to in order to master them (I’m looking at you, Bubble Bobble, Ice Climber and Super Mario Bros.).

One day, out of boredom, I found my copy of Midway Arcade Treasures 2, an emulated collection of old Midway arcade games. I only played it a few times on my Gamecube a long time ago, so I decided to give it another chance and popped it in my Wii. After chopping down trees in Timber and crashing cars in Hard Drivin’, I played a game that caught my attention: Wizard of Wor, an action maze game from the magical year of 1981:
The basic premise of of the game is you and a partner must shoot and kill all the monsters in a maze-like dungeon to move on to the next one. The partner can be another human player or, if you’re playing alone, a computer player with limited intelligence. From what I’ve seen, the players’ movements aren’t confined to a grid like in Gonna Catcha. However (and this is the whole point of me mentioning this game in this post), the game had no problems with players getting caught in corners, as the player characters would “hug” the corners if they were close enough to one. In technical terms, the player would move in the direction perpendicular to the direction the joystick is being held, towards the nearest intersection if one was close enough. Confused? Don’t worry, there will be figures soon.
This got me thinking, if an actual early-1980s arcade maze game could handle intersections like this, then Gonna Catcha should be able to too. So I modified the movement code (something I haven’t touched in a long time) to make it handle corners and intersections like Wizard of Wor (and likely the multitude of maze games that came after it). The figure below shows the results of holding [Up] in each case with the new movement system:
Figure 3. Results of holding “Up” in the new movement system
Cases 1and 5 remain the same, however in cases 2 and 4, the player will now scoot around the corner of the nearest intersection if they are partially-aligned with it. Playtesting the game with the new movement system, I can say for certain that turning around corners is now much easier and smoother. One other thing I noticed when I was playtesting was that I had coded the movement direction and the way the sprite faces independent of each other. Before this change, the player’s movement and facing were always in sync, so I never noticed it, but now that there are cases where they’re not in sync, and in those cases it looks like the player is sidestepping or strafing around a corner. Technically, this is a graphical glitch, but I think I will allow it, because it looks cool.

The v.0.9.1 update will be coming soon. It’s not the finalized version of the game, the later levels are still unbalanced and possibly impossible to beat, but I am one step closer to it.

Copyright © Quadolor Games. All rights reserved.

The end is nigh. Muwahahahahaha!

It is a joyous occasion; Gonna Catcha is now feature-complete. Everything I set out to do with the game is done aside from a few tweaks here and there. In v.0.9.0, I made two major sets of additions, along with some minor improvements.
The first set of additions are two additional screens in the attract mode. The first one is a brief introduction to all the characters in the game, and idea I borrowed from Mappy:
Meet the folks.
The game itself did not have any detailed depictions of the two main characters Pohena and Donum, so I put (relatively) large portraits of the two on this screen. Both still adhere to the 4-colour palette limitations of all sprites in the game, if you break them down into individual 8×8 tiles. (It was actually much easier to do than I imagined.)
After the introductions, the attract mode switches to a gameplay demo. This where the game’s autoplay system plays back one of my attempts at beating the first round with both characters. As was the style at the time, the attempt was poor.
You suck at this game!
I’ll buy YOU for a dollar!
The second set of additions are the tutorial sequences that teach players how to play the game, replacing the instructions screen in the previous version.
… …
Yeah, I got nothing.
The tutorials demonstrate, by example, the basic rules of the game: what each player character’s job is and what they can or cannot shoot. There are four in all; they are shown before Rounds 1, 2, 3 and 8.
Copyright © Quadolor Games. All rights reserved.

This game plays so good, it plays itself.

Welcome to the first post of 2014! I’ll been working on the autoplay system (for the “How To Play” segments and the attract mode) for Gonna Catcha since the last time I posted. And since it’s also been a while since I uploaded something on my Youtube channel, let’s make it a twofer; here’s a short video of it being tested:

As I was coding this, I realized that creating the autoplay system would have been a lot easier if I was using Game Maker 8.1 instead of GameMaker:Studio to make this game. That’s because games made with Game Maker 8.1 could be coded to be dynamic at runtime. That is, you could add, remove or change graphics, sounds, rooms and even code while the game is running.

So what does dynamically-generated game assets have to do with the game playing itself? Well, the assets of interest in all of this are timelines, a series of code snippets that are run at assigned steps in time. Once a timeline is assigned to an instance and is set to run, it will automatically fire off the code snippets at their predetermined times. If I was using Game Maker 8.1, I could record player input to a file and then save it to the disk. Later, when I want to play the input back for demo purposes, I could read the data from the file, translate it into a dynamically-generated timeline and let Game Maker (and my player input code) handle the rest.

Unfortunately, due to cross-platform incompatibilities, the ability to dynamically add and change game assets at runtime had been restricted in GameMaker:Studio. In particular, most of the dynamic coding functions are gone. Fortunately, the all of the dynamic timeline functions survived the cut; well, all of them EXCEPT the function that allows you to ADD new code to a timeline. Without this function, this function, it is impossible to created new timelines with new code from scratch on-the-fly, pretty much destroying the above method of creating an autoplay system with a surgical strike.

In light of that, I tried to think of other ways to do this. First, I tried to record the player input into a human-readable format then manually translate and hardcode it into a timeline. However, this method was too tedious and took way too long to do, and if I wanted to re-record a play session, I would have to retranslate everything from scratch. Next I tried to build the timeline from scratch, but it was also too tedious since it was too hard to predict NPC movements, even though the random seed was fixed.

In the end, I decided to create my own timeline system. It’s not as through or functional as GameMaker:Studio‘s native timeline system, as it can only take control of the player characters, but it’ll do.

Copyright © Quadolor Games. All rights reserved.

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.