It’s been an exciting and frustrating month as I keep running ahead and getting pulled back. This is the first time in quite a while I’ve gotten to focus on seriously expanding the game rather than just refining and polishing a narrow slice of it, which is both exhilarating and mildly panic-inducing as I struggle to slot all of the pieces of the puzzle next to one another in a way that makes sense.
Before any of that, though, came the final 1.3 version of the demo. This work dominated the first week of the month: Aside from a few bug fixes and balance tweaks that aren’t really worth mentioning, the main change introduced in this version was a significant tweak to the combat system, reworking most attacks to have a slight startup delay and an extra frame of animation. This provides another lever of weapon balance, in particular allowing me to change an early weapon that turned out a bit stronger than intended to be a bit more of a challenge to deploy. I also reworked some enemy animations to make their behavior a little bit more obvious and added some additional feedback as to when and how special weapons are being used.
Once that was done and 1.3 was out the door, I settled down and focused on building out the game’s map. The content of the demo comprises, I would estimate, somewhere around 20% of the finished map, so I’ve clearly got my work cut out for me. For the most part, I’ve just been focusing on figuring out basically what rooms are needed and how they ought to be placed relative to one another — a surprisingly exhausting and time-consuming process, considering how rough these rooms currently are, mostly just solid black blocks arranged as placeholders. Every room, though, is a convergence of several design challenges: What is it meant to convey? What happened here? What is the danger or interest of the space? How is the player supposed to navigate it? And so forth. These challenges are particularly tricky in the dense urban space that this part of the game is meant to take place in: Figuring out what an obstacle should look like, be themed around, while still conveying the concept of a city full of action and history, is a challenge.
Of course, in the meanwhile I sometimes go and play other games, other Metroidvanias and such, and can’t help but notice they usually don’t worry at all about any of this shit! Platforms float free of support in space, rooms exist with no history or practical application, backgrounds are generic tone-setters with little specificity, and so forth. It’s probably worthwhile to remember that probably few players will care as much about this as I do. Still, I personally find it important — Bound City, the city itself, is part of what the game is about, and I do want to do it justice.
As part of the level-building process, I’ve also added a little bit of flexibility to the tile set. Previously, all tiles the player could interact with were either solid blocks or drop-through platforms. However, as I’ve been developing the aesthetic and layout of the world, I keep feeling like the setup now, where stairs are represented as combinations of background elements and platforms, simply doesn’t feel very good in a lot of situations. Thus, I have added the dreaded sloped tile.]
With a few collision tweaks this works well enough with the player object, but there are a number of Ramifications that will take me some time, and probably lots of testing, to really contend with. One of the more minor ones is that the player animations sometimes don’t look very good on it, so it will require some additions and tweaks to resolve that. Another more significant one is that the existing enemies were developed with the assumption of all solid or platform tiles, so they may require a significant amount of additional reworking — particularly the spider enemies, which crawl along surfaces. The potentially trickiest obstacle I foresee at the moment, though, is the interaction with the player’s wall grab and climb abilities: Now that ledges don’t map completely straightforwardly with tile boundaries, a more generalized solution is necessary than the kind of hacky one I’d previously developed. I’m not wild about creating all this extra work for myself, but I really do think it creates a more interesting and varied space
Along the way I’ve also needed to tweak and improve some of the rendering fundamentals, half in preparation for future special effects and half just to have something to play with when I didn’t feel very driven towards hard problems. One of the effects I really liked in You Have to Win the Game and Super Win the Game, a pair of retro-styled platformers with incredible post-processing effects, was the subtle reflections created on the edges of the screen to recreate the experience of viewing on a CRT television. I spent a day on the related tasks of ensuring correct aspect ratio on every display, of creating these reflections, and of creating a rendering layer that bypasses most post-processing effects. The first of these is a technical necessity for compatibility, the second is a fun diversion that makes a pretty effect, and the third is largely unused for now but will be vital for creating certain special effects later on in the project.
Finally, reaching the end of the month, I decided it was a good time to fully implement the second special weapon (or I guess the third if you include the healing ability) — The Revolver. This was a design challenge I’ve been turning over and over in my head since the beginning of the project: What makes a satisfying gun, particularly in the context of a pseudo-retro platformer? What is the correct balance between aim and mobility? What’s true to the style of the game and creates interesting gameplay situations? My original concept for a gun was a weapon that could be aimed in any direction, but the issue with that is that it creates a conflict between the player’s directional inputs: Do those inputs aim or do they move? As I was working under a 1-month deadline on the original prototype, I decided to reduce this to the simplest possible version: The extremely early prototype of the game included the gun, but it just fired straight ahead, making it nearly useless against any enemy smaller than the player. I found this very dissatisfying, both in that it felt flat as an experience and that it had a very narrow use case. This version has remained in the game over the intervening couple years, but over the last few days I’ve gradually replaced it with the gun as I’d originally envisioned it, as it was meant to be.
View post on imgur.com
I decided to completely deprioritize movement when aiming the revolver, locking the character in place. This may seem strict in a platformer, but is fairly consistent with the other weapons and abilities, all of which restrict movement while being used. I also made very fine aim adjustments possible: Aim starts in whatever direction is pressed when the attack action is started, but higher or lower inputs swing the aim in the direction of the input rapidly with a bit of acceleration. Both quick reactions and fine adjustments are quite feasible using a D-Pad or arrow key, and using an analog stick allows direct 1:1 aiming input. This is also the first application of a mechanic I’ve been planning for a while, critical hits: Only the revolver and a few other weapons are capable of critical hits, but when using these weapons if you hit enemies in the head or other vulnerable locations you can deal critical damage, usually somewhere around 2x the weapon’s standard damage.
This month has been a real breath of fresh air — even if each new breath also brings a touch of hyperventilation as I get overwhelmed thinking about all the work that still needs to be done. Moving into June, I’m going to be detailing the world I sketched out over the last few weeks, adding some core interactive elements such as pushable blocks and switches that affect the world — and figuring out how to implement a fast travel system, both aesthetically and logistically.
If you’d like to help support this project or my writing, please consider supporting me on Patreon.