This has been a productive month, though much of that productivity has been invested into small tweaks and improvements that it’s hard to say much about. As I continue work on this project, I’ve been trying to develop better and more stable work habits, trying to avoid the cycles of rapid progress followed by bouts of burnout in the hopes of building a more consistent approach. Now, rather than trying to do “as much as I can” 5 days a week, I’m trying to get in 3-5 hours 4 days a week – and, while 3-5 hours is logically less than “as much as I can,” in practice it tends to be a lot more since it keeps me more focused to a limited period of time and able to stick to discrete tasks. At the same time, I’ve made improvements to keeping track of ideas and tasks, noting blocks of tasks on wet-erase cards and keeping a legal pad handy to note down bugs and small tasks so that I don’t have to remember them while working on other things (and also get the satisfaction of crossing them out afterward).
As I inch closer to the pseudo-finished version that is the vertical slice/demo that I’ve been working on, I notice more little bugs that need fixing and bits of polish and presentation that need to get added in. I spent some time on aesthetic improvements, which can be nice low-impact tasks when I’m overwhelmed with other work. Among these were numerous small improvements to the bleeding effects and creating small dust effects for footsteps and other player terrain interactions: While this may seem a solely aesthetic improvement, changes like this can also add clarity by showing clearly where jumps start and where the player touches the ground. I’ll probably try to apply this technique to other entities as well eventually, so enemies will also emit puffs of dust on footsteps and impact – there’s probably a point where this will be ‘too much’, but since most of the effect just sinks into the background that may be a high threshold to cross. There are likely to be more effects I’ll want later on similar to these – sparks, fragments, maybe splashes of water – so I may later try to generalize the system currently used for blood effects to be a more generalized shared particle system.
Another effect which could very easily become too much is that of animated palette changes. This was something I fiddled with briefly early on but created a much more robust version of recently. First, a bit on the lighting logic for the game: While one can clearly see that darkness obscures much of the world, in fact only the foremost layer, used for entities and terrain, is lit. All of the background tiles, near and far, have no lighting logic whatsoever and use default sprite rendering. This has some interesting properties: For instance, I can use the always-visible background tiles to guide the player towards where the foreground tiles are likely to be in poorly lit areas – that is, if you see supports for a bridge aligned linearly, you can safely surmise that there will be a bridge above them. However, what this means is that even if the foreground is very strongly lit by a given color from a given point, none of that will be reflected in the background – which may or may not be good, depending on the tone of the scene.
Animated palette effects are my solution to this issue. While the background’s properties of being unaffected by lighting and always the same color remain unchanged, the background can now shift color based on circumstances! So, for instance, if I want the player to slowly delve into a darker and scarier area, I can gradually fade the background character as they move, or if I want to have a flickering light source add tone to an area I can also make the background flicker as they approach it. Of course, any palette color can be shifted the same way – though in practice I will probably mostly reserve this effect for the background detail color.
Now, finally, after months of talking about how I really needed to build this boss fight, I started really building this boss fight. Perhaps because it had been gestating for so long, this actually went quite smoothly once it got started – but was, nevertheless, a lot of work! I’m coming to realize that boss battles are simply always a tremendous amount of work, each one probably equivalent to making 5-10 standard enemy types – at least the way I’ve been making them, which is closer to the Dark Souls style of having a malicious entity choosing specific moves to make against the player rather than the old school approach of a boss being a sprite that’s twice as big that maybe shoots out some projectiles. Each separate attack I create for a boss feels effectively like making an enemy type and then grafting them all together to make a singular meta-enemy. None of this is necessarily a problem: Some tasks are going to be harder than others, and if one of them is going to be particularly difficult I don’t mind that it’s in service of making cool detailed boss fights. I note all of this to, essentially, reassure my future self that the worry and discomfort I have around boss battles is fine and reasonable and makes sense considering these challenges! At the same time, realizing all of this, it seems like a good argument for making a few more basic enemies, since they’re such a smaller time investment and they can add a lot of fun interactions to the world if well placed and thought-out. Basic enemies can even, in some instances, be integrated into boss fights – as happens in this one, where the wolf boss can howl to summon additional dogs to attack.
Over the course of developing this boss, I also expanded the enemy action system I developed when I was building [what I previously believed to be the first boss]. What I realized is that the majority of actions fell into one of a few categories: One, the most common, is simply “wait for x seconds while doing animation”. Many others are some version of the same thing but with an initial burst of directional movement (as with leaping attacks), or some kind of movement over time. Along with these, an action that creates an attack or projectile covers almost every remaining situation reasonably well. The main thing that wasn’t covered by these was simply that many states had special logic for ending because the player got close or the creature was facing the wrong way or hit a wall – so I also added a set of “interrupt” parameters which, if they test true, cause the action to end and change over to another action. If all goes well, these more flexible and robust actions should make implementing the basic logic of future enemies and bosses go much faster.
The close the game gets to the discrete playable chunk I’m trying to complete, the more playtesting and polishing becomes possible. Indeed, I suspect that much of my development time over the next while is going to be taken up by playing through what I have so far over and over and making sure everything fits together, that I haven’t left holes in the terrain or unrecoverable dead ends, that everything works the way it’s supposed to and feels satisfying to play, and probably making a ton of notes and little fixes as I go. Meanwhile, much of the dialogue is still unimplemented and unwritten, the title screen and intro still need to be done, the intro and conclusion of the second boss still need to be scripted, and some extra music and special encounters need to be added. It’s all starting to seem like an eminently reasonable amount of work – though, perhaps, a tall order to complete across one month.
Of course, once that’s done I’ll have to figure out how to make the rest of the game. It seems much less intimidating now, though.
If you’d like to help support this project or my writing, please consider supporting me on Patreon.