whoopsie doodles – Quadolor Games

Two-player action!

mstop_4 gameplay, Gonna Catcha, Rise & Fall, ROM Game Jam, testing, whoopsie doodles October 6, 2013 0 Comment

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:

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

mstop_4 GameMaker: Studio, gameplay, Gonna Catcha, Rise & Fall, ROM Game Jam, testing, whoopsie doodles September 26, 2013 0 Comment

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.

Alpha demo gameplay video thingy

mstop_4 demo, gameplay, Gonna Catcha, whoopsie doodles September 12, 2013 0 Comment

The part of my brain that comes up with clever titles is out of office today.

After some thought, I’ve decided to make the Gonna Catcha playable demo a closed alpha for testing purposes, as I think it’s still too early for me to throw the game up on the internet for open testing. As a consolation prize, here is a video of the playable demo in action:

So what else do I need to do to move this game from alpha to beta? Well let’s see…

More rounds. Which maze the round takes place in and the number of spirits, rocks, preta and bonus items (in bonus rounds only) in it are manual determined by me for each round, rather than determined by some algorithm. Even though the game will have 256 rounds, I’m only going to create round data up until a certain point, then either start repeating the last few rounds or randomly generate round data to fill in the rest.
Co-op mode. It might have modified round data compared to single-player mode to balance the game.
Attract mode. How else will you know how to play the game?
High score table
Controller support
Bug fixes and code optimization. Even when I thought I’ve squashed most of the major bugs in the game, a new challenger appears:

And here are the features that would be nice to have, but not entirely necessary:

CRT shader. The game is setup up to use it, but it’s no longer a required feature to me anymore.
Demonstration cutscenes. Whether or not I need these will depend on how much info I can cram into the attract mode.
Bezel art. Artwork to put on my virtual arcade cabinet.

Well, looks like I’ve got my work cut out for me. …Wait, haven’t I already said that before?

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

Gonna Catcha: In-Game Testing

mstop_4 GameMaker: Studio, Gonna Catcha, testing, whoopsie doodles, Windows March 1, 2013 0 Comment

Status report:

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

The video shows some tests on changing between animations depending on the state of the player:

Gun out or holstered: 2 states
Walking or standing: 2 states
Facing direction: 4 states
Total combinations: 16 states

It also shows some projectiles and the death sequence, which I will never get tired off (*Not a guarantee, I guarantee.) You may have noticed that Donum sometimes jumps in position whenever he hits a wall. That’s just my squeeze-the-player-around-the-corner code that still has some bugs to work out. At least it’s better than what I had initially:

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

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

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

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

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

Go home Font Caching, you are drunk.

mstop_4 GameMaker: Studio, Sticks and Stones, whoopsie doodles, Windows February 10, 2013 0 Comment

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

Have you been hanging out with Zalgo?

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

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

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