This week, I’ve been working on another facet of the core player actions in Gunmetal Arcadia: secondary weapons. These will be an alternative to the standard melee weapon and will encompass a variety of ranged attacks in the vein of Castlevania‘s knife, axe, cross, etc. Only one secondary weapon can be carried at a time, and each will have its own advantages.

In terms of implementation, I was able to leverage the attachment point system I wrote recently to spawn new entities at a certain time during an animation and at a specific location relative to the player sprite. Unlike the melee weapon attachment, however, the secondary weapon sprite is not fixed in place; once it has spawned, it is free to travel through the air and collide with whatever it wants.

One of my goals with secondary weapons is to facilitate a number of different play styles by modulating their behavior with other effects, in much the same way as items can synergize in The Binding of Isaac. So for instance, a basic throwing axe might be upgraded to pass through enemies after it hits them, bounce when it lands on the ground, and inflict fire damage. Or a throwing knife might split into two smaller knives that each home towards enemies. This technology doesn’t exist yet, but as secondary weapons start to come online, I will be building with modular effects in mind.

I haven’t yet determined whether these secondary weapons will be limited by hearts/mana/whatever arbitrary resource as they are in the Castlevania series. I imagine that will come down to testing and tuning, and in the absence of enemies, I’m not there yet.

In addtion to the secondary weapon, the player will always have access to a cache of bombs. Bombs can be placed on the ground or thrown from a distance and will inflict radius damage to both enemies and the player. More importantly, they can also break through certain surfaces.

Destructible terrain is something that I wanted to do in Super Win but didn’t make sense for a number of reasons. In that game, I constructed the visible mesh and collision mesh for each room once upon entry and never allowed them to change. Anything that needed to be dynamic was necessarily built from an entity object, including crumbling platforms and the “ghost blocks” that can be toggled on with the aid of a powerup. With the recent change to make collision dynamically generated only when it is needed, there was one less hurdle. I can now simply alter the underlying tile data, and the collision automatically updates to match. The visible mesh still needs to be updated, however. My expectation was that rebuilding the entire mesh would be too slow, but I figured I would start there and optimize where I could. As it turned out, rebuilding the entire visible mesh is fast enough that it does not produce a noticeable hitch even in a slower debug build. I have optimized it a bit by queueing up all changes to the terrain for a single frame and only rebuilding the mesh once per frame, but even without that optimization, I did not experience any loss of performance. Theoretically, larger rooms might take long enough to rebuild that it would be worth subdividing the visible mesh into smaller portions and only rebuilding the ones that have changed, but I can cross that bridge when I come to it.