Steve Cochrane

A 2013 talk by Jan Willem Nijman of Vlambeer, where he takes...

Sun, 20 Dec 2015 17:29:28 -0600

A 2013 talk by Jan Willem Nijman of Vlambeer, where he takes something that resembles most people’s first game design projects and then adds a bunch of little details that combine into a much better experience. Basically he gives away Vlambeer’s design secrets for a half hour.

Via Game Maker’s Toolkit.

New Pixel Font: Marietta Seven

Sun, 20 Sep 2015 17:38:11 -0500

I’ve made another pixel font, Marietta Seven, which is now available for download. It’s a 7px-tall companion to my previous font, Marietta Five, and it’s inspired by western and Clarendon typefaces.

This took a surprising amount of time to make! As with anything involving pixel art or chiptunes it’s an exercise in working within constraints. I learned a few things about the makings of a typeface while working through this, such as…

Rules

Having a typeface that reads well is all about consistency, so it’s good to start with some general rules. All of the letterforms here follow these rules:

Golden ratio for the ratio of width to height. (This was 11x7 but ended up at 10x7.)
2px vertical strokes, 1px horizontal strokes. The horizontal strokes pretty much have to be 1px because when a letter has three horizontal strokes with spaces in between them, like E, then 1px strokes are all you have space for when working with a height of just 7px. The 2px vertical strokes are there for some nice contrast.
1px-wide serifs.
Decorative spurs (S, C, G, J) and tails (Q, R) like a Clarendon.

Proportion

Letterforms can relate to each other in a surprising number of ways. In this case I started with the letter O, and that rounded shape was also used for anything rounded, like C, D, G, Q, and U.

That gave me a general 10x7 box to work with, which then determined the width and height of the boxier letters like B, E, H, and N.

It allows you to recycle a lot of parts when filling out the typeface, but it also means a lot of attention has to be devoted to keeping everything in proportion with everything else.

Diagonals

Print designers can use diagonal strokes however they want. For pixel fonts, this is all I really have to work with:

Choosing one of those for a letter with diagonals like X will dictate the width of every other letter in the typeface, because all of the other letters will then have to be around that same width to maintain proportion. Letters with diagonal strokes like X, A, V, W, and K have easily been the most difficult for me.

Points

I also found that certain letters need an odd width and others need an even width. W, M, A, and V pretty much require an odd width so that they can have a 1px point in the middle:

While others like Y really need an even-numbered width when they have a 2px-wide vertical stroke. And since the top half of the X should probably match the top half of the X, the X should also have an even-numbered width:

In Conclusion

I’m pretty happy with how this turned out, except that I wasn’t able to implement kerning tables, so certain letter pairs look pretty awkward and require manual correction, such as WA:

FontStruct is an amazing tool for making pixel fonts and it’s what I’ve used here, but it doesn’t provide any kerning functionality, and I tried a few free trials of tools like Glyphs and Birdfont but I ran into compatibility issues. If anyone has any other suggestions, please let me know in the comments!

"Today’s a day for playing lots of games together as a family until you can play no more, only..."

Wed, 15 Jul 2015 22:25:26 -0500

“Today’s a day for playing lots of games together as a family until you can play no more, only to do it all over again tomorrow. And as we do that, those games will light up our rooms. That’s how it should be, we can’t keep them in the dark because in my mind, more than anything, that’s what games are all about: keeping the house lit up.”

- Shinya Arino’s remarks on Satoru Iwata, translated by Thomas James, via USGamer. Posted here for safekeeping.

Berserker

Fri, 18 Oct 2013 23:51:26 -0500

I’ve been updating my front-end web development skills lately, trying out a bunch of new-to-me automation tools, and it’s been a lot of fun. In the interest of being a lazy programmer I’ve made a template for very quickly starting up a new project with everything set up and ready to go. Most developers probably have a folder like this on their hard drive already but I’m putting mine out there in case it’s useful to anybody else. It’s called Berserker and you can easily fork it and make customizations to suit your needs.

This was motivated by two things that I definitely want to use for all of my sites going forward:

Sass + Compass: these greatly streamline CSS development, and it’s a little embarrassing to admit that I only recently discovered them since they’ve been around for years. You can automate vendor prefixes, base64 encoding, px/em/rem conversion and a lot more.

Grunt: a JavaScript automation tool that makes it trivially easy to build your sites according to best practices.

With Berserker you can just paste one command in the terminal and get started with a file structure like this. It starts with Normalize.css, some basic Sass functions and variables that I use regularly, and a very basic HTML file.

When it’s time to ship, run the included Grunt script and all of the following stuff happens automagically in a matter of seconds:

HTML is validated and minified.
Images are compressed.
Compass’s compiled CSS is validated and minified.
JavaScript is tested with JSHint to detect errors and potential problems.
Provided the JavaScript passes the test, all JavaScript is concatenated into a single file.
That concatenated JS file is then minified.

These were all things that I used to do manually or just didn’t bother with, so it’s amazing to have it all done so easily. It saves a lot of development time and my resulting sites are faster and less error-prone. If you’d like to give it a try, there are more details in the README on GitHub.

INSTIGATION Postmortem

Tue, 27 Aug 2013 23:57:23 -0500

I made a game in the Ludum Dare 48-hour solo competition this past weekend, a frantic match-three puzzle game called INSTIGATION.

One of the things I regret about Intergalactic Curling League (my first Ludum Dare entry) was that I didn’t really do any game design for it, I merely lifted the rules of an existing game. So this time I wanted to take a few hours at first to really plan out the design and to try to make something at least somewhat unique.

I’ve always enjoyed the more frantic match-three puzzle games (Tetris Attack being my favorite) because they’re possibly the best at getting me into that “zen-like state” where I’m completely absorbed and the controller becomes an extension of my brain. Also I tried Wario’s Woods for the first time on Wii Virtual Console a few months back and I was pretty taken with it. So INSTIGATION has the instant response of Tetris Attack with the in-game character moving and lifting blocks like in Wario’s Woods. My additions were a column cycling mechanic that is kind of like a Rubik’s Cube and falling blocks that can stun you, which hopefully creates a nice push-and-pull between clearing the blocks while also staying out of the way to make sure you don’t get squashed.

I really wasn’t sure if this was going to work because I hadn’t programmed anything like a match-three puzzle game before and it seemed pretty complicated. But Ludum Dare is a perfect opportunity to take a risk because at worst, you only lose a weekend’s worth of time. Fortunately it worked out just fine, but I still planned for it by going absolutely minimal on graphics and animation so I could reserve as much time as possible for programming.

Of course there are plenty of things I wish I could have done if I had more time, and maybe I’ll do a more polished version at some point depending on how well this is received. The main thing I wish I had time for would be the ability to match more than three blocks at once for bonus points, and also chain combo bonuses. This would elevate it from just clearing blocks as fast as possible to more of a true puzzle game where there are more interesting choices, and where skillful play is rewarded.

Now Ludum Dare participants get three weeks of playing and giving feedback on other people’s games, which is about as satisfying as making the games themselves. I’ve even seen some participants in the jam making their first game ever and it’s heartwarming to see the community being so encouraging.

What's in the Box?

Wed, 14 Aug 2013 00:40:08 -0500

I recently played CAPSULE by Adam Saltsman and Robin Arnott and it got me thinking about items in games. I’ll be writing a bit about the gameplay here so there are minor spoilers if you haven’t played it yet.

It’s a survival horror game, but not in the usual sense: there aren’t any zombies or other supernatural creatures and instead you’re a lone pilot with only a partially frozen radar/sonar screen to guide you, and you scramble to collect the supplies you need to stay alive. (At least, at first. I haven’t completed the story yet.) A large part of the game consists of using sonar to identify nearby items which then slowly and agonizingly fill a progress meter before finally revealing what’s inside.

That slow reveal is what adds the suspense that makes it a survivor horror game. If the items were revealed immediately you would probably zoom around trying to collect them all as fast as possible, and it would instead feel like an action game.

There are a couple other broad ideas here that are core to a lot of games:

Randomized items keep things interesting. All of the items are randomized so each one is an interesting little gamble. See also: random item drops in Diablo and The Legend of Zelda, every MMO ever, etc.

Showing an item container and then having the player reveal it is more fun that just being given the item. In Super Mario Bros. where every block potentially has coins or power-ups or even a beanstalk hidden inside, the candles in Castlevania and their equivalents in Ninja Gaiden that just might have that subweapon you desperately need (or that other subweapon that you think is useless) and so on. It ties in to the fun of discovery.

Another kind of example is (obligatory Metroid reference) the Chozo statues in Metroid, where the item is hidden at first to add a moment of suspense. (Not to mention the “item room” audio cue.)

That red ball is basically the wrapping paper that you tear off to open a gift from the game designer. Here you go, player one! You’ve earned it. Nintendo uses this concept in a lot of places and now even 3DS eShop games come in virtual wrapping paper. (It’s a little silly since we know what we just bought, but even unwrapping a known item can be fun.)

So, currently in The Mountaineers I have ice blocks that look like this, with the contents visible, and now I’m guessing it would be more fun to hide the contents and make it a surprise. Then, the contents of every block can be a mystery.

Climbing Mechanics

Tue, 30 Jul 2013 23:01:33 -0500

Okay, back to what seems to be the standard format here: documenting the research and thought process behind a new feature. This time: vertical levels in platformers.

Usually when NES platformers have vertical levels, there are more ways to move up than just jumping, like ladders and staircases. These are good for gameplay variety, and they’re also interesting because they’re stressful: movement is restricted and they put the player at a disadvantage.

In Super Mario Bros. 2 there are occasional vertical segments where you climb vines, and they take patience because the player has no way to attack enemies from below. The only option is to avoid enemies until you have the upper ground.

In the Mega Man games there are frequent vertical segments with ladders, and while Mega Man is still fairly mobile, he can only move up and down and the horizontal default weapon is less useful.

In Castlevania, stairs are frequently used for vertical segments and these make the player extremely vulnerable, which is perfect for the horror setting. Once you’re on a staircase you move even slower than usual, you can only move up and down the staircase, and you can’t jump off (at least, not in the NES games). If you’ve played Castlevania III, the following screen might raise your heart rate:

I think this is also why people hate and fear auto-scrolling segments: they remove control from the player. You no longer dictate your pace and you either have to struggle to move fast enough or you’re bored because you want to go faster.

So, for The Mountaineers I’ve currently got climbable walls that are similar to the fences in Super Mario World. There are areas on the walls that a player can grab on to and then move around in all directions. This fits the mountain climbing setting pretty well, though now that I’ve written this I’ve realized I might have given a little too much power to the player and it might go back to one-dimensional movement like the above examples. Here’s a screenshot, again with somewhat crappy first-draft sprites:

The implementation for something like this wasn’t too bad, thanks to the magic of Flixel. The “climb zone” has an invisible hitbox that I can define in my map editor, and if the player’s hitbox is within this zone, they can press up to grab on to the wall. From that point they can jump off the wall or do a stationary attack in addition to moving around within the climb zone. When combined with wall-jumping this gives the player several “verbs” for vertical movement and it’s hopefully just enough to keep things interesting.

My Favorite Button

Wed, 17 Jul 2013 00:15:50 -0500

This “Scale” button here, in GarageBand for iOS?

This button made me a better musician. I’ve been tapping virtual keys on GarageBand for iOS to compose chiptunes largely because of this one button. If you press it you’ll see a list of available scales, and when you choose one, like Major Pentatonic…

…it only displays the keys in that scale so it’s pretty much impossible to sound dissonant. This is super valuable for novices like me, because everyone needs training wheels sometimes.

Normally when learning a new skill you have to learn the fundamentals, like scales, and memorize them to the point where you can use them without thinking. A lot of people probably get bored and quit before then. (I did.) Not only does this feature allow me to postpone that step and get right to the fun part, it teaches. If I hadn’t seen this I might still not know what a Major Pentatonic scale is.

It also shows one of the unique strengths of touchscreen platforms, the ability to change the display of a touch panel. The OS X version lacks this feature and (to me) it’s less useful and less fun without it.

Here’s a second sampler of work-in-progress music...

Wed, 03 Jul 2013 11:00:13 -0500

Here’s a second sampler of work-in-progress music (following the first) with the intro cutscene song and a new loop for one of the stages. I’ll have one or two more of these as the soundtrack is wrapped up.

That loop has a couple things I hadn’t tried before: pitch bending (so fun) and the 12.5% pulse wave (starting around 1:08) which I had stupidly dismissed as being for “robot zapping sounds” a while back, but it’s obviously more versatile than that and it’s a defining part of the NES sound.

Alex Mauer’s music is what changed my mind. He’s done this thing a few times where he plays a melody first with the normal 25% pulse and then repeats it with the 12.5% pulse, done for variety in “The Waiting (Part 2)” (starting at 0:13). Same melody, different voice. Then on the very next track, “DYFEYW”, he uses the same technique but this time it’s to punch harder (again at 0:13).

Tagging Along

Wed, 19 Jun 2013 00:28:41 -0500

I’ve already hinted at one mechanic in The Mountaineers with an image posted to Screenshot Saturday, ages ago:

For the second stage the idea was to have the kid on foot, mirroring the player’s movements. It was a struggle but I’ve mostly got a functioning mechanic for it now, and here’s how I got there.

There are two 2D games I can think of that had something like it, both with a nearly identical mechanic but in different genres: Gradius and Ninja Gaiden II.

Gradius has the “option” powerup, a floating orb that follows you and doubles your firepower. It works something like this:

All of your ship’s movement is recorded.
Once you’ve moved for a certain number of frames, the option will start to retrace your recorded movements at the same rate of speed.
If your ship stops, the option stops immediately. This ensures that the option never catches up to you.
If your ship fires, the option fires immediately. This allows for some strategy with positioning, as you can spread the options out to cover a large area of the screen or bunch them up to concentrate all firepower on one location.

Ninja Gaiden II has the clone powerup, and I’d outline how the clone works too but it’s virtually identical, just replace “ship” with “ninja”. It’s a nice little feat of programming that was likely pretty hard to pull off. These seem pretty simple at first glance but there were a few things I only noticed once I tried my own version.

It’s okay for a clone to hover in mid-air. This is just fine for a floating orb or a shadowy flickering clone, but if the “clone” is a person like with what I’m trying, it really doesn’t make sense unless the person has a jetpack or something. So my solution is to just have the kid keep moving through the tracked movements, even if the player has stopped moving. Of course, this removes most of the strategy that the above games had so we’ll see how it goes. It also means that if the player stops moving, the kid will then move to occupy the same space and vanish behind the player unless I add some logic to prevent collisions.

The clone needs to follow player movement exactly or it falls apart. Implementation is tricky because if the clone’s movement deviates at all, even by a single pixel, it might cause the clone to miss a jump. My first attempt at this mechanic failed because it wasn’t an exact match. Also the clone’s hitbox needs to be exactly the same size as the player’s hitbox or you get the same problem.

The clones are invulnerable. This is another case where it makes sense for an immaterial clone but not for an actual person (especially a child who should never get hurt). I think I can dodge this with an animation where the kid ducks under hazards or jumps away for a split second.

Hopefully some screenshots will suffice for now:

Scoring Systems

Wed, 05 Jun 2013 00:47:38 -0500

Following the HUD post from last time, I’ve added a scoring system to the game. Numbers!

This was added for a couple reasons. One, it can provide overlapping goals for the player to keep things interesting, beyond just the motivation to get to the end of the game. When used well, the player can choose to go out of their way and take optional risks for extra rewards. Two, it adds to the fun, I hope. As long as it’s not too cloying, like giving an achievement for completing a tutorial or something, it’s fun to be rewarded when doing well, and when a level is cleared you can spin some numbers and go ding ding ding and that’s just fun.

Admittedly I’m a little unsure about this, because scores are usually a vestige of the early arcade days. Games back then had to be very short because it just wasn’t possible to have more than a few levels (if any) with the hardware at the time. So in order to keep a player’s interest, the goal became to play the same levels over and over again in order to master them and get the highest possible score, and since arcades were social spaces it also added a competitive element.

Now games are usually more about narrative, and many not only do away with scores, but with lives in general. While this is generally for the best I also think at times that this can oversimplify things, and give a feeling like in my Super Mario Bros. With Respawning notes where the danger was removed, the strategy became to brute force through to the end, and the challenge and fun were lost.

I’m a novice when it comes to game design so I’m sticking to the old ways while I get my bearings.

On HUDs and My First Font

Wed, 22 May 2013 00:46:00 -0500

Last time I hinted that I might be writing about enemies, but I procrastinated on game design again by making a HUD instead, hooray! (Though in my defense, it is related to game design since there is a lives system now, getting a high enough score gets extra lives, etc.)

HUDs were interesting on the NES because of its limitations, and also because they evolved as game mechanics got more complex. In the beginning you could get by with something like this:

Soon it became more and more common to have screen space dedicated to the HUD because of an increase in the number of visual elements, and the need to display more than just letters and numbers.

The NES didn’t support alpha transparency and it was also limited in the number of colors that could be displayed on each line of the screen. If you use red and pink for hearts, for example, that’s potentially two fewer colors that you can use for sprites and backgrounds on that same line. So when showing anything beyond white text with a one-color, opaque shadow behind it, developers would usually dedicate a portion of the screen to the HUD. Of course, the drawback is that you reduce the size of the play area.

There were also some clever workarounds. For example in Mega Man the colors for Mega Man’s bullets (light yellow and white, with a black outline) needed to be available for every line on the screen since he could shoot anywhere, and the life bar also happens to use yellow and white. I assume this was done to give it some nice shading while also not subtracting from the available colors.

Once you got into the 16-bit era, much larger color palettes and alpha transparency were available, so games that would have had dedicated screen space in the past didn’t need to do that anymore, and the HUD could be laid on top of the playable area without sacrifices. (Except maybe readability, like in Super Castlevania IV below.)

For my own HUD I don’t need much, just a score, a lives counter, and a life bar. I tried dedicated screen space for the HUD just to see how it felt, but I didn’t like reducing the size of the play area, so after trying about a bunch of concepts I settled on the one at the top here. (Now that I’ve written this, I realize it breaks the above rules with the red…)

When I tried my usual go-to fonts, none of them felt quite right, so I ended up making my own numerals and the letters I needed in the same style as the wide, serifed text I’d done before, but smaller. Later I reproduced those in FontStruct, added some more, and enjoyed it so much that I ended up making a whole font, my first. So here is Marietta Five, and I hope to follow it up with a larger Marietta Seven at some point in the near future. It’s public domain so use it however you like! It’s intended for a font size of 8px but it also works with 16, 32, etc.

This is exactly why I enjoy making games so much. I might not be able to make a print-quality font, but a pixel font is attainable. I might not be able to make beautifully-rendered visual art, but NES pixel art is attainable. I might not be able to make professionally-produced music, but NES chiptunes are attainable. It’s really empowering.

Adventure Island IV has some pretty adorable sprites. I tried drawing some in this style but...

Sat, 11 May 2013 14:00:45 -0500

Adventure Island IV has some pretty adorable sprites. I tried drawing some in this style but it’s deceptively simple.

The Magic of Palette Swapping

Tue, 07 May 2013 23:34:10 -0500

I’ve mostly been iterating on game mechanics and level design lately, which hasn’t resulted in any exciting things to post here, I’m afraid. It’s also the area that I’m least experienced with so it’s a bit of a slog. I’ll hopefully post some enemies that I’ve added for next time though.

I’ve been getting a lot of mileage out of this set of rock tiles I made a while back.

Once I had those, the environments still looked too blocky, so I made some angled half-block tiles and some other tiles with a rough edge on one side, which were easy since all I had to do was subtract from the original tiles.

Then in order to make a background layer of rocks, I simply did a palette swap and brought down the contrast.

Then, I palette-swapped four more times to get a first pass for the rocks in mountains 2-5.

Last week I made a spooky cave interior by, you guessed it, palette-swapping those same rocks once again.

This might get repetitive over the course of an entire game and once I’m satisfied with the level layouts I’ll likely draw some more textures, but for making a first pass on the levels, it’s more than enough.

Worthy of Note

Tue, 23 Apr 2013 22:24:21 -0500

This time I just thought I’d point out a couple things others have made that have influenced my work and got me thinkin’.

Anatomy of a Game

Jeremy Parish has finished the latest in his Anatomy of a Game series, a dissection of Zelda II: The Adventure of Link, and like all of them so far it’s a good read. He’s covered some concepts I hadn’t noticed before which I am now trying to work into my game if possible, such as the consistency of architecture in Castlevania, which really ties the whole game together and provides a great sense of progress, and the point of no return in Castlevania II and Zelda II, which provides a feeling of dread heading into the final battle.

This is exactly the sort of thing I want to read: looking at the classics under a magnifying glass and analyzing all of the little things that combine to form something great.

Super Mario Bros. with Respawning

Lately I’ve felt like something has been missing from The Mountaineers but I can’t quite put a finger on it. I’ve considered adding some sort of collectible item to give the player an objective in addition to just getting to the end of the level, and I wondered what Super Mario Bros. would be like if the coins were removed. Someone has to have made a ROM hack for this, right?

Leon Arnott has made many interesting Super Mario Bros. ROM hacks, including Silhouette Mario Bros., which you might recognize if you’ve read Rise of the Videogame Zinesters. But to me, the most interesting one is Super Mario Bros. with Respawning. Here’s his description:

“This hack is mostly identical to the original game, but changes were made to make it more “modern” (by which I mean “Knytt-like”) in its sensibilities. Most of the game’s text is removed - there are no interstitial “World 1-1” title cards, the status bar is gone, and the floating score numbers are absent. You have unlimited time, unlimited lives, and instead of midway points, you respawn at either the start of the room you died in or the last pipe/vine you exited. This last change makes some levels easier (6-2, 8-1, 8-4) and some harder (the X-3 levels).”

Here are some things that came to mind as I played it:

Coins are worthless. Now that you have unlimited lives, there’s really no reason to collect coins anymore, or for the coins to even be there. This just reinforces the idea that collectibles should have some sort of gameplay benefit or they’re just noise.

No danger. Infinite lives and respawning make sense for Knytt because the game isn’t supposed to be challenging. The fun is derived from exploring the world. Normally when you play Super Mario Bros. you know that your lives are quite limited, and if you lose them all, you’ll have to start over from the very beginning. This means that every move you make has consequences, and the stakes are progressively higher as you advance. Once respawning is added and your lives are unlimited, there are no consequences to your actions anymore and the most effective strategy is to brute force your way through everything. Overcoming challenges is no longer satisfying.

No sense of progress. If I don’t feel like I’m progressing towards something I will quickly lose interest, and here there’s really no indication of where you are anymore. Of course, this wouldn’t be a problem if the title cards hadn’t been removed, and there are plenty of other ways to solve this too, like an overworld map for example. Knytt solved this problem by making it the goal to collect the scattered parts of your ship, and you could see how many parts were left to collect at any time.

The original Super Mario Bros. wasn’t designed with these intentions, so if the original designers were setting out to make a game of this type, they would have made other changes for it to be more of a cohesive whole. But it’s still an interesting thought exercise about goals and motivation for the player.

Wall Jumping

Wed, 10 Apr 2013 00:48:18 -0500

In the prototype for The Mountaineers, the player had the ability to air-dash in any direction including upward, as seen in my post-TIGJam demo. While it can be fun to air-dash all over the place, once I started to design more levels I found it was hard to provide a challenge when the player was so mobile. It could probably work in a game where combat is the main focus but that’s not what I’m going for, so I’ve replaced the vertical dash with a wall jump. This seems like a win because it allows me to restrict where vertical movement is possible when designing the levels, and it has a timing element that makes it even more fun.

Wall jumping is always a little strange because you have two opposing forces: you have to hold in the direction toward the wall to get close enough to jump from it, yet when you jump you’re immediately thrown in the opposite direction. The subtlety is in the timing of the switch.

You can have the player press away and jump when in contact with a wall. If you don’t time it right you might disconnect from the wall before making the jump, and that can be frustrating. (e.g. Super Metroid)
You can have the player press jump while holding against the wall, pause for a split second before the jump happens so the player has a chance to hold in the opposite direction, then go through with the jump. (e.g. Batman for NES)
You can have the player press jump while holding against the wall, then propel them away from the wall at maximum velocity so that even if they are still holding toward the wall for a second or two, movement is unaffected. (e.g. New Super Mario Bros.)
You can have the player stick to or slide on the wall, giving them time to hold away from the wall and press jump without disconnecting from the wall. (e.g. Super Meat Boy)

This could be a much longer article as there are plenty of unique approaches out there with a lot of subtle variations, but I’ll stick to the good stuff. Two games stand out with exceptionally good wall jumping in my opinion:

Mega Man X is the first game I remember with really good wall jumping. It’s a core mechanic and you can tell they spent a lot of time getting it just right. You attach to the wall, which stops downward momentum for a second, and slide down in a cool pose with a trail of dust behind you. You also slide down at a constant speed, slower than free-fall, which allows you to time your jump perfectly. My only possible criticism is that you don’t have a lot of time to press jump once you start holding away from the wall, but that also means you can get off the wall pretty quickly without jumping if you want to.

Super Meat Boy’s wall jumping has a great feel to it as well. Gravity still affects you while you slide, so you’ll eventually hit free-fall speed, but you have reduced vertical drag. You can also slide on the wall during the ascent of a jump, and when combined with the reduced vertical drag you can actually go higher than a normal jump this way. The wall is also very sticky and in order to get off the wall without jumping you have to hold the direction away from the wall for about a second, which gives you plenty of time to hold away and jump.

I’ve done my implementation in the usual way: by finding a bunch of great examples and then combining my favorite elements from all of them. Like Mega Man X, when you touch the wall your vertical momentum stops for a second and you begin to slide. The character is clearly in slide mode because they have a unique pose and there are puffs of snow trailing behind you as you slide. Like Super Meat Boy your vertical acceleration is slower than in free-fall, but you accelerate as you slide, which hopefully provides some tension when timing the jump. And like New Super Mario Bros. you are pushed away from the wall enough that you can’t continually jump up the same wall. I also added a little sssssshhhh sound while sliding for another layer of feedback.

I had trouble capturing an animated GIF this time, and that’s a crappy first draft sprite of the player, but it feels pretty good in motion!

A Good Camera is Invisible

Tue, 26 Mar 2013 23:36:00 -0500

Part of the fun of making games is that it causes me to see my old favorites in a new light, and to appreciate the little details that I hadn’t noticed before.

Super Metroid is my favorite game, and despite the many times I’ve played it, I never really noticed the camera until I sat down last week to deliberately observe how the camera works. The fact that I never noticed the camera means that it’s an ideal camera.

Super Metroid’s jumping is pretty unique: once you get the Hi-Jump Boots you can actually jump as high as the height of the screen. To account for this, the game’s gravity is lower than it would be on Earth (which fits since you’re on an alien planet and you’re wearing a spacesuit made by an ancient race of magical bird-people) so you have time to control your trajectory in the air. The camera also assists by moving upward slightly faster than you do, revealing more of the area above you when you jump. It seems like it would be disorienting but it feels completely natural, and it takes the unique qualities of the game into account.

The original Metroid is a great counter-example because it does the opposite. As you move upwards the camera lags behind and it actually shows more of the area below you than above, and vice versa. Simply centering the camera on Samus would have (I assume) been easier to program and more functional.

Another series worth mentioning is Sonic the Hedgehog. Sonic loves to run very fast, usually to the right. When you’re moving very fast, you don’t have a lot of time to react to oncoming obstacles, and if you’re usually running to the right, you don’t need to see much of the area to your left. Yet in the first three Sonic games the camera is centered on Sonic at all times, and in the 2010 game Sonic the Hedgehog 4 it lags behind and shows more of the area behind you than in front, which is even worse.

I replayed the first Sonic recently and noticed that because of a lack of reaction time, I denied my own wishes to run very fast and walked slowly to make sure I didn’t charge into the stinger of some giant robo-bee lurking just off-screen. Better camera placement probably wouldn’t completely solve this problem, but I bet it would help.

So with these in mind I set out to optimize the camera for The Mountaineers. The game is about climbing mountains and there are lots of vertical segments where you are mostly moving upward, so in these segments it’s nice to lead the camera and show more of the space above the player. This also allows me to do some fun things with the level design, like having deadly boulders that roll down from above as you climb. When I just had the camera centered all the time there would be less time to react and less room to maneuver, so it wasn’t as fun.

(Yes, that’s the boulder from Yoshi’s Island. It’s a placeholder. Shush.) Also since the game is mostly about forward motion, I lead the camera in the horizontal segments too (which is something that Super Metroid also does well). If you change direction it then sweeps the camera in that direction faster than your movement speed, so that in a second it again reveals more of the area ahead of you than behind. Leading the camera can be really helpful and I’m surprised at how often it gets forgotten with modern games.

For even more on the inner workings of cameras in platformers, here’s a nice little video from Shaun Inman on the camera in Super Mario World:

NES-style Screen Transitions

Tue, 12 Mar 2013 21:41:10 -0500

There’s a transition effect seen in a lot of NES games like Mega Man, Castlevania, and The Legend of Zelda where when the player reaches the edge of the screen, the camera sweeps over to reveal the next area. I’ve also used that effect for The Mountaineers, and it looks like this in animated GIF form:

While there is some nostalgia at play here, of course, and while this was originally done because games at the time had very limited memory available, I’d argue that there are still good reasons for it. Rather than having an entire level stretch on and on, which can get overwhelming with more demanding action games, transitions like these can break the level into smaller, manageable chunks and more frequently provide the player with a sense of progress. Also, if the player is low on health or if this is used to telegraph danger ahead, it can provide suspense in a “I don’t want to see what’s behind that door” sort of way.

In the Mega Man games this is very effective for building tension before each boss, and it gives the player a chance to pause and consider strategy. Imagine how less tense each showdown would be if you just immediately ran into the boss at the end of each stage.

Implementation

Rather than having the camera just follow the player all the time, I have an invisible “camera helper” that the camera follows instead, which usually sits on top of the player but which can allow the camera to move independently for things like this. Here’s what that same transition looks like with the invisible objects shown in red. The solid red block is the camera helper and the semi-transparent red block is the barrier between screens.

First, the camera’s boundaries are set so that the player can’t see beyond the barrier.
When the player touches the barrier, immediately move the camera helper to the center of the screen.
Temporarily remove the camera boundaries, and move the camera helper at a fixed speed toward the next screen.
At the same time, move the player forward at a slower fixed speed, so that over the same period of time the player ends up slightly beyond the other side of the barrier.
Once the camera helper has reached the center of the next screen, snap it back to the player and restore camera boundaries.

Properly Upscaling Pixel Art in Flash Fullscreen Mode is Difficult

Tue, 26 Feb 2013 22:57:00 -0600

For fullscreen mode in a game with pixel art, I want one thing: upscale as many times as possible while maintaining the aspect ratio and pixel ratio, with no distortion.

Simple, right? It seems like boilerplate functionality that Flash should provide but it’s not, and it was surprisingly hard for me to find any resources on how to do this.

My game runs at a base resolution of 256x240 (the standard NES resolution, naturally) and it’s normally set to display at 2x scale for a result of 512x480. Let’s say I enter fullscreen mode on a 24" Cinema Display with a resolution of 1920x1200. The height is the constraint here, and in this case 1200 divides evenly by 240, so we can just scale up to 5x and keep the width proportionate. Easy.

It gets tricky when the display’s dimensions are not exact multiples. For a (non-Retina) 15" MacBook Pro with a resolution of 1440x900, the dimensions aren’t evenly divisible so if you fill all of the available width, you’ll get distorted pixel art.

What I want is to scale up as many times as we can while preserving the pixel ratio, and no further.

Again, it seems simple, but I wasn’t able to find anything online detailing how to do this. Here are the commonly-used fullscreen methods that I’ve found for Flash games, none of which are ideal:

Use Flash’s built-in fullscreen methods and set stage.scaleMode to EXACT_FIT. This will set your game to display as large as the screen can allow. Aspect ratio is preserved, but pixel ratio is not, so as in my MacBook Pro example you’ll get distortion if the screen dimensions aren’t cleanly divisible.

Change the size of the play area to fit the full dimensions of the screen. This can have a serious impact on gameplay and it’s not for me, but there are fans of this approach. Here’s a nice tutorial about it from Wolfgang Graebner of Funstorm Games.

Use stage.fullScreenSourceRect. This is promising since it uses hardware acceleration and it runs very smoothly, but it anti-aliases the content (a deal-breaker for pixel art) and there’s no way to change that.

All of these are problematic because the game object is the highest addressable object, and that limits what you can do with it. So I made a new container object that sits above the game object, which can detect the available width and height of the display and then scale and position the game perfectly. And it works!

Except, this approach breaks the preloader, or at least it does for my Flixel games. You can see it in action here with a fullscreen-enabled edition of Intergalactic Curling League (click to focus and then hit F to toggle fullscreen) though you just get a white screen for a few seconds while the game loads, which is a major sadface. I was likely going to distribute The Mountaineers as an app anyway, but this does limit the usefulness of the technique quite a bit.

With that said, if this is still of interest to anybody I’ve published it to GitHub as Fussy Flash Fullscreen. If you’re distributing a standalone/projector/AIR Flash game (or if you can figure out how to get this technique working with a preloader) I hope this saves you some time so that you don’t have to burn a whole weekend on it like I did!

Pain and Death

Wed, 13 Feb 2013 00:47:00 -0600

After adding some hazards to my game it became pretty noticeable that I didn’t have a sprite for the “hurt” and “death” states. Here’s a bit on my process for making one, and as usual it starts with some research.

For web design I usually start with my “design scrapbook” (tons of tagged screenshots of websites that I’ve collected over the years) or searching for a specific concept on Pattern Tap. For pixel art that means going through my small-but-growing pixel art scrapbook, booting up various games that I have handy, or looking up games at Giant Bomb. For example when I wanted to draw a reindeer, I searched the Giant Bomb wiki for “reindeer”, got a list of every videogame with reindeer, and then went from there.

After researching hurt/death animations I found that there are two kinds of death animation that practically every platformer uses:

Cute and silly — the protagonist makes a googly-eyed face and usually falls off the bottom of the screen.
Violent and realistic — the protagonist is knocked to the ground and lays still.

Here are some of my favorites from NES games in the “cute” style:

Super Mario Bros. 3

Hammerin’ Harry

Panic Restaurant

Q*bert

Donkey Kong Jr.

For my own I took the basic idea of the asymmetrical googly-eyes and flailing limbs of Donkey Kong Jr. and tried it in my own style.

I wish I could have some modern examples here but the small handful of modern pixelated 2D games I’ve played recently mostly adhere to established styles, as I’m doing. Feel free to add more in the comments though!

The death animation is one of those details that can be overlooked, but it’s a great opportunity to add some personality and charm.