I’m back! Well technically, I was back from my honeymoon last Monday, but I had already scheduled that post in advance, so this is the first new material I’ve written since getting married and traipsing around Europe.

I chose to spend this week knocking out a few tasks that had been looming overhead for a while, the last few things that need to happen before I feel like the complete set of immediate player actions exists in some form. The first of these was to alter the size of the player’s bounding box in response to crouching and standing. Historically, my entities have had one primary collision primitive that never changes in size or relative location, which is why holding the down button in Super Win just makes the character tilt his head down rather than crouching. For Gunmetal, I wanted to have a proper crouch that could be used to avoid enemy shots, and that meant tackling this issue.

My editor now has a list of primitives which may be associated with animation sequences. At runtime, the game looks for changes to this setting whenever the current topmost animation sequence changes (as I mentioned in a previous blog, multiple prioritized sequences may be playing at once, with the highest priority sequence being the one seen on the screen) and toggles the appropriate collision primitive for that sequence.

There are still a few lingering issues left to solve here. For instance, I’m not doing any checks to see whether the new collision primitive is fully encompassed by the previous one; if it’s not, we run the risk of intersecting solid geometry and falling out of the world. (Consider the case of standing up after being crouched beneath a low ceiling. In this case, the full-size standing collision primitive would intersect the ceiling, and, in the absence of any proper handling, we could walk or jump through those blocks.) But in the general case, at least, this is working correctly, and I’ve been able to prove that crouching under projectiles will function as intended.

The next major feature I worked on this week is an extension of the palette swapping feature I implemented for sprites a couple months ago. I can now apply this same process to every 8×8 tile of each tileset in order to palettize environments. This is another feature that I contemplated for Super Win but rejected due to time constraints. For Gunmetal, this should be a huge win in terms of coaxing a variety of aesthetics from a smaller number of tilesets.

On the game side, this works a little differently than sprite recoloring. Each sprite is rendered in a separate draw call, so I can simply set each of the three palette colors as shader parameters prior to drawing. By contrast, each layer of the environment is drawn all at once in a single draw call, which means all the colors for each 8×8 tile must be specified somehow. My solution is to aggregate all the palettes into a texture atlas (shown below in PIX) and then index into this texture with a new texture coordinate channel added to the environment’s vertex buffer.

In fact, with a little more work, this pattern could be generalized to encompass sprite rendering as well, such that I could draw all the on-screen sprites in a single draw call. This would depend on packing every sprites’ sheet into another texture atlas and maintaining a fixed-size dynamic vertex buffer whose vertices could be allocated to each sprite’s quad, in much the same way I handle  font rendering. Sprite rendering isn’t a bottleneck at the moment, however, so I probably won’t go down this road, but it’s certainly interesting to think about.

I did some minimal work on Saturday to faciliate vertical attacks while airborne, a la the downthrust and jump thrust attacks from Zelda 2 (or the pogo attack from Ducktales, or from Shovel Knight, or whatever). I’m not 100% sure this feature will make the cut — this depends largely on whether it feels necessary once I have more representative combat spaces blocked out — and it will need some further attention to make it feel good, but I wanted to hack it in there in some form, as it’s one of the last immediate player actions I’ve been considering.

Finally, I’ve started implementing a HUD. I don’t know for sure yet what information I’ll want here, in part because I haven’t yet decided how some game systems will work (e.g., will secondary weapons consume ammunition?), but since I’ve been working on combat recently, it’s important to at least have health represented in some fashion. I’m toying with the idea of displaying enemy names and health on the HUD, which isn’t necessarily in keeping with the style of the classic games I’m imitating, but I think it could be nice for bosses at the very least. Theoretically, a minimap might be a better use of that space, although depending on the size and topography of the levels, a minimap might not be necessary for this game.

I’m reaching an exciting point where the individual systems I’ve been working on are starting to coalesce into something that resembles a game. I suspect sometime within the next few weeks, I’ll be able to publish a small demo as a means of collecting feedback on the feel of core mechanics, the first step in a plan to involve players in the development of Gunmetal Arcadia all the way to launch. I’ll be talking more about this plan and a roadmap for the future next week, so stay tuned!