
Well, my assumption was that after finishing the demo, I’d be mostly taking the month away from Bound City to focus on other things. That didn’t happen so much for two reasons: First, the feedback from the demo and bugs uncovered in playtesting felt like they needed to be addressed, so a significant portion of the month was spent developing new versions of the demo with various tweaks and fixes. Second, around halfway through the month I came down with a fairly nasty cold, which completely destroyed my ability to focus for about 10 days, so this was effectively 2/3rds of a work-month. For the most part, the month was taken up by listening to feedback, thinking about it for a while, and trying to address that which was in the scope of the demo.
First, a lot of people complained about spikes, both in terms of them being visually identifiable and in terms of how brutal they were. I already had a system in place to make spikes visible from a little further away than normal terrain, but given how much visual noise the lighting system has I don’t think dimly lit spikes really visually registered as dangerous. I changed the spikes-only lighting to be more flickery and red, so the peripheral glances of them might more readily register as dangerous. I also toned down the damage a little, as it was extremely brutal for this stage of the game.

Another challenge which didn’t quite work as intended was the boss battles. I quickly learned that one necessary step in testing a boss battle is to ensure that the tactic of walking up and attacking over and over is not an overly effective one! With version 1.0 of the demo, boss attack speed and aggression were low enough that the knockback of basic attacks was sufficient to mostly keep them at bay, and their attack frequency was low enough that even when they could sneak attacks through they weren’t keeping up with the player’s more steady damage output. However, once I made the obvious tactics no longer overpowered, the bosses became significantly more challenging to deal with even using normal tactics. Work balancing these boss fights, ensuring that they’re fair and readable while not being trivial, is ongoing — it’s a tricky process, but quite satisfying.

A number of complaints came in regarding specific areas in the levels. Most of these centered around either an enemy near a screen transition or an enemy being introduced for the first time in a way which was confusing. I was vaguely aware of this as an issue, but it seems clear in retrospect that the way an enemy is first encountered — particularly an enemy that requires a different method of engagement — is very important. Moreover, I realized that I need to be paying careful attention to where these encounters were pushing players. A difficult encounter in the wrong place might guide the player away from an interesting moment, or even a health upgrade or save point — making all future encounters that much more difficult! Placing enemy encounters will, naturally, be an ongoing process of level design, and I’m sure I’ll make more mistakes like this in the future. In the meanwhile, I’ve learned a few more things I’ll have to pay attention to.


This is around where I got sick. I was working on the standalone version of SoundMakr kind of half-heartedly, and as I recovered and my energy came back my mind was on fire with possibilities for things to do with Bound City, improvements to make to the demo, additions to make to the main game, what to do next, what to build, where I was going. Inevitably I shifted my focus away from the relatively tedious work of making a UI for SoundMakr and towards a final version of the demo that addressed as much feedback as possible.

Another thing I’d heard from a number of people was that the map wasn’t as useful as it could be. I wracked my brain thinking of ways to make it more useful — perhaps the fact that map tiles had such different dimensions from room tiles (1:1 vs 8:5) made the map less legible? Maybe there needed to be more terrain information to make the rooms immediately identifiable? Maybe… Oh! It turns out that one of the core map features, the display of connections between rooms as dotted lines, was simply not working! Each room was displaying as a solid block, so discerning the relationships between them was nearly impossible. This turned out to be because the code to find exits (to later display them on the map) only worked if the room’s GameObject was enabled — because all rooms start disabled, that meant it was seldom-to-never actually working when the map was generated and displayed. As it turns out, fixing this problem was surprisingly tricky. Neither 2D colliders nor Unity’s Tilemap system can be used well when disabled, so I had to prod around to figure out where the systems did and didn’t work before I could finally build something that worked regardless of the GameObject’s current status. Now… it may be that if these rooms change based on game progression whole new problems could emerge, but that’s a problem I can hopefully address later.
I also made several improvements to the map system in addition to the bug fixes. Map tiles were changed to be 18×12 to more accurately match the size of rooms — it’s still a bit off, 4:3 instead of 8:5, but having one side even and the other odd made adjoining rooms look kind of bad since the dotted exit lines didn’t line up well. However, as the tiles were no longer square, they could no longer be rotated in 90 degree increments (only 180), so I had to make a bunch more tiles to compensate and rewrite the tile selection code to account for the new restrictions. I added a display for save points on the inactive room layer so the player had more information about where they all were, and I added a tile display for room tiles which were known to exist due to connected explored tiles but which hadn’t been explored themselves. The final result is a little bit cramped, but very informative and, I think, pretty nice looking.
A complaint from several testers, which was very revealing of my own blind spots, was that the inputs from analog sticks felt a little finicky and inconsistent. Now, I’ll strenuously avoid using an analog stick in a 2D platformer where possible, so I simply never thought to test these controls very much! I’m still not sure quite how I’ll be handling these issues — what I’m experimenting with so far is making the dead zone much larger specifically for up and down inputs, so it is more difficult to accidentally input these directions, but frankly all 2D platformer analog inputs will feel pretty bad to me so I don’t know exactly what will be satisfying to others.
There are other things which didn’t receive much active feedback but which seemed to be confusing to testers. The behavior of breakable terrain tiles seemed to cause a fair bit of confusion: There’s nothing explicitly introducing the concept, so without knowing it’s a possibility many players don’t bother looking for it. Additionally, the differentiation between breakable and non-breakable visually similar tiles caused confusion, as well as tiles which required specific damage types to break. There’s a lot going on here and I suspect this is going to be something I’m tweaking for a long time: Part of it comes down to the specific visual look of breakable tiles, part of it comes down to conveying the idea of secretly breakable tiles, and part of it comes down to conveying the idea that there are certain damage types necessary to break certain kinds of tile. I keep thinking of Super Metroid’s solution of just showing you a little picture of the particular item you need to break a tile, and while I find it extremely inelegant I can see why that’s the way they went with it.

There is also some feedback which I’m not going to be addressing in any demo updates. Some of it requires sophisticated solutions which are going to take a lot of time and testing before I’m satisfied with them, so they probably won’t find their way back into the demo at that point — an example of this might be the issues people have had with the interactions between attack animations and movement. Some of it I need to think about for a while and figure out if there’s a way to address it while staying true to what I want the game to be, such as issues with the lighting system and rendering style. Some of it I have a pretty good idea how to address but is going to be a longer-term approach which will shape how I develop the game out from here and perhaps move around content so it’s encountered differently, such as issues regarding early-game dialogue density and relevance.
Anyway, within a few more days of work I’ll be wrapping up version 1.3 of the demo, which I intend to be the final version — I intended that for version 1.2 as well, but I’m intending even harder now. With that I will of course be building the game out more, expanding the world map, adding/implementing planned upgrades, new enemies, and so forth — all the exciting work I’ve been putting off to focus on getting this first part of the game finished. However, at the same time I need to be seriously considering what the future of this project is and how I want to approach it. My default inclination is to just keep my head down, keep working on it for year after year until it’s done and I can be proud of it — but whether it’s now or then, I need to figure out how I’m going to share this, how I’m going to sell this, how I’m going to make it something people experience instead of just a hobby.
If this kind of approach came easily to me, I probably wouldn’t be the sort of guy who spends years developing solo game projects! What do I want promotion of this project to look like? What do I feel I can consistently offer in terms of promotional effort? Should I be looking into crowdfunding? Should I be looking into a publisher? I’m not sure, and each question digs into the insecurities I have over ever sharing work ever, insecurities which only cut more deeply as I put more and more time into a project. Inevitably, these discomforts just lead me to wanting to put my head down and work more, avoid them by just making something bigger and stronger and more beautiful — nevertheless, someday I’ll need to decide on an answer.
If you’d like to help support this project or my writing, please consider supporting me on Patreon.