I kicked off this week of development with a feature that I’ve been wanting for some time: attachment points. When I brought placeholder assets from Zelda 2 into my editor a few weeks ago, I was able to start testing melee combat feel, but I knew I would need some additional features to accomplish everything I wanted to do.
Link’s melee animations have his weapon drawn into them. This means Link can only use this sword, never an axe or a hammer or a lightsaber. In Gunmetal Arcadia, I want to have interchangeable weapons, which means the weapon art asset needs to be decoupled from the player sprite.
This introduces a new problem: aligning the weapon sprite with the character’s hand. If my art assets were locked down and I knew they would never change, I could hardcode this offset, but I’m trying to avoid those sorts of quick, dangerous hacks in this game. (Also I have no actual art assets yet.) The right way to tackle this problem is to provide data to position the weapon sprite in the appropriate location regardless of what my sprites and animations look like.
Enter attachment points. This system allows me to specify named points on a sprite which may exist only on one frame, or across an entire animation sequence, or for the entire duration of the sprite. Regardless of the scope of the attachment point, its location may vary per frame, as well. Using this system, I can place an attachment point on Link’s hands for the appropriate frames of the melee animation. At run time, I can look up the location of this point and spawn the weapon sprite at this location. When this frame ends and the attachment point is no longer in scope, the attached weapon sprite is automatically removed.
Compared to Super Win the Game, I’ve been moving away from relying mostly on implementing features in XML markup and towards providing an interface for facilitating features for this game specifically. To that end, I augmented the attachment point editor with a feature for automatically spawning an entity and associating it with the specified attachment point. This allows me to handle combat mechanics almost entirely through the editor and will make it much easier and faster to add new content in the future.
As a test, I replaced Link’s sword with a battle axe. Fun times.
Attachments are working. Here's Link with a battle axe. pic.twitter.com/LEt7GBXFPH
— J. Kyle Pittman (@PirateHearts) December 23, 2014
A few months ago, I gave a talk at the Dallas Society of Play about the CRT simulation in Super Win the Game. You can find the slides and some source code from this talk here:
One of these slides mentioned that I had considered an interlacing effect but had rejected it due to its framerate-dependent nature. In giving this talk a second time last month, however, it struck me that I was already using a couple other framerate-dependent effects which can be automatically toggled off or reeled in when vertical sync is disabled. Since then, I’ve had a note to myself to at least give it a try, which I finally did on Friday.
The good news is my plan for implementing the effect worked exactly as I’d imagined. The bad news is it’s a little hard on the eyes. Maybe not too surprising. Nevertheless, it fits within my target Shader Model 2 instruction count overhead, it’s easily tunable, and it adds a fair amount of authentic retro grit, so I’m leaving it in for now.
Trying out interlacing in the CRT shader. This is an extreme case. Obviously. #screenshotsaturday pic.twitter.com/giHuC593qx
— J. Kyle Pittman (@PirateHearts) December 27, 2014
The last big feature I worked on this week is another one that I’ve been sitting on for a while. I’ve had a note on my whiteboard for a month or two that says simply:
Ever since I set up the physics for Gunmetal Arcadia, it’s been apparent that vertical traversal will be significantly different than in Super Win. In that game, the jump height is moderately high from the start, and it can be amplified with a double jump and wall jump. By contrast, the jump height in Gunmetal is fairly low and gravity pulls harder on the downswing. There may or may not be powerups to increase jump height or add double jump or wall jump, but it’s clear that in the base case, jumping is not going to be a significant means of reaching higher ground.
Ladders and stairs seemed like the clear choice for diversifying levels by adding some vertical elements without requiring the jump height to be higher than I wanted. The question then was how to implement these. Ladders and stairs (of the NES Castlevania variety) tend to be a little awkward to implement because they add modal gameplay rules. For instance, while climbing on a ladder or stairs, you typically won’t be affected by gravity, you may not be able to attack or perform other standard actions, you’ll play a custom animation that may have some rules of its own, and so on. It represents an odd circumvention of normal gameplay systems, and that makes it a little more difficult to implement and more prone to introducing bugs.
My original idea was to implement ladders and stairs both in the same way, by placing invisible “mount/dismount” entities at the top and bottom of the path and specifying an animation to be played while traversing this path. I prototyped this implementation but ultimately rejected it for a number of reasons. It felt bad to only be able to mount a ladder from the ground, as opposed to in the air. It made dismounting from the top of a ladder difficult, and it required me to hack in some fixes to prevent the player from falling through the top of a ladder.
In light of those difficulties, I pushed stairs to the backburner and decided to focus on ladders, as they are the more interesting and versatile tool. Rather than using invisible entities to toggle the climbing mode, I added ladder tiles as a new type of world tile. For reference, other world tiles include solid blocks, harmful blocks, shallow ledges, water, and so on. Ladders are now a new kind of tile which the collision code can query and react to. They can be stood on and jumped through just like shallow ledges, but they can also prompt the player character to enter climbing mode when the proper criteria are met.
I’ve looked at a number of examples of ladders in 2D games, from classic NES games to modern platformers and roguelikes. I’m using Faxanadu as my model for how ladder traversal should work in Gunmetal Arcadia. In particular, I’m allowing horizontal movement while attached to a ladder, which allows me to use a string of ladder tiles in a row as “monkey bars” for bridging long gaps.
ɴᴏɴ-ᴄᴀɴᴏɴ #screenshotsaturday pic.twitter.com/MnXLdXDTjF
— J. Kyle Pittman (@PirateHearts) December 28, 2014