Making Happiness!, Part Two

So Tom’s breathing down my neck again. Guess I’d better post this next part of our little behind-the-scenes featurette for Happiness.

A Very Different Game

Happiness was initially planned to be hand drawn through and through. I had gone through some early animation tests involving the Dreamer in a desert at dusk, but realized quickly that A) it wasn’t coming out very well, and B) it was going to take forever to create the game with large detailed sprites. My skill in artistry and animation aren’t anywhere near the level required for the game to look good. The hand drawn style was quickly abandoned, though one iteration of the early tests is still on my hard drive. I’ll probably delete it next month. Who needs history?

Seen here: History. Thank god.

Laziness Takes a Lot of Effort Actually

The first spritesheet created, the Dreamer took a good while to finish. His mouth is actually a separate object that floats on top of his body sprite, allowing for dynamic expression changes.

The game quickly took a very retro pixelart direction, reminiscent of old NES games. At first I had thought that this new direction would make things easier, and it did. Only ‘easier’ is in relation to what I was going to do before. I still had a lot on my plate, having to not only design every environment, character, item, and object in the game but I also had to animate them as well. I studied a lot of sprites and tilesets from other games intensely, picking up on the way sprites were shaded and what sorts of colors were often used together to create textures. How to imply movement in the animations so I could turn a full swing or walk animation into 3 frames, how to use templates and avoid creating an unnecessary workload. As I got further into development I gradually picked up a rhythm and the assets became easier and easier to create.

All the visual assets were created in Paint Shop Pro 9, because I’ve used it for a long long time and I can’t afford Photoshop. It runs in a lesser color mode that is incompatible with the Windows 7 aero effects and is the primary reason I don’t upgrade to Windows 8. I often use layers when creating sprites, for purposes such as onion skinning and for template modifications. I constantly work on grids of 16×16 or 8×8, and each sprite is laid inside very specific frame sizes, 32×32 for both the Dreamer and Dreamette. This allowed me to maintain consistency when the sprites were imported into Construct 2, especially for hotspots and origin points and the like.

Archaic program used to inspire archaic graphics.

Archaic program used to inspire archaic graphics.

Dancing to Some Nostalgic Beats

All that graphics stuff is fun and all, but the real reason I decided to go into game development is because I wanted to compose a video game soundtrack. Inspired by the works of Nobou Uematsu, Koji Kondo, and Jeremy Soule, among a great many others, I had wanted to compose video game music alongside my own pop rock efforts. As I was already taking on a huge undertaking with creating the rest of the game I had asked my bandmate Chris if he would like to contribute to the soundtrack. Eager to work on a score for a project and the interesting nature of video game music intriguing him, Chris eagerly agreed, the second member of what would become Blue Key Games. Since the art style was going to be NES style, I decided we may as well emulate the NES sound as well.

Yes, it was as confusing as it looks and yes, it was very very easy to destroy around 7 days worth of work in about 7 seconds.

Yes, it was as confusing as it looks and yes, it was very very easy to destroy around 7 days worth of work in about 7 seconds.

To achieve the effect we turned to the NES soundchip emulator Famitracker. It took a little while (we weren’t too familiar with how tracking software worked, as we were used to more elegant and fully featured setups) but we figured out a method to the madness, and it was a really interesting challenge working within the limitations of the “NES hardware”, creating drumbeats by varying the pitches of white noise and creating the different textures of the instruments using the square and triangle wave forms. The first track finished was “Pieces”, used for the “Incomplete Machine” level. The second track finished was “Hugs”, heavily inspired by the 8-bit arcade remix of “Planet Wisp” from Sonic Colors. Music was being done at a pretty good clip. Probably my favorite part of development.

Importing the songs into Construct 2 was interesting, as we had to create intros that cut off cleanly into main song loops. Then we had to edit them in fancier programs than Famitracker, where we were able to set loop points to eliminate any of the “seams” in the loops. Granted, in the final game, there are certain browser limitations/speeds that only serve to highlight the split between the intro and the loops, but that’s unfortunately something outside of our control. The overall effect I feel is quite good however, and we’re all pretty happy with how it turned out in the final game.

It Looks Pretty, But Does It Do Anything?

What’s a game without the actual programming though? Nothing, that’s what. Shame on you if you thought otherwise.

This is about the point where my eyeballs bled right out of their sockets.

This is about the point where my eyeballs bled right out of their sockets.

Countless nights and days were spent haphazardly hacking together components to create some semblance of a playable video game. Taking a cue from Object Oriented Programming, various game components were created in reuseable event sheets that were included in each of the various stages. Inside of these “include sheets” were the various Controls, Player Systems, common functions (including fades and data management, and so on and so forth. Certain functions would be created with modularity in mind, allowing me to substitute variables so that the same function can send you to Stage 1 or 8 depending upon the instance variables in the door object you walked through, reducing repetition and bloating. Granted, this wasn’t done with much finesse as I was also using Happiness as a learning experience as well, and the end result doesn’t allow me to add stages with any sort of flexibility as a lot of the game is hardcoded in, including the number of stages and the mobs in each stage as well. The only objects that would cross over from stage to stage were the Dreamers and their parents (though the parents had a lot of their AI hardcoded into the final stage as well). Fortunately, the player game experience itself does not suffer for the disorganized mess beneath the candy shell. I’m of the firm belief that the only thing that matters with a game is not what it looks like under the hood, but whether the resulting player experience is any fun. I hope we’ve achieved that with Happiness, and we look forward to creating another memorable one with Revahlen.



Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Protected by WP Anti Spam