Well, first off, apologies on having to make another two-month devblog, and on having not really kept up on other weekly posts. Hopefully, though, what I’m about to say will make up for it: The demo/vertical slice that I’ve been talking about finishing for the last six months or so is finally done. Over the last few days I’ve been sending it out to a few test players, and early responses are encouraging! While there has been some feedback about structural issues I may need to address, so far it seems that the fundamentals of the game are sound and people enjoy playing it, which is a big relief to hear. The demo is a more-or-less complete (albeit subject to change) chapter 1 of the game, comprised of the first three zones of the map. It seems to take about 2-3 hours for testers to get through, which is a little meatier than I had expected, and represents probably somewhere from 10-20% of the complete project. Since I’ve been very focused on getting this out there, I’m taking this opportunity to briefly step back from the project, assess feedback, and take care of some other stuff I’ve been putting off – more on that at the end of this post. For the time being and foreseeable future the demo is private – if you’re a Patreon backer and are interested in access (I’ve already reached out to most of you) then send me a message and I can get you a key. Otherwise, I’ll probably open it up for some folks to stream at some point, so you can see what it’s all about when that happens – I’ll try to announce any such streams on Twitter and link videos when available.
Okay, so that’s the big news. What follows is the nitty gritty of what I worked on over the last couple of months, some of which was finishing up the demo and some of which was just miscellaneous other parts of the game I was interested in.
First off, I realized that the control scheme I’d been working on was not very controller-friendly: I had tried to restrict everything to the face buttons, but this was increasingly obviously impractical since there were three menu screens (map, inventory, and options) and only two usable center option buttons. Well, fortunately there were all these unused shoulder buttons, but implementing them meant I had to reconsider the whole control scheme. As there are (currently) only 4 special weapons, I initially decided to bind each one to a different shoulder button and move the inventory screen onto the top button of the main cross of face buttons (Y on XBox, Triangle on PS). However, on playtesting I quickly determined that I didn’t like this scheme at all, since it forced the player to memorize all of the special’s positions even when they only had one available, and selecting with this then using with another button felt very awkward. Instead I simply ignored the back shoulder buttons and set L1/R1 to cycle through specials, with the ability to hold either down to instantly select the heal ability. This will let the player quickly orient themselves in the line-up and cycle to the tool they want without looking right at the icon, while also opening up the possibility of adding more special tools later on if I’m so inclined.
Speaking of improvements to controller play, I also added controller rumble effects. The question of when it’s appropriate for a controller to rumble and when it isn’t is an interesting one: I personally feel like a lot of games tend to overdo it, adding significant shaking when there’s nothing very interesting happening, which can be overwhelming and confusing. Because of this, I tried to restrict controller rumble to mostly conveying important information: An enemy performing a powerful attack, one of your attacks connecting, or a pulse that gains intensity as the player loses health (a favorite element of mine from Silent Hill) and is timed to the music (a favorite element of mine from Axiom Verge). The interface I’ve created for rumble effects is dead simple – similar to how I handle transitioning post-processing and screen-shake effects – so adding future effects as they occur to me should be a breeze. It does feel a bit odd sometimes adding features that only some players will be able to engage with at all – as far as I know, there’s no such thing as a rumble-enabled keyboard – but I think enough people prefer using a controller for games like this to make it a worthwhile use of time and effort.
I also added a number of features to the dialogue system while I reworked, expanded, and polished NPC dialogue, including some changes on how character vox sounds get played. Normally, the dialogue interface plays the character vocal sound whenever a certain category of character is played for the first time in sequence – so if it’s set to vocalize vowels, when reading the word “sequence” it will vocalize the ‘e’, ‘u’, and ‘e’ as those letters are displayed, whereas if it vocalizes consonants it voices on ‘s’, ‘q’, and ‘n’. For most casual character conversations, a setting like this works well – however, for certain pseudo-words, such as “ssshhhh” and “ahhhh” this works very poorly, and sometimes I need a character to use something besides their default vocalization for when they’re yelling or whispering, or need to temporarily disable vocalization for a longer vox effect to have room to breathe. For all of these reasons I added a [v] tag to my dialogue system, which can either override the sound file used or override the vocalization rules so all or none of the characters are voiced. This effect is used sparingly, but is quite important when it appears.
I also discovered that the game was hitting some huge slowdown issues, which was odd and frustrating for a project with such minimalistic style. After a while learning how to use the Unity profiler (which I was aware of but hadn’t really had the opportunity to learn deeply until now), I discovered the slowdown had two main sources: First, the way that I had player profiles set up to store information was very inefficient, a huge list of game flags which had to be iterated through every time a game flag was changed, which I was able to replace with a much more efficient Dictionary object. Second, the sprite settings script that was a component of my sprite shader set was updating the rendering properties for every sprite on every frame, regardless of what changes had occurred, so I rewrote it to only write new changes as necessary – hopefully, and as far as I can see, without introducing any bugs, but only time will tell.
I was dissatisfied with how destructable blocks felt, so I added a little feedback in the form of controller vibration and slightly pushing the player back whenever they hit a potentially destructable block, whether it was damaged or not (as some blocks have special requirements for being damaged). This was one of those little tweaks that quickly ended up having huge ramifications: To make this tweak feel consistent, I also changed it so that you get the same feedback for hitting an enemy, so it functions as an all-purpose “you are hitting something” feedback, and this ended up slightly but significantly changing the feel of combat. Even more significantly, once I added this as a gameplay element certain things became obvious – such as that, for the exploding maggot enemy that sent you flying if you got hit, it felt ridiculous for it to just push you back slightly. Thus, I expanded the maggot’s code slightly to make it so it had the same knockback effect when popped with a sword as when stepped on, which immediately made it a much more interesting enemy. Now, rather than just being a small and slightly mobile alternative form of spike trap, it forced the player to consider whether attacking it to get it out of the way was a good idea or if trying that would just fling them into an even more dangerous situation. Immediately one of the least interesting enemies in the game became one of the most interesting, all because I didn’t like how destructable blocks felt!
In order for the demo to be complete, of course, I had to have some sort of an ending. I had mostly wrapped up the boss battle many months ago, but a few of the underlying systems had been changed and broken things. Even after fixing those, though, I wasn’t satisfied with the battle – the boss had too few moves, too few ways to transition between them, and often became stagnant and predictable. I spent a week or so just testing the fight out over and over, tweaking the state transitions and making the fight more dynamic. Of course, all this was only half an ending – the other half was in the scripted sequences, which became rather more complex in this section and which took me another week or so just to make sure flags got set correctly, effects animated correctly, that no contradictions broke anything, and so forth.
That all pretty much covers the work leading up to the demo. However, over the last couple of months I also wrote some new music. This is a pair of pieces for different sections of the same area, a dark place which gets weirder and more dangerous the deeper you go. This is a section intended to be revisited several times over the course of the game as you get additional capabilities, and is probably going to be where a lot of the deepest, darkest, strangest secrets get hidden. These tracks represent the first two sections: All to Waste, an NES-styled action version, and I, Refuse, a much darker, more melancholy version styled after SNES music. Who knows what the third version will sound like? I don’t… yet.
Okay, that covers the last couple of months! I may actually just make these posts bi-monthly, since it does help smooth things out so I don’t feel embarrassed by slow months and don’t feel like I’m spending too much of my monthly time/energy budget just describing work I’ve already done. If so, though, I’ll probably do it after next month’s update just so I can keep it lined up with the start/end of the year and won’t have awkward December/January updates again.
Now! What’s next? This month is going to be a bit of an odd one: While I collect feedback on the demo and consider my next steps on Bound City, I also would like to catch up on the mountain of adjacent work I’ve been putting off for the last, uh, 1-2 years.
First: I need to finish building a personal website: This is a project I started at the end of December and then got quickly sidetracked from, though I did manage significant progress in the meanwhile. This website will serve several important roles: First, as a place to centralize my writing into an ad-free space I can control, second as a place to host promotion and info about Bound City (and other past and future projects), and third to host documentation about any assets I release on the Unity store or elsewhere. Which brings me to…
Second: Soundmakr. You may recall that a few months ago I developed a tool for dynamically generating sound effects in Unity, and that I talked about selling it as an asset – and then, shortly after, as is my habit, I got distracted. In the meanwhile, I’ve had the opportunity to test it in my project, get a sense of how it performs in an actual game in development – and it is good. I think so, anyway! Because of its relative completion and straightforwardness, this is going to be my first target as a Unity asset to sell in the store. In order to make this happen, though, I need to quickly develop a free-standing demo version of the tool and to create documentation, tutorial videos, and a store page for it – which I think will take about a week, maybe a bit more.
Third: Palette effect. I haven’t thought of a snappy name for this yet, but it’s a pretty neat post-processing effect I developed for Bound City which I think I could fairly quickly build out into a publicly usable tool and which I think other folks might find useful. Right now a lot of it is pretty tangled up in Bound City-specific code, so it would take a few days to pull it out and build an interface, write documentation, tutorials, page, etc.
Fourth: Sprite Shaders. This was my main focus for several months prior to starting on Bound City, an extremely powerful and flexible set of sprite shaders for Unity. Because this is the most complex of the mentioned assets, I got burned out on documenting, fixing, and preparing these for release as an asset and put it off indefinitely, but a few small but vital fixes and improvements (such as the performance improvement mentioned above) means that they’ll be even better now than if I’d released them back then. Most of the documentation is already done, but it will take a few days to make sure I haven’t broken any of the functionality not used in Bound City, to make sure everything is documented and consistent, and to make, yes, tutorial videos and a store page.
Obviously I have my work cut out for me, and all-in-all this may be more than I can realistically accomplish over this month, but I’d like to at least get the ball rolling on all of this so that it isn’t all piled up when I get back to work on the game. I’ll be picking Bound City back up in bits and pieces as the end of the month approaches, integrating any feedback that seems applicable and starting to build out the next sections of the game. For now, though, it’s an opportunity to gain a little… perspective. And, maybe, make a little money while I’m at it.
If you’d like to help support this project or my writing, please consider supporting me on Patreon.