Bound City DevBlog, September 2023 – Training and Derailments

For reasons some of you may be familiar with, September was a hell of a month. Along with many other independent game developers I was knocked significantly off-track by Unity’s antics, and it’s something of an open question exactly how big of a problem that will continue to be. I’ll dive more into that a bit later on – let’s start at the beginning.

At the end of last month I was wrapping up an extensive and annoying rework of the dialogue system. This whole process was very frustrating and tedious, but I wanted to follow through on that work and build the Notebook – an inventory item the player could use to track progress and dialogue, an entry point back into the game for players who hadn’t played for a while and a way to communicate some non-obvious details about how the game systems work. This all adds up to a not-insignificant challenge: How does all this information get displayed? Where do I store the information? How do I format it? 

One of the trickier features I had to tackle was a way to display enemy attack hitboxes and damage. This is made particularly tricky by this information changing with each enemy movement and attack. Unity’s UI elements have completely different display properties than the sprite renderers used in gameplay, adding another layer of challenge to getting this display working. I built out the UI and an enemy sandbox room with its own camera that just gets rendered out to an image for the enemy display to use. I also figured out how to copy out enemy hitbox information into a SpriteShape display so the collision data can be visible in real time.

This is a pretty solid start, but there’s a fair bit left to do. Everything so far is partially implemented and untested, and I still need to hammer out some of the specifics of how old dialogues will get displayed and how the journal will be implemented. However, all of my efforts to figure this out were interrupted when Unity, the game engine I’ve been building the project in, decided to ruin everything for everyone.

For those of you fortunate enough to be unfamiliar with these events: A couple of weeks into September, Unity announced their new pricing plan. Under this plan, after a game reached certain thresholds Unity would begin charging game developers per game installation. The exact amount charged varied based on license, but the following facts were true regardless: First, there is no plausible way to track the number of times a game has been installed by users, and suggesting otherwise raises Questions. Second, there is no way for a game developer to account for these hypothetically unbounded expenses, putting every developer at unknown levels of financial risk, particularly if these numbers can be manipulated by malicious actors. Third, they’re asking us to place our financial futures entirely in the hands of their opaque black box algorithm and abide by whatever number it spits out. Fourth, declaring that these changes can happen retroactively and affect everyone who developed in the engine in the past, who had no opportunity to disagree to the terms or account for them, establishes a, let’s say, worrying precedent.

Now: They have since amended their proposition to cap the fee at 2.5% of gross revenue and to require devs who cross a sales threshold to pay a $2000/y subscription to Unity Pro. This is unequivocally better, in that it is an expense that one can realistically plan for, that there’s now no scenario where they can simply claim a game’s entire revenue because of some behind the scenes numbers. It’s still simply not very good: While these terms only apply if you update to the newer engine versions, they have not to my knowledge added anything preventing them from trying the same retroactively applied abuses as they proposed before, or from changing these cuts to be even worse down the road. Additionally, these sorts of revenue shares are an egregious pricing model in the first place, particularly coming on top of an exorbitant subscription fee. However, this is at least enough of a compromise that I can countenance finishing the project in this engine, which I was otherwise having serious doubts about.

I mention all of this for two purposes: First because I’m still mad about it and wanted to vent a little, and second because development of the notebook feature got completely derailed by all this. The couple of weeks following this announcement were mostly occupied by shock and anxiety, then explorations into what would be needed to port the game to another engine such as Godot. The answer I arrived at, after a fair amount of exploration and experimentation, was: A Lot. Many of the game’s systems and rendering solutions are tied pretty intimately into Unity’s architecture, and these would need to be painstakingly reproduced. That being said, it wouldn’t necessarily be a completely ground-up effort: It would probably be possible to export and reimport the basic levels, though scripting and lighting might be trickier, and the sound systems could probably be rebuilt relatively quickly. Still, if there’s any way to avoid these months of additional tedious and depressing effort, I would prefer that.

All of this, of course, was terrible for morale. I still haven’t resumed work on the notebook feature – not least because this is one element that would need to be rebuilt more-or-less completely to port it into another environment – and have instead focused my efforts on level-building. This should be relatively satisfying – it is one of the most direct and active tasks I can do on the project! To some extent it is satisfying, but I am still so tired from all of the Unity issues and from various other life events that my energy and enthusiasm are at a notable low point.

Still, even if I’m tired and frustrated, the problems presented by this project are fun and interesting ones. In particular, I have been building this with more of an eye towards verisimilitude, towards building an environment that feels plausible and lived in, than most games seem to be interested in – particularly action games, and particularly 2d platformers. This results in some pretty odd circumstances! For instance, in building a parking garage, what does one expect to be there? Perhaps a staircase and elevator for people to go up and down on their way to and from parking, and perhaps a ramp for the cars to drive up or down to change levels. But: What does that mean in a 2d platfomer? Most of the stairs in the game are non-interactive background elements placed behind one-way platforms.

This creates something that serves the same purpose as stairs, and are interacted with in a similar way, but which in practice the player jumps up an entire flight at a time. What’s so remarkable is how invisible this arrangement quickly becomes: The stairs read as stairs, the platforms read as platforms, they both seem in place, and the player doesn’t even notice how odd the specifics of the interaction are. However, I’m not sure how far I can push this dynamic before it starts to get weird. Returning to the parking garage, the specific example that prompted this line of thought, let’s look at what the ramp looks like:

It’s the same theory as the stairs. Make something that looks like a ramp, make a set of platforms that can be used in the same way and fit into the art, and hope the player never thinks about the bizarre non-sequitur logic of using a ramp this way. Will it work? I don’t know! This seems to really push the boundaries of visual plausibility, but it also looks kind of fun and interesting. Whether it works or not is something that will probably require some testing and feedback to determine. If it doesn’t, well, there are always alternative solutions.

Anyway, as the project lurches unevenly along I’ll be continuing to build out these levels. There’s still much to be done even on that front alone — I’m maybe a third of the way into level-building for the next demo, and of course there is much to be done aside from that basic construction work, so I have my work cut out for me. Let’s hope there are no more announcements like this recent one any time soon.

Bound City DevBlog, August 2023 – Towing Lines

Most of this month was taken up working on tweaks and changes to the dialogue system, which is definitely not how I had hoped to spend this time. One fix to the system required another more fundamental fix, which led to bugs, which required fixes which themselves required other fixes to the core system to enable, and so on and so forth over the course of three weeks or so. All-in-all this has been one of the more dispiriting months on the project so far and an object lesson in the dangers of relying on third-party tools. I think the real lesson I need to take from this is that at the moment where the third party tool’s capabilities and my requirements begin to diverge I need to immediately consider dropping it and rolling my own, because working around limitations like that can be An Ordeal. Now that I’ve done it, I may try to compile all these experiences into a list of recommendations for the developers of Yarn Spinner to implement internally so no one has to go through this in the future.

Giving a play-by-play of this entire struggle would probably be boring for you and stressful for me, so let’s skip that even if it comprised about 2/3rds of the month. I did achieve some notable work before and after this bleak venture that might be interesting. First, and precipitating much of the above-mentioned struggle, I built an interface for asking NPCs about keywords:

Now that I have everything I need to query the dialogue system for which lines have been played or not and which lines can be reached from every other line, I can have these keywords fade out as they’re played. Yes, that’s what all this effort was meant to achieve: The mere ability to query whether there was more dialogue available on any given dialogue branch. 

Another little flourish I added to the dialogue system is the ability for characters to play incidental dialogue lines into the game world without changing the game state to dialogue mode. This makes it a little bit easier for the player to spot NPCs, since they can say something when the player encounters them, and I think a little later on will be a great way to add a bit more flavor to boss encounters, with the boss cursing or gloating as the battle progresses.

I also added some new background tile art to flesh areas out a bit more:

Ideally I’d like to have posters and graffiti be modular tiles so I could construct something that looks relatively natural, but in practice it can be difficult to compose images in such a way as to make that possible. I may give it another shot later, but in the meanwhile just having a bunch of little pictures that I can place where posters ought to go or the like is probably going to add a lot to each area visually.

Of all the work I did this month, though, I’m most pleased with the new music composition. First, I started developing a character theme:

This is mostly background for a conversation with one of the game’s more important characters, and I’m a bit worried that it’s a little too busy for that purpose. However, I really like the overall mysterious and wistful tone, which I think will fit the scene well. I’ll probably leave it as-is until that part of the game is implemented and I can decide how it feels in place.

I also went back and revisited one of the stage themes I’ve been meaning to develop a little further. This is one of the first pieces I created for the game – actually, I originally wrote the sketch that became this piece in 2008, wasn’t sure what to do with it then, and changed it to the chiptune style when I was figuring out what this game would sound like during the first month of the project. I expanded it a bit then, but this time I revised it completely, adding new melodic lines, changing the instruments around to make it better balanced, and adding little pitch-bend details to the instrumentation (a technique I’d just started experimenting with in Burnt-Out or Oxygen-Deprived). I’m quite happy with how this all turned out, and I think this feels like one of the stronger tracks now. I always knew that that sketch I made had potential, and I’m happy that finally, 15 years later, I’ve managed to make something that lives up to that potential.

In the midst of all this, I finally invested a chunk of time and money into updating the old dilapidated laptop I was using for a mobile workstation – not least because, as I am planning on moving soon, I expect to be working on the go significantly more often. I am simultaneously excited about how nice it is to be working (and gaming) on a modern machine, and stressed about having to spend a thousand bucks to make that happen, but over time I hope the latter will become less acute.

So, with all of this dialogue reworking behind me (hopefully), what’s next? There are still some fixes and tweaks to be done to the display of keywords and dialogue choices, but after that I will have to build the journal. This inventory item will track all dialogue lines played (another reason I’ve been working so hard on this system) and make it so you can look up any conversation later on. It will also store a short summary of “the story thus far” so the player can quickly catch up after taking a break, a list of known keywords that also works to look up dialogues, a reference manual for any non-obvious gameplay tips the player may need to refresh themselves on, and an enemy bestiary with information on attack patterns and weak points. It’s entirely possible I may decide one or more of these aren’t worth the trouble and cut them later, but that’s the current plan. In the likely event that I want to take a break from dialogue stuff altogether for a while, I also have plenty more level-building to do, which would be a real relief after all this.

Bound City DevBlog, June/July 2023 – Swings and Arcs

Around the start of July, I went on a trip for a couple of weeks. I mention this to explain why this is another two-month DevBlog: When a trip like this coincides with the start of the month, it’s easy to get distracted from posting updates while I prepare for the trip, and then once I’m traveling I don’t have the time or energy to rectify that. When I get home a couple of weeks later, it seems like there’s not much point to posting such a late update, so I combine it with the next month’s update — which is probably fine, since with trips like that I end up doing about half as much work over the month anyway.

After putting the finishing touches on the revolver special weapon I mentioned in the May update, I started addressing a fairly common bit of feedback I got from the demo: Several players felt the weapon attacks were a bit clumsy, and found themselves frustratingly committed to attacks that were slightly misplaced in one way or another. At first I had no real intention of doing much about this beyond tweaking attack timing and so forth to make the whole thing feel a bit more fluid — however, a suggestion that came up a couple of times to address this was the idea of adding some directional control to attacks, and this idea has been floating around in my mind and gestating…

At the same time, one of the ideas I’ve been thinking about for a while is that of weapons that have significantly different attack patterns and styles. A lot can be done with the sword swing animation I started with but I found myself running up against its limitations. Iif, for instance, I want to add a rapier or spear weapon (which I do) then these attack animations work quite poorly. At the same time, if a weapon like a spear were to be added, it should offer some unique advantages over other weapons — range, obviously, but the ability to attack in more directions and from more angles also made sense. These two ideas seemed to dovetail nicely together, so for the first couple weeks of June I extensively overhauled the weapon and attack system to bring them into reality. 

At this point there are three classes of weapon attack: Swing, the default type which all the old weapons in the demo belonged to, now with the added ability to aim up/down by 33 degrees; Thrust, which includes fists, spears, and rapiers and can attack in 45-and-90-degree angles; and Two-Handed, which has no directional attack and can’t be used while climbing, but has a very wide arc of attack.

The way attacks were implemented before, creating all of these weapon and directional attacks would have required me to create a full custom animation for each attack direction. Attacks were implemented as a weapon overlay placed on top of the character sprite, which contained both the visual representation of the weapon and of its attack, an arc of dissolving pixels. I extensively reconfigured the player animations, creating a set of attack animation frames that ended up being significantly more numerous than all the non-attack player frames combined. To keep things within a modicum of reason, I made the attack preparation and recovery frames the same across every direction of attack, with only the two frames of actually performing the attack changing. Additionally, I stripped the arc of the attack (the “flash”), out of the weapon overlay and made it so these effects were generated from a couple of sprites and a programmatic fade.

All of this was a lot of work, but relatively straightforward. Much more frustratingly, I found myself struggling for several days with the Unity Animator system. The logic chart I use to play animations works relatively well with a small set of animations but, as things get bigger and more complex, cracks begin to emerge. Animations started to get desynced by a frame or two, or display the wrong sprite for just a frame — little issues, but unacceptably jarring in practice. 

After a lot of frustration, I eventually found that two Animator features I had been overlooking were indispensable: Layers and Blend Trees. I had discounted these features early on, as their descriptions were all couched in terms of animating a 3d character and they were focused on use cases such as making a part of a model do one animation while the rest of the model did another. However, these also provided some crucial functionality that could still be used with 2D frames: First, layers allowed me to take all of the dense logic of weapons and attacks and completely separate them from the standard player animations, which let me prevent the rapidly developing situation of having a hundred ugly and error-prone crisscrossing lines of logic.

Second, blend trees allowed me to have a set of synced animations that I could snap between based on a parameter, which allowed me to enable the player to change positions during attack recoveries without resetting the animations.

While I was doing all of this, I also began implementing the Charge Attack upgrade. You’re probably familiar with the basic idea from other games: You hold down the attack button for a second or two, then release it to do a special super attack. I’ve been thinking a lot about how this is going to work. There are two ways I’ve seen this type of attack go wrong in other games: The first is when there’s no drawback to charging so the player just ends up constantly charging attacks, making inputs a little more complicated for everyone for no particularly interesting tactical result. The second way, conversely, is when charging restricts your movements and actions to a degree where it’s seldom ever really worth it compared to just attacking normally. 

It was very important for me that charge attacks feel useful but situational, something everyone would want to use sometimes but few people would want to use to the exception of normal attacks. It remains to be seen if I can hit that mark — a lot of testing will have to happen before I think we’ll know — but I am doing everything I can to address it now. Charge attacks do leave you completely immobile during the charge, but you can conserve momentum from a jump to minimize this vulnerability, and, while you probably will do less damage with a single charged attack than if you just spammed standard attacks, charged attacks will have the unique ability to parry enemy attacks, canceling them out and dealing additional damage, as well as deflecting all projectile attacks back towards their source. That last part isn’t implemented yet, and all of this will require a lot of fiddling and testing, but that’s what I’m aiming for. This also means that charged attacks may be required for entering certain areas blockaded off by otherwise unavoidable damage!

Doing these attack reworks took a couple of weeks, and once they were wrapped up I was pretty tired of creating art and animations, so I decided to work on something a bit more purely programming-focused. A concept which has come up in a number of different places over the project so far is various forms of special level tiles. At first, these were just breakable blocks placed to hide secrets, then more breakable blocks placed casually to make encounters more interesting, then falling breakable blocks that did damage for a boss’s special attack. For a while these different types had functionality spread across different classes and prefabs, but now they are combined into one dynamic block class, along with additional functionality allowing the player to push and stack blocks, and for the blocks to subsequently permanently remember the positions they were pushed to. With this, creating permanently unlocking shortcuts by nudging a block or two is now possible. A few tweaks and improvements still need to be made: As you can see at the end of the demo video, some weird collision situations can be created which might result in the player falling out of the world. I would also like to be able to anchor blocks to each other — so, for instance, one block might not fall until the other is destroyed, which I think will feel much better for conceptually solid pieces like logs or beams, and could lead to some interesting puzzles and effects. Additional special terrain types like elevators and conveyor belts will probably also eventually be implemented in this class.

I made another fairly minor change with potentially major ramifications: it’s now possible for the map to change dynamically based on the game state. For instance, I might have an intact and ruined version of a room which I can flip between, or a room that only exists under special circumstances, or an entire section of the world map that gets flipped out for another one. This all would have been possible to fake before by making special entrances between levels, but doing it this way ensures that any changes will be reflected on the map screen as well. I also worked on building a series of special rooms: The player will probably start to encounter these shortly after where the demo ended, and there will be one of them for each area. I have the first couple completed, for the hotel and park respectively. I am quite pleased with the results so far. The park’s room is the header image, here is the hotel’s:

This is the point where I left on the aforementioned trip. I started working on a piece of music before the trip and managed to more-or-less wrap it up over the course of my travels. This piece is the track for the confrontation with the dragon, a character who you’ve mostly been just hearing rumors and confused snippets about up until this point in the game. I’m broadly pleased with where the piece is at now: I was having a lot of trouble keeping all of the parts from sounding muddy against one another and keeping the audio from clipping, but I think it’s finally come together pretty well.

Aside from this, I’ve mostly been working on fleshing out the next major section of the game, the Undercity. Since this whole section is mostly intended to be subway tunnels and stations, it was difficult at first to keep the terrain feeling varied and interesting, but I’m really pleased with how it’s starting to come together. Each stretch of tunnel and track feels dangerous and challenging in a slightly (or significantly) different way, and each station feels like it’s got its own personality that’s somewhat related to the section of city it serves. However, so far it’s just terrain and lighting: I still don’t know what the enemy encounters are going to look like, what the specific challenges and obstacles are going to be, what the moment-to-moment experience is going to look like. I’ve got some ideas, to be sure, but more ideas will be needed to fill the gaps, and the ideas I have will change over their implementation.

I’ve long been having second thoughts about the dialogue system. I was broadly happy with it and the responses to it in the demo were generally positive, but I noticed some issues, and the more I thought about these issues the more they bothered me. Players would speak to NPCs once and move on, not realizing they had more to say, or they’d repeatedly accidentally use items from the inventory, or they’d be unsure why they were having a conversation with a character or where it was meant to go. These are the sort of issues players don’t voice — you can’t complain about the things you never notice — but it feels like it quietly undermines a lot of the narrative of the game. I’ve been thinking for the last couple weeks about how I want to rework things to address those issues. First, I think I’m going to streamline a lot of the “use/give” item functionality in the inventory, so this is only possible with key items you’re likely to want to investigate or find unorthodox uses for. Second, I’m going to be introducing the idea of keywords. A few games have used this concept, the main one I’m familiar with being Final Fantasy 2 (not 4, I know it’s confusing). With this system, if you encounter a keyword in dialogue, it unlocks the ability to ask other NPCs about the keyword and uncover new information about it, potentially unlocking new keywords to inquire about and so on. I really like the idea of how intentional this makes the process of investigation: You can choose to specifically ask about an idea you’re curious about, and the causal relationship between that investigation and your options for future investigations are made clear. It also means that, whenever I get to implementing the Journal item to track dialogue and other information, you might be able to quickly look up everything you’ve learned regarding a given keyword.

There are a lot of remaining questions, even as this design takes shape. Can you ask every character about everything, even things it’s extremely unlikely they’ll know about? Does everyone use the same word to refer to the same characters and concepts, or are some keywords aliases for one another? Should items you can ask about appear in the keyword list? Some of those ideas I’ll probably only figure out once I start grappling with the specifics of the system. In the short term, I’m glad to have figured out the generalities – even if it means I’m going to have to spend a little while rewriting character dialogue to fit the new format.

I’m starting to get a sense for what the scope is for the remaining work for this second slice of the project. It’s a lot, but it feels manageable, and it’s exciting to start to see things take shape and solidify all over again.

Alternate Roots

I’ve been feeling a little unenthusiastic about writing these posts recently. By “recently” I mean that I’ve been feeling it gradually over the last few years, and more acutely over the last few weeks. There are a few reasons for this: One reason is that I can’t escape the sensation that I’m repeating myself a lot, reiterating more-or-less the same ideas in more-or-less the same ways. It’s not uncommon for me to start brainstorming an idea only to take a look at the archive and realize I wrote about it, or a very similar idea, several years ago. Another reason is that I feel like overall the quality of this work has been slowly declining – there are still better and worse pieces, and some I’m very proud of, but it often feels like I’m cooking with leftovers. Third, I just have no idea at this point whether anyone is interested in this writing, and if so which writings they’re most interested in – this lack of sensation probably contributes to these other dissatisfactions, since without feedback I can’t readily tell what work is worthwhile and which ideas are worth delving deeper into. 

All of the above is made more challenging because I’ve been so excited about my main project, Bound City. Any time and effort I’m not expending on that project feels somewhat wasted – in most cases it is a better expression of the ideas I usually write about. Why bother writing about game design when I can game design about it? Why bother ruminating on art and life when I can simulate life in art?

This might suggest the entire blog/mini-essay/Patreon endeavor has run its course, but I’m loathe to just retire the Problem Machine blog – both because this steady output helps me to emotionally and creatively regulate and because, well, now that I’ve got a Patreon running it seems like it would be a nuisance to shut it down only to most-likely start another one later. However, my commitment to a format, to trying to do one piece of critical writing a week, is beginning to feel like it’s doing a disservice to my abilities and passions – and to whatever audience might want to enjoy or support my work. Now that I’ve managed to articulate these obstacles, it’s become apparent that I will need to change how I approach this writing and creativity in general.

I recently started realizing the pains I’ve gone through to avoid ever having to think about any audience I might have: In my fear of having my work rejected, I avoided ever considering how it is received. It is the curse of the artist to constantly seek attention while constantly avoiding scrutiny, to spend tiny eternities crafting masks for the world to see instead of your face. While making this Patreon several years ago was a step in the right direction. Since that time, I’ve retreated back, as is my habit, to a place where I never need face an audience directly, a place where I can once again hide in my thoughts. The idea of trying to promote myself, of trying to simply tell anyone that they should look at what I’m doing and should find it interesting, has been a very difficult one for me, and one that still causes me anxiety to contemplate. My attempt to compromise has so far has been a sort of shotgun approach, creating a large amount of relatively quick and low-effort work – not that I don’t put energy and thought to making each mini-essay as solid as possible, but I have constrained their scope to the smallest, purest, and most perfectly-expressed angle on an idea I can, such that it’s almost impossible to spend more than a couple thousand words on it. With this small investment, I can cast it to the open sea to fend for itself as it may, and if people like it I can be happy – and if they don’t I can remain contentedly oblivious.

However: Eventually, hopefully, I will finish this game I’m making, that I’m spending years on, and once I do it will be truly devastating to me if no one looks, no one plays, no one cares. As things stand, I have no practice in making people look, making them care. My goal, now, is to create things that I can advocate for, to gain practice in advocating for my work, even if it means I end up creating somewhat less consistently. When I started writing this post weeks ago, I intended to change things up and start doing large monthly projects. I even made some progress doing one of these before I ran up against a huge question with no satisfactory answer: When the hell am I supposed to work on it? I soon realized that I would have a very difficult time following through on that idea, and didn’t feel ready to commit to doing so. Sometimes a commitment is exactly what one needs, and if all that was standing in my way was nervousness and anxiety I’d push through — but, though I have plenty of both, in reality the real challenge is time management.

The question, it turns out, is not whether I have the time and energy to do additional projects on top of the game, but one of what sort of time and energy I have. I’ve created little 2-3 hour niches in the week that are suitable for going to a room and tapping away for a bit on an idea, but that’s a wholly different pursuit than if I wanted to, say, create a full song with lyrics or a video essay or something. The amount and kind of energy required differs, as does the amount and kind of equipment. The more complex and sophisticated the task, the more likely it involves me sitting in front of my computer — which is where I work on the game, naturally, so any time I’m in front of it I feel like if I’m going to be working on anything it should probably be that core project.

I’m not going to do these huge side-projects — or not commit to doing them, anyway, which probably means not doing them. What actually am I going to do, though? My plan at the moment is to pause the Patreon for a month or two, flush a few ideas and half-finished pieces out, and then change over to the per-delivery payment plan. This alternative to the monthly pricing allows one to charge only as new works are completed and delivered. Thus, even if I end up never writing again, people who are subscribed won’t be paying me in perpetuity for nothing — and, at the same time, if I have a piece mostly written that I’m not really sure about, I can feel free to take whatever time is necessary to ensure it meets my standards. I’m also probably going to be shifting the focus of my writing away from criticism and analysis and towards more artistic and expressive writing, since it feels like there’s a lot more exciting work to do there right now (and such pieces usually get a better response anyway). 

Some questions emerge: What counts as a finished work, a “deliverable”? First off, monthly DevBlog posts do not and will not count. However, if I make something for the game that I feel stands very well on its own as a piece of writing or music or software, I may deliver that as Patreon content. Second, if I’m charging for individual deliverables, will I continue making these available for free shortly after pushing them to Patreon? This will probably vary to some degree on a case-by-case basis: Completely disconnected works such as critical pieces, personal essays, fiction, music, etc, will probably be made public a couple of weeks after publishing on the Patreon, while those pieces which are part of another project such as Bound City may be kept internal until the project is complete and published.

There’s two goals I’m trying to achieve with this: First, to free myself from my self-imposed bonds of feeling like I have to try to say something even if I don’t have confidence in the thing I’m trying to say; and, second, to ensure that whatever I put up from now on is something I have confidence in and passion for, and something that I’m hopefully willing to advocate for, to tell people that it’s worthwhile and they should support me so I can do this work and more work like it. Actually doing that promotional work… well, that’s still something I’ll have to figure out. For now, I can at least work to ensure that I’m making things I have confidence in, things I genuinely want to promote, and hope that the rest follows naturally from there.

Bound City DevBlog, May 2023 – Taking Shots

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.

https://imgur.com/a/zyBjdBq

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.

Uneven Balance

One of the most hazardous unquestioned assumptions of game design is that a game should be balanced. Don’t get me wrong, it certainly can be an issue if one tool is too strong, or many tools too weak, particularly in competitive settings. However, it isn’t inherently so: An option can be seemingly useless and still provide tactical value, or evidently overpowered but still have vulnerabilities — or, perhaps more interestingly, be provided to players for reasons beyond the merely tactical.

What does “balance” even mean in the context of game design? This term is far more confused and has more assumptions built into it than many seem to realize. For instance, while many would state that weapons in a competitive shooter should be balanced, that statement often quietly disincludes starter and fallback weapons like fists and knives, which everyone accepts should be relatively weak. Many fighting games specifically include taunt moves, and sometimes entire “joke” characters — no one cares if these are weak or useless, though sometimes they can be surprisingly potent. Similarly, while one might design a strategy game such that many approaches are viable, few would argue that one should balance all approaches to be viable — for instance, never inputting any commands and simply letting turns progress wouldn’t be considered a good strategy, and trying to “balance” it against other approaches would be meaningless. A truly perfectly balanced game would be one in which no action matters because each choice is equally likely to attain victory.

This all may be a bit pedantic to dwell upon — after all, no one advocates for the kind of total balance where all choices are truly equal —  but I think it’s helpful to establish that this is kind of an odd term in the first place. The real concern is that the game be living and developing, that the player stay engaged and thinking about how best to navigate each situation as it comes rather than automatically choosing a known best option. The game degrades when there is a paucity of viable choices — either because one is obviously optimal or many are virtually useless. However, what is necessary to create this healthy ecosystem of choice is not balance, but nuance; not a system where all options are equally viable, but a situation where the ability to discern an option’s viability requires careful insight into the system rather than rote memorization.

Much of the time this is effectively what people mean by saying balance, but it’s important to clarify the actual intent. If we thoughtlessly decree balance to be a desirable (or even achievable) goal, it has some odd effects on the game’s design. For instance, it means that anything we choose to include has to be useful — even if utility has nothing to do with the actual intent of its inclusion. As an example, if you’re making a historical war game and you want to accurately represent that war — or even represent war in general — there are a host of horrible things you might include, war crimes and atrocities of every flavor, particularly if you want the player to be able to recreate a given historical moment and its impact. However, if you’re particularly vulnerable to the poison of game design, you might decide that these have to be balanced — that there has to be a gameplay reason to massacre civilian populations, kill surrendered enemies, deploy chemical weapons, and so forth, on and on… it is a long list.

To balance these game design mechanics is to forward an argument on the wisdom and viability of atrocity. Sure, they might be ugly, but they get a specific kind of result which might be desirable under a specific circumstance. Certainly, there must have been commanders who believed this about the atrocities they committed, who told it feverishly to themselves, but I don’t think it’s a worthy pursuit to reify their worldview by generating a systematized representation of it.

“Okay, ” one might argue, “but we only have so many resources to put into a game, and if we add a mechanic that’s never an actual good idea to use then isn’t that just a waste of effort?” Not really! There are several ways for an included option to be interesting completely aside from whether it’s ‘good’ or not. Even if a tactic is terrible, it could still provide a unique challenge — avoiding every upgrade in an action game is a terrible idea in terms of achieving victory, but plenty of players enjoy doing it for that exact reason. Players interested in recreating historical events, in exploring thought experiments, or in role-playing can all find interest in a clearly suboptimal option. Even solely from a tactical perspective, if a move is terrible in every situation then as long as it’s meaningfully distinct from other options it will probably still find itself occasionally used — for the element of surprise if nothing else.

Thus, what is necessary to make a choice viable and interesting is not to make it balanced but to make it meaningfully distinct. I’m not a military strategy enthusiast, but to me the most interesting part of including repugnant options in a game would be to attempt to represent why these morally and logistically terrible actions might seem appealing to a commander in the moment, why these things keep on happening despite a clear trend of them making everything worse for everyone. The pursuit of balance, as an end in itself, all too often takes us away from the truly interesting possibilities — it pushes us towards a numerical game, where everything must sum up, even if the most interesting effects, and the most poignant lessons, seldom can be neatly evaluated in that way.

My argument is a little all over the place here. I’m making an argument both that it is immoral to blindly attempt to simulate atrocity as though it must be, in one light or another, justified, while at the same time arguing for a system where anything might be justified emergently due to unexpected systemic confluences. Very well then, I contradict myself — these are both excellent reasons to avoid the idolization of balance, and together form the meta argument that it simply makes things more interesting to build a system where balance is not only impossible, but unthinkable, where balance doesn’t even make sense as something to desire. Of course, at some point you’ll need to make certain options weaker and others stronger, need to ensure that some choices are less viable to make others more viable — call it balance if you must, but never forget that your goal is to make the play space open to possibility, not to make all things equal, to argue for idiocy’s practicality.

If you enjoyed this essay, please consider supporting me on Patreon.

The Great Unknown

I find randomness a fascinating topic. Core to many game designs, a hint of randomization can cause the possibility space to explode in many directions, create a sense of mystery and possibility, and convert simple puzzles with straightforward solutions into complex challenges with many varied strategies and angles of approach. The most interesting thing about randomness, though, is what a slippery idea it actually is: Living in a largely causally deterministic universe, the outcome of any die roll could be perfectly predicted, the order of any deck of cards known with absolute certainty — but, because these outcomes are generated from a sufficiently complex combination of physical factors they are effectively impossible to predict.

Regarded in this light, the truth can be seen: Random is, for almost all purposes, simply a term that means “unknown,” and a random number generator is just a tool to evenhandedly select one out of a set of unknown possibilities. We ascribe all sorts of mystical properties to randomness, we regard it as something impossible to know rather than something merely unknown — and for most purposes this is a completely valid understanding, because there is seldom any significant difference between the two. Thus, for any game design problem involving “randomness”, the question is: What does the player know and when do they know it?

One of the terms I’ve run across is that of “input” and “output” randomness. “Input” randomness is unknown information that is discovered before the player makes a decision involving it — for instance, if they’re drawing a hand of cards and then playing them, the cards they draw are input random. “Output” randomness is unknown information discovered after the player makes a decision involving it — for instance, if one of the cards does 5-9 damage, the specific outcome of doing 8 damage is output random. This is, I feel, somewhat confusing terminology: It frames every random result entirely from the perspective of decisions made around it, which is a helpful angle to understand but I think often an overly specific one to work from.

Let’s set that concept aside for a moment, and instead consider the question: What information can be concealed from the player while still allowing them to make meaningful decisions? This is an extraordinarily important question to the general pursuit of game design. Even if your game contains no “random” elements whatsoever, it likely contains a great deal of information outside of the player’s perception which may as well be random. A lighting system or fog of war that conceals areas of the map? What lurks within the dark is effectively a random encounter. Enemies that behave deterministically but in complex ways, sometimes beyond range of sight? Effectively random. An entirely scripted series of events that has yet to be observed? In terms of the player being able to accurately predict the outcome it is effectively random — assuming the player hasn’t played the game before or otherwise attained the knowledge of what lies around the next bend.

This understanding of randomness has the interesting implication that you don’t actually need to worry that much about how you approach randomness itself, but instead about communicating the possibility-space and making sure that even as things shift the player has enough information to make interesting decisions. Any element which changes per-visitation will need to be communicated to the player as if each time was the first time: If a carefully-designed situation would be unsatisfying or frustrating because the player isn’t given the information to understand why they should take a particular action, your procedural system should avoid generating that situation. What can make randomness unpleasant and frustrating is when either the generated circumstances or the information around those circumstances do not allow the player sufficient control to feel like they can act in the world.

The other interesting implication of viewing randomness as merely a kind of hidden information is that it blurs the line between that which is random and that which is not. A game like Quake has no random number generation per se, but if you’re playing against opponents the hidden information of the opposing players’ positions, equipment, and own thought processes are so concealed and dynamic as to be effectively random — even if, on occasion, we might be able to make an educated guess as to the generated state. In any competitive setting the randomness of the other player’s veiled mind, their own complex decision making process, acts as a subtle source of “randomness”, of unknown possibility, making the resulting strategy far more exciting and varied than if we were simply solving a puzzle of known factors.

With “randomness”, as with all game design, what makes it actually interesting or tedious is the process it sets the player into. When an input is randomized (like a card draw), does it make the player’s decision more interesting because the context of decision-making shifts, or less interesting because it’s impossible to come up with viable long-term plans? When an output is randomized (like a percent chance to hit), does it make the player’s decision more interesting because they have to account and control for a range of outcomes, or less interesting because they feel like they have limited control over the result? There’s no hard and fast answer to what kind of randomness can generate interesting results — even the intimate “randomness” of human opponents can provide confusion and frustration if their decision-making process is confusing or obscured. Each situation will be satisfying (or not) based on the context around it, on how well the possibility-space is conveyed and on how that interacts with the player’s ability to make reasoned and informed decisions — and receive results that, even if they don’t go quite as they had hoped, at least lie within the bounds of what they had anticipated.

If you enjoyed this essay, please consider supporting me on Patreon.

Wildfrost

After Slay the Spire released into Early Access in 2017 and was one of the best-designed games ever made, a wave of roguelike deckbuilders inevitably followed. Most of these were, I would say, pretty uninteresting — Slay the Spire excels not just due to its solid core mechanics, but the complex finely-tuned interactions of its items and cards making each run a uniquely compelling puzzle. Many of these games simply aped the basic gameplay, with the cards themselves offering rather uninteresting cost/damage/defense trade-offs. A few of the cleverer designs grounded the mechanics into a different context, such as a tactics board or longer-form adventure, which allowed them to offer something unique rather than simply being a less interesting version of Slay the Spire, but few offered much over Spire at the level of being compelling card games. 

Monster Train is one of the best of the post-Spire deckbuilders. Released in 2020, Monster Train changed the formula in two important ways: First, rather than each card being an attack or maneuver performed by the player character, many cards were instead creatures that were placed onto the field to defend against attacking units, and most other cards were spells that could be played on either these allied units or on enemies. Second, rather than card upgrades being a static element, where one could choose to either upgrade a card or not for some known effectiveness boost, upgrades were reworked into special power bonuses that could be applied to a slot in any compatible card — so, in addition to finding synergies between cards and items, you could also synergize with specific upgrades, opening up exciting avenues for player inventiveness and offering an almost exponential power development over the course of the game. 

A few weeks ago Wildfrost came out, certainly the most exciting development of the genre since Monster Train. The core design is similar to a very stripped down version of Monster Train: You have Allies and Constructs which you place on the field — a pair of three-tile long lanes, with an opposing pair of three-tile lanes for your opponent — and Items which you play from your hand to affect those units. As in Monster Train, all of these card types can be upgraded with charms to create new effects and synergies — though these effects are relatively understated. 

The truly inspired part of the design, however, is that where Slay the Spire and Monster Train both have a system where you expend energy each turn to play cards, only passing your turn once you’re satisfied, Wildfrost combines the concept of energy and turns. Each time you play a card (with a few rare exceptions), one turn passes — and, as each turn goes by, the units on the field tick down towards their next attack. Rather than dumping and redrawing your hand every turn, you instead have to either waste a turn on a redraw or play a certain number of cards to get a free redraw. Thus each battle is a race against time, trying to maximize the effectiveness of each card play and organize your battle lines to absorb or preempt each attack.

This core design is tremendously impressive, capturing much of Monster Train’s explosive possibility space while still retaining much of Slay the Spire’s elegance. When it works it feels great: Each action is of monumental importance, each position of each unit matters, an immaculate and immediate tactical puzzle. However, the perfection of the broad strokes of the design is somewhat let down by some of the specific design decisions.

Some of these might be relatively straightforward to address. A lot of runs tend to end due to oversight of or confusion about incoming damage, suddenly losing the unit at the heart of your whole strategy to an attack you didn’t see coming. I’m sure many expert players will respond “git gud” in true gamer fashion, but I don’t think it adds much to the tactical puzzle of the game to force the player to calculate incoming damage from all sources and predict which unit it will be applied to: Some sort of incoming damage preview would be very helpful, not just for preventing unpleasant and confusing surprises but also for teaching the rules of the game before attacks even happen. There are some tricky cases here, of course: What do damage previews look like for enemies with the “aimless” trait, which makes them hit a random target in the row? Perhaps a range of damage, or perhaps just appending a “?” To the display. Should a preview appear when you’re about to use a skill that would change the outcome, or would that incentivize players to just try to preview everything and brute force solutions? Similarly, when applying a charm to a card, it would be helpful to see a preview of what the finished card will look like — it’s not always obvious how charms will interact with each other or with innate card abilities. Though the specifics are tricky, it’s still the case that a few such simple UI changes could make the game significantly more straightforward to play and easier to pick up.

Some issues are a bit thornier. Broadly speaking, every time there’s a choice to be made it fails to provide enough leverage to consistently put together a solid run. For instance, at the start of a run you have a choice of three “leader” units, each from one of the different factions. If your leader dies, you lose the run, and while leader units are clearly designed to be approximately equally useful, there are definitely better and worse picks available. Sometimes you get locked into playing one faction just due to the other leaders being bad — sometimes all three leaders are bad, and you just deal with playing a bad run. Some of this can be addressed by tweaking the leader selection, but also choosing a faction separately to choosing a leader would likely improve the player’s control while still pushing them to deal with dynamic challenges.

Similar issues emerge any time the player is asked to select a card. While the pool of cards to choose from isn’t gigantic, it’s not uncommon to be offered a choice of one of three cards which are simply not useful in the current context. Skipping an item card is not allowed, so every item card encounter has a non-trivial chance of making your deck slightly but significantly worse. Card removal events can be encountered in the world, but since they can often only be visited by sacrificing the chance for a shop or item card they can really only be used to strengthen an already-powerful deck rather than strip away the worst parts of a weak one, and almost always are used to remove starter cards, leaving any duds found later on in encounters to drag you down. The net effect of all of these choices is that it’s quite common to feel trapped in a bad run, unable to strip away the cards that are bogging your deck down, slowly accumulating more of them as you’re presented with more unappealing choices with no chance to remove them.

A good way to fix a lot of these issues might be to expand the functionality of the shop. Each shop contains four cards, a seemingly infinite random supply of gradually-more-expensive charms, and a crown which can be applied to a card to make it playable for free at the start of combat. Compared to Slay the Spire there are very few cards available for purchase, just one more than in a standard treasure encounter, which makes them barely better than such an encounter for the purposes of finding a card which makes your deck better than worse. Compared to Monster Train, the charms are all randomized and unknown, so spending 50 gold can completely arbitrarily yield something that suddenly makes your deck unstoppable or something that’s a completely useless joke. Expanding the shop with a couple more cards and with a finite and visible selection of charms that can be strategically and intentionally purchased would go a long way, as well as adding some sort of purchasable card removal (perhaps just one per shop). It might, perhaps, even be worthwhile to have separate charm and card shops, adding a bit of depth to the decision of which node to visit.

These problems could also be addressed to some degree by simply increasing the number of encounters per stage of the game, but those sorts of changes can be tough to balance against the overall challenge curve. Some events might need to be reduced in effectiveness or frequency to counterbalance the additional encounters. This is a straightforward solution, but one that would require so much playtesting to ensure a good result that I can’t describe it as a quick fix.

The final major issue I have with the game is that the three current tribes — factions which determine what cards are available to you — do not seem equally well-considered. The Snowdwellers tribe, the only one initially available, centers around relatively straightforward attack/defense boosts and disabling units with slowing snow attacks. This is fine, if perhaps a bit straightforward. The Clunkmaster tribe centers around card generation and manipulation and is very interesting, resourceful, and fun to play with. However the Shademancers, centered around summoning and sacrificing units…  simply don’t seem to work very well at the moment. 

The first issue I encountered with this faction is that almost their entire starting deck is taken up with 5 Tar Blade cards, an item which does damage equal to the number of Tar Blades in-hand. This is a pretty boring card to start off with so many of, and not an especially strong one. It is, moreover, one that only gets weaker as the game progresses and your deck grows, one that doesn’t meaningfully interact with any of the tribe’s core mechanics, and one that can’t really be strategized around. These are not interesting cards — similar cards in other games can be interesting because of the tension between a short term loss (a single weak card that does nothing) and a long-term gain (a set of powerful cards), but in Wildfrost these cards are all loss and no gain. Another significant issue is that a number of cards have special triggers on “sacrifice” — that is, something special happens when they’re killed by the player instead of by an enemy. The problem is, it’s not really clear what counts as a sacrifice. Does attacking something covered in spikes and dying as a result count? (No.) Does dying due to losing HP over time count? (No.) Does being destroyed by an allied unit’s active effect count? (Yes.) At each juncture, the player can make educated guesses about what might count as a sacrifice, but there’s really no way to be sure — another place where, perhaps, some form of combat preview would be helpful.

There are other issues. The “Soulbound Skulls” card, which randomly selects one enemy and one player unit to soulbind, making one unit die if the other one dies, is effectively a 1 in 6 chance of instantly losing if it happens to target the leader. The preponderance of units which can only function alongside one another, relying on sacrifices and deaths and triggers which can only happen once you manage to get several of them, makes each individually untakeable and the beginning of the game a hellish slog where the player struggles to find a single viable unit. The flavor of the faction and the core mechanics are cool, the interplay between them can be really fun, but the whole thing doesn’t seem designed in a way that acknowledges it’s in a deck builder and that you’re not going to have all these resources available, you’re going to have a few of them if you’re lucky enough to find them.

As is frequently the case, this whole review comes off a lot harsher than I actually feel about the game. The core design is incredible, the visual and audio presentation are fantastic, I have had the soundtrack stuck in my head for weeks. I hope all the stuff mentioned here can get ironed out, because I think with a little reworking this game could be one of the all-time greats.

Bound City DevBlog, April 2023 – Versions and Diversions

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.

Juice, Crunch, and Clarity

I recently saw this video explaining easy ways to make your game feel “juicy”. I don’t know if I’d heard this specific term used before, but it meant exactly what I would have assumed it to mean: Adding a bunch of effects to maximize the impact of each interaction. This video was made a decade ago, so maybe it’s just an artifact of that time — and particularly that time in indie game development — that this quality of juiciness, of extra sensory impact, is treated as inherently desirable. To me it seems a quality entirely possible for a game to have too much of — and, indeed, much of the time now when I see a short clip of a new game, when I see the smooth tweening and screen shaking and flashing particle effects and freeze frame on every impact, I am immediately turned off. 

It’s so noisy.

This, naturally, leads me to consider when I do enjoy these techniques being used in games I play, as well as how I tend to deploy them in my own project. For the most part, partially due to personal preference and partially due to the retro style of my game, I tend to eschew this sort of juiciness, to prefer a crunchy style of gameplay and rendering with fewer moving elements. At the same time, there are several effects one might consider juicy layered on top — particle effects for damaged enemies and terrain, screen shake for impacts, controller rumble, slowdown on hit, and some animated post-processing/overlay effects. The question is, though, where did I make the choice to add these effects, and what led me to do it?

My overriding priority in game design (as in most things) is clarity, and this seemed such a self-evident value that until thinking about this I only had a vague conception that others might have different priorities. To me, all art is about communication, and game design even more so — not only are you communicating an idea to the player, you are communicating a way for them to communicate with the idea, to form some kind of interesting loop, a systemic relationship. The game succeeds or fails based on how interesting the ideas themselves are to engage with, certainly, but even before that it succeeds or fails on how well it can tell the player what the ideas even are or how to engage with them. With this priority set, “crunchy” design is the clear default state to start from — the minimum set of elements to convey the action, minimal distance between action and depiction, minimal extraneous detail to distract from these important elements. However, while this is the ideal starting point, it’s neglectful to stop here — used judiciously, “juicy” techniques can add clarity, just as using them carelessly can reduce it.

As an example, let’s take screen shake. If you add screen shake every time the player attacks, every time an enemy attacks, any time you receive damage, etc, then it is noise that screens out useful information by adding visual chaos. However, if it’s used solely in specific circumstances — such as a large opponent landing on the ground or grabbing something heavy — then it becomes a way to convey the opponent’s state and position to the player implicitly even if they’re off-screen. Similarly, controller rumble can convey health levels, post-processing can convey proximity to danger, particle effects can convey successful (vs deflected or ineffectual) attacks, and so forth. These “juicy” techniques are a channel for communication — beyond just conveying bombast and impact, they can convey whatever the designer wishes, whatever they find most relevant for the player to know, about the world of the game.

Of course, it must be said that sometimes obscuring information is desirable, is the point. Maybe you want a screen shake effect to convey the visual chaos of being under bombardment and the impossibility of doing complex maneuvers under those circumstances, or a high-intensity post-processing effect that masks fine details to create something subjectively similar to an adrenaline rush. These are valid creative decisions, but ought to be considered choices rather than merely stumbled into. There is little long-term satisfaction and enjoyment in impactful effects created for their own sake. These tools, these movers and shakers, are useful inasmuch as they allow us to create and communicate a world — and with each tool we add, with each new communication method, we must take care to control what we communicate, lest our games cry wolf too many times and be ignored.

If you enjoyed this essay, please consider supporting me on Patreon.