music – Quadolor Games

Cat Concerto – Now with 80% less yowling!

mstop_4 Cat Project, music August 31, 2014October 27, 2014 0 Comment

(No, “Cat Concerto” is not the new name for “Cat Project”.)

I haven’t had much time to work on “Cat Project” this week; I had to take care of a friend’s dog and bird (no cats though, except for a surprise visitor in the backyard). So the game is pretty much the same as it was last week. However, I did get a chance to work on some of the background music for the game, which I’ve neglected to talk about since I started this project.

Currently, I have two tracks to show. To give a bit of background, both of them are “hand-me-down” tracks; music that was composed for other projects that got cancelled that I fixed up and remixed for this one. No point in letting them go to waste. The first one is the title theme:

I don’t know if it is technically a waltz (maybe it’s a minuet, or some perverted fusion of the two, who knows?), but I just call it that out of habit. In any case, it’s a fuzzy, lighthearted track that sets the mood for the game.

Next up is a level theme track thing; it’s a work-in-progress:

The vaguely “meow”-sounding lead synth in the second half of the track is a patch I accidentally made with fiddling and twiddling around with the knobs on the Dreamstation DXi2. It seems appropriate for the subject matter at hand and I kinda like it. I just hope the novelty doesn’t wear off to quickly.

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

mstop_4 gameplay, graphics, music, Rise & Fall, ROM Game Jam, testing August 11, 2013 0 Comment

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

Well isn’t this a motley crew of small updates.

mstop_4 administration, gameplay, Gonna Catcha, graphics, music July 14, 2013 0 Comment

In the past two weeks I’ve been mainly doing a little work here, some more over there and a tiny bit all the way over there. The updates are a bit difficult to stitch together into a coherent theme for a post, so I’m just going to list and itemize everything.

Item #1

Implemented the Hungry Ghost enemy into Gonna Catcha:

It’s current behaviour has it wander aimlessly in the maze like the Wandering and Straying Spirits. However, if there is an item in the maze, it will move towards, consume it and then resume wandering and feeling remorse. Also, you might kick yourself for not grabbing the item first. The Hungry Ghosts are harmful to touch at all times; they can be stunned or knocked out for a short period of time, but they cannot be captured, so they remain a permanent fixture in some rounds.

Item #2

Modified some of the rules for Pohena rounds: if Pohena comes into contact with a good spirit, her movement speed will be reduced until she is no longer touching one. They will slow her down enough for evil spirits or preta to catch up with and kill her. Hopefully (or disappointingly for Pohena) this will make good spirits more of an obstacle as evil spirits are for Donum.

Item #3

New music for Gonna Catcha: Bonus Round!

Item #4

Rewrote some of the graphical and garbage-collecting backend code. The new graphics code fixes some minor graphical glitches that occur when upscaling the game window.

Item #5

Updated various parts of the blog:

The rules section on the Gonna Catcha info page has been updated with the info in Item #2.
The descriptions of the non-player characters from this post are now on their own page, with the addition of the two new spirit types and slightly updated artwork for the spirits.
Rearranged some stuff on the sidebar on the right.

THE END

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

mstop_4 audio programming, BASS, BASSGMS, GameMaker: Studio, Gonna Catcha, graphics, music, other projects, raytracer, testing, That Which Binds Us June 2, 2013 0 Comment

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…

*flashback*

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.

*flashback*

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.

Update Double Feature!

mstop_4 Gonna Catcha, music, That Which Binds Us May 21, 2013 0 Comment

Gonna Catcha

Most of the work I’ve done on Gonna Catcha are behind-the-scenes coding stuff that won’t show up in screenshots. I need to fill in all the gaps (so to speak) so that I can release a proper demo version of the game as soon as possible.

The one thing I did that I can take a screenshot of is this:

All arcade games I’ve encountered run a self test to check their own hardware when switched on. To give my game a bit of authenticity, why not put one of these into it too, even if it is completely bogus and ironic. In fact, I might have a little fun with it. (twiddles fingers) >:)

That Which Binds Us

Our team still hammering out the details of the design document for That Which Binds Us. We have some concept art for some of the levels in the game, which I may put up here later.

One thing I can show right now is the main gameplay theme for the game. It’s pretty much what you’ll hear in the final game, barring any minor adjustments:

Next, I would like to take you back to that mystical time period known as the early 90s, when sound cards had synthesizers so bad that it turned the MIDI file into the scapegoat it is known as today. This is the same theme played using the Sound Blaster 16’s FM MIDI synthesizer. I actually started composing using this sound card (Sound Blaster 16) in the late 90s, so it holds a special place in my heart, even if it does sound bad. This track may or may not be in the final game; I just made it for fun.

Time really flies you’re eagerly awaiting something.

mstop_4 GameMaker: Studio, gameplay, Gonna Catcha, music, testing, That Which Binds Us, TOJam April 28, 2013 0 Comment

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.

A Race to Bottom… of Sound Chip Specs [Updated]

mstop_4 administration, audio programming, Gonna Catcha, music March 18, 2013 0 Comment

Update 3/18/2013 (6:21 PM):

EVERYTHING IS SUPER

HAVE A NICE DAY!

Well, it didn’t take long for things to go back to normal. Maybe I should’ve held off posting this just for a little while longer. Oh well.

As a bonus, here’s the coloured image of Pohena I meant to show earlier:

“I’m not a prize, you idiot.”

W-well, I didn’t mean it like that. Uh… awk-ward.

—

TECHNICAL DIFFICULTIES

PLEASE STAND BY

Well, it seems that in my attempt to reorganize the files on my “website”, I did something that caused all the images on this blog to break (Dammit, I’m a computer scientist, not a web administrator!). I’m in the process of getting that fixed.

In the meantime, let talk about something that doesn’t involve anything hosted on my site.

In my introductory post of Gonna Catcha, I posted this music sample from the project:

It was my attempt at emulating the style of music from 80s arcade games, without actually knowing how it was actually done. Being someone who spent 3 years working on a master’s thesis on computer-generated sound, this just simply wouldn’t do. Nope, nope, nope.avi.

As with the graphics, I turned to Pac-Man for inspiration:

The game used a chip called the Namco WSG to generate sound. It had 3 channels, each could play one of the 8 waveforms stored in 256 bytes of external memory (PROM). These waveforms could be customized to the sound guy’s heart’s content, which resulted in the highly-memorable audio of games such as Pac-Man.

This also stands in contrast to early PCs and early home consoles that came around the same time as or after it. Although some of them did allow custom waveforms either intentionally or via programming exploits, they mainly relied on programmable sound generators (PSG) that only played preset waveforms to generate sound. Some examples are (off the top of my head):

AY-3-9810 – found on earlier models of MSX computers
MOS Technology 6581/8580 (SID) – found on the Commodore 64
Ricoh 2A03/2A07 – found the NES

For comparison, listen to the NES port of Pac-Man:

Even though the sound generation of these chips weren’t as sophisticated (well, the SID was sophisticated in other ways), it didn’t stop them from being popular even to this day, even more than these old arcade chips.

Enough digression, time for the main event. After applying the knowledge above, I have created the following early-80s-style arcade-type music:

Track list: Donum Start ~ Donum Level ~ Donum Defeat ~ Pohena Start ~ Pohena Level ~ Pohena Defeat

I couldn’t find a way to generate 4-bit samples; everything I had to work with had a minimum bit resolution of 8 bits and the bitcrushers (a digital audio effect that reduces the number of bits used in an audio signal) I tried didn’t produce the desired results. So essentially, I doubled the amount of pretend PROM on my pretend arcade board and used 8-bit samples. Otherwise, I’m satisfied with the result, at least for now. Personally, I find both “Defeat” tracks to be quite funny.

My name is BASSGMS, I’ll be your interpreter for today

mstop_4 audio programming, GameMaker: Studio, music, Windows February 8, 2013 0 Comment

I’ve for a long time found GameMaker‘s audio engine to be too limiting. particularly in the background music department. That’s why I choose to use an external audio library to handle the background music.

Long story short, GameMaker only allows you to use MP3s for background music, and the only flexibility you have for it is whether you want it to loop back to the beginning or not when it reaches the end. That’s why I prefer to use MO3 modules for my background music. MO3s are tracker modules with MP3- or OGG-compressed samples rather than straight PCM samples. In simpler terms, MO3s combine MP3- or OGG-compressed samples with data on how to play those samples. Looping is internal to the MO3 itself and is seamless, allowing you to theoretically have an infinite-length MP3/OGG quality music in a few megabytes, or even less.

The only library I know of is BASS, whose developer, Ian Luck, also created the MO3 module format. Getting BASS to work with GameMaker isn’t as easy as just importing the DLL into the project. They can’t communicate with each other due to incompatible data types used in their functions.

I’m sorry, I don’t understand your funny accent.

(For those coders playing at home, GameMaker‘s only two types, real and string, are equivalent to the C types double and char* respectively.)

The solution was to create my own wrapper library, which I dubbed BASSGMS, that translates the functions in BASS in a way that GameMaker can work with. In the heart of BASSGMS (and any wrapper DLL I may create in the future) lies these magic words that make everything possible:

What is this sorcery?!

To this day, I still only have a vague understanding of how to code DLLs. All I know is it works like voodoo magic.