graphics – Quadolor Games

The Eternal War Between Light and Darkness

mstop_4 Feast for the Senses, graphics, interface March 15, 2016March 15, 2016 0 Comment

Hi everyone, welcome to another installment of me sitting in a corner thinking about what I did then writing about it.

I wanted to push out a blog post sooner, complete with a new gameplay video. However, the day after I uploaded it on Youtube, I made some major changes to the graphics and I was no longer satisfied with the video. So I had to make a new one and then start writing about that.

Before I go through it in detail, I’m just going to show you the new gameplay video and see if you can spot the changes:

Can you see what has changed. Go ahead, I’ll give you some time to think about it.

… … …

Ready? Alright, here we go:

Redundancy eliminated in graphics pipeline. Productivity up, but many lines of code now out of work

This first one is a bit unfair since it’s imperceptible: I rewrote the lighting rendering pipeline so that it works with GameMaker: Studio‘s native graphics pipeline rather than against it. This switch resulted in a 25% boost in framerate, though it’s not perceptible on my dev machine since it is able to render the game at over 60 fps. However, this might help some lower end machines run the game at the full framerate so they don’t have to cap it at 30.

Light and dark embrace more extremist positions

The way light and shadow are blended with the scene was also changed. In the old method, light and shadow were blended in using multiply blending implemented with GameMaker‘s built-in customizable blend modes. The new method uses overlay blending by means of a shader (there was no easy way of configuring GameMaker to draw using overlay blending). Below is a comparison of both methods:

Left: Old lighting using multiply blending | Right: New lighting using overlay blending

If you’re familiar with image editing programs like Photoshop or GIMP, then you should already know the differences between multiply and overlay blending and what they do. If not, then you can click on the links to get the technical explanation, or you can just look at the pretty pictures. The game now has access to a greater range of brightness values by using overlay blending; this not only makes bright areas look brighter but also makes dark areas darker, creating a a more striking contrast between the two:

The increased brightness also allowed me to enhance certain particle effects, such as making the fairy dust created by Réiltín look actually sparkly.

Increasing number of young lights join the occult

I fixed a long-standing problem with how the simple lights were drawn. In my engine, simple lights are lightweight (no pun intended) light sources that don’t cast shadows. They are used for things like lamps, muzzle and explosion flashes, and glow effects. Originally, these simple lights were drawn in post-processing, i.e. simply added on top of the regular (shadow-casting) light source. This had the effect of those lights shining through opaque objects when they should be occluded.

Should be. Could be. Would be. ARE:

In the screenshot above, the spiky hit flashes are properly occluded by the tree trunk in front of them. I left in the option of allowing simple lights to be drawn in post-processing, as demonstrated by the dead, flashing red monsters being drawn through the tree trunk.

Better minimap, better know a district

The minimap in the top-right is a fairly old feature, but before it only revealed the location of items relative to the Reiltin. In this update, it now also shows the location of enemies, walls, gates, decoys and proximity mines:

For proximity mines, the minimap also shows their activation range when primed and their area of effect when they explode:

I realize that giving all this information to the player really makes the game’s theme of obscuring things in the dark moot, but in the final game the player won’t have all this info all the time. They will have to use certain items or tools to get additional pieces of information.

Next time, on Feast for the Senses…

And here’s some leftover stuff I haven’t finished yet but still want to mention:

Non-rectangular levels: it’s not hip to be square

Up until this point, all the levels I had created for Feast for the Senses were rectangular, whether they be levels for the Arena, free roam exploration, or linear exploration. But what if I didn’t make them rectangular? Here is a irregularly-shaped linear-type level I’ve started working on:

It might not be apparent from this screenshot, but this level is huge. It’s the largest room I’ve ever created in GameMaker. I had to make the sections wide enough to accommodate gunfights and the entire level long enough so that the player doesn’t just blaze through it too quickly.

Birth of a new tileset, the miracle of… uh… graphic design?

I’m starting to get bored of seeing both tilesets that are currently in the game, you know what that means: it’s time to add a new one to the family! The one I have in mine is a little more involved than the others. It makes use of dynamic graphics…

The undulations are almost hypnotic. Yes…

Updates: Mostly Graphical, Some Audio, Some AI

mstop_4 enemy AI, Feast for the Senses, GameMaker: Studio, graphics, interface February 19, 2016February 19, 2016 0 Comment

A summary of the updates to Feast for the Senses from the past month. If you have been following along my Twitter, then most of this might already be familiar to you.

The Full Gathering of the Senses

So I finally got off my butt and finished implementing all five sense monster classes: Sight, Hearing, Taste, Smell, and Touch. I renamed the Bearer-class (who’s only job is to hold items until the player destroys them) to “Pain-class” to fit it in with the whole sense theme. Each class of monster now has their own set of vocalizations. I’d like to thank the contributors at freesound.org for letting me demonize their voices. 😛

Each monster type has it own way of detecting its victims, so they all have their unique behaviours. I will go into more detail in a future post:

Oh, that video also spoils the next two things I want to talk about:

Weapon Wheel

As I have been adding more and more weapons and items to the game, I found it awkward to switch between them using the d-pad. I know and played a few games that do this out of necessity because the right stick is mapped to a more important function, but then I realized I wasn’t using the right stick for anything. So, I changed the weapon/item selection system to a weapon wheel.

Since now every weapon and item is access via the weapon wheel, there is no longer any distinction between main and sub weapons, but since only a handful of people actually playtested the game during that phase of development, we can pretend it never happened. 😉

Refined Tileset

I also redesigned my tilesets to remove or tone down the detailed skeuomorphic elements, which were clashing with the simpler flat elements. Something bugged me about how I designed my tileset for a long time, and I think this might be the reason why. I also bumped up the vibrance of the colours a bit too, as I thought the levels were looking a bit too dreary, and that I know has been bugging me recently.

And for comparison, the old Grassy tileset…

…and the new Grassy tileset…

At first I was worried that having the grass as huge areas of flat green would make it look boring or make it hard to get a frame of reference when moving, but those grass tuft tiles that hug the sides walls, ground tiles and randomly strewn around everywhere really help make it look much better. Curiously, I don’t have any good screenshots of the old Marble tileset. They’re all either too small or animated GIFs. Because of that, I can’t do a fair comparison of the old and new Marble tilesets. Oh well.

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

ROM Game Jam Day 2 – So Very Tired

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

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

ROM Game Jam Day 1 – The internet wouldn’t allow it.

mstop_4 demo, graphics, Rise & Fall, ROM Game Jam August 10, 2013 0 Comment

Normally, I wouldn’t update my blog in the wee hours of the night, but the lack of a good internet connection at the ROM Game Jam has forced me to.

So now I share with you some screenshots of the work that has been done today by me and the rest of Team “Robots Mashing Keyboards” at the jam:

First, a screenshot of an very early version of the game:

FUS ARROW DAH?

I won’t go into details right now, but let’s just say our game will be a 2-player competitive platformer.

Next is a screenshot of a later build of the game, featuring graphics for one of the two characters in the game: some Roman guy, done by team member Shmuggly.

Minimalist architecture

And finally, the highlight of the day came near the end of the day: the inclusion of the Roman guy’s running animation, also done by Shmuggly, into the game. The initial results were hilarious:

The video doesn’t do the run cycle justice; it looks much better (and funnier) at 60 frames per second. The background music was composed by me, hastily over the course of only a few days and still needs a bit of work. Still, I’m actually impressed with how it turned out. When was the last time I even did anything in 3/4 time with the harmonic minor scale?

And now I’m tired, and have to get up early tomorrow to continue jamming. Good night everybody.

140 character limit exceeded

mstop_4 Gonna Catcha, graphics, shaders, whoopsie doodles July 31, 2013 0 Comment

This post was too big for Twitter, so I’m posting it here.

The first step towards creating a CRT display shader is complete. Gonna Catcha can (optionally) draw the game window with barrel distortion:

Babby’s first shader

I know there are already CRT display shaders out there on the internet, but I do want to learn how to do it myself.

In other news, it hasn’t been a week yet and already amusing bugs have been making a comeback.

The video also revealed the new time bonus tally at the end of each round.

You have encountered Abstract Art.

mstop_4 administration, GameMaker: Studio, gameplay, graphics, ROM Game Jam, shaders, That Which Binds Us, whoopsie doodles July 29, 2013 0 Comment

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!)

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

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

mstop_4 GameMaker: Studio, Gonna Catcha, graphics, interface June 15, 2013 0 Comment

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.

New HUD

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:

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.

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:

A graphical title to put up top rather than just having “G O N N A C A T C H A”

in plain text.

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.

Shaders

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

SHADERS!!

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.

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.

← Previous