Several months ago, I had the idea that I was almost done with the initial vertical slice of the game, and wanted to push to make that happen. Now I’m a month away from the one-year anniversary of the project, and somewhere over the intervening time I lost that sense of urgency. In some ways, this lack of urgency has been beneficial: I’m not stressing out so much about the particulars, and am instead focusing more on building robust structures that I can modify as I work on them so I don’t feel too tied to any particular idea. Somewhere along the way, a shift happened in my perspective: Just as I was making a game for other people to play, the process of making the game became a game for me to play, and I started trying to shape the project into a space for me to play in.
This is, I think, probably a good idea if I’m going to be working on the game for a significant amount of time. What it is, in fact, is an extension of the realization I came to about dialogue last month: What will make this project exciting for me, and probably exciting for the players afterwards, is if I can structure it in such a way that when I have a cool idea I can usually implement it quickly and easily, ideally in an hour or two. I think that’s where the dialogue system is going to end up once I have a bit more practice with it, the world construction is effectively already there (thanks, in part, to Unity’s existing structures), and the enemy action system I added a couple of months ago is probably another step in that process. There are dangers in this idea, though: One is the classic danger of every new opportunity creating new demands to exercise it, of then feeling obligated to add new stuff just because I can – and, on the flipside, the danger of never actually exercising these creative opportunities and effectively wasting any time I spent creating a flexible solution. Time will tell whether this is, in aggregate, a better approach: It has, at any rate, created a bit of distance for me, and I’ve lost some of the urgency that had been driving me. Almost certainly too much – it becomes all too easy to bog down in the particulars of a passion project when you lose sight of the bigger picture, of a specific goal to work towards. However, as I now have a task list, I ought to be fully capable of constructing some sort of a timeline, and plan on doing so as soon as I remember to – perhaps I should add that to the task list.
Treating the development of the game as though it were developing a meta-game for my own enjoyment has some interesting ramifications. I first realized I was doing this when I was overhauling the sub-weapon system. I wanted in particular to avoid the issues I’ve seen with similar systems in the past: Either the sub-weapons quickly fall off and become weak in the later game, or they are incredibly overpowered with the expanding ammo pool allowing effectively infinite use of them to get out of any tricky situation later on. Thus, while I did want to have ammo capacity upgrades, I still felt like I had to navigate between the weapons being too weak/powerful and ammo too common/precious. To start with, I wanted to figure out a better ammo system – and this is what I mean about designing for a sort of meta-balance, because whatever ammo system I create will push me in certain design directions later on! If ammo is too plentiful I will make the sub-weapons wimpy and unsatisfying, if it’s too rare I will make them too overpowering and undermine the core gameplay.
Eventually, I settled on something a bit similar to Hollow Knight’s energy recovery system: Every hit with the player’s melee weapon fills up a meter, when the meter fills up one tick of sub-weapons ammo is recovered. Where this differs significantly from Hollow Knight’s system is that different weapons and enemies will fill the meter faster or slower. Some equipment may have special secondary effects on recovery as well, such as temporarily increasing damage or defense. That’s the ammo system, but what of the sub-weapons themselves? In the end, I figured out a system I’m really excited about: Instead of every upgrade permanently and collectively upgrading your sub-weapon, they can each be separately equipped and each have their own drawbacks, such as higher ammo cost. Thus, even as the sub-weapon gets stronger and the player gets more ammo for it, it gets hungrier and consumes more and more – or, should the player desire, it can remain weak and be used more frequently.
The big outstanding obstacle to getting this all working is really the inventory system. I keep on running into issues with this, and that’s largely because I don’t enjoy doing UI work: I have the particular combination of exacting standards and extreme apathy towards the actual work involved that make it particularly painful for me to work on. Nevertheless, big changes are going to have to be made, and I’m running out of excuses to put them off – and, frankly, the same goes for the map screen, for all of the same reasons.
After getting all this figured out I set out to get the only new mobility upgrade that was going to affect this first chunk of game working: Ledge grabbing. Now, I’ve played a few platformers with ledge grabbing, and in most of them it doesn’t feel great, so I really wanted to get this working well: First, a lot of games have issues with ledge grabbing interrupting the player when they want to fall, so I made it so the player has to explicitly choose to grab by pressing up; second, a lot of games infer that the player wants to climb up automatically even when that’s a bad idea, so I just made it a position which the player can jump from normally. Now, it remains to be seen how well this works in the sorts of high-pressure situations created by platforming and combat demands, but at least in testing it felt pretty good. Along the way I made a few other improvements to controls such as jump-buffering and responding properly to concurrent directional inputs, which could be a big improvement for keyboard players in particular.
Because I’ve been kind of all over the place, I also added a system for creating a trail behind the player similar to that seen in most of the later Castlevania games and other games inspired by them. This is kind of an interesting aesthetic challenge, since the art style in this is so stark, but I think it looks pretty good in motion now – it also gives me another channel for offering feedback on what’s going on, so I could make it flash red or white when an ability activates or when the player’s in danger or something.
Similarly, I created a system for displaying damage numbers. I don’t know if this is actually going to be necessary: Enemies don’t really have defense and weapons do static and consistent damage, so it really doesn’t provide any extra information. In the end I may end up not using this system at all. Still, I wanted to have it there – all said, I’d prefer to choose whether to have them there or not based on how well they work, rather than some vague idea of whether they might work, and they didn’t take long to implement.
Interaction icons have been improved by making them always visible instead of just contextually visible. This might create a bit of visual clutter, but without this I worry players might get stuck due to simply not seeing where a path, door, or switch is available. Right now they fade into view as the player gets closer, but I’m going to continue tweaking this as I test it.
Here at the end of February and the start of March, though, what I’m most focused on creating is another boss fight. I mentioned this in passing last month and have now started actually working on it – albeit a bit slowly. Bosses are intimidating to tackle as a developer, just as they are for the player, and I’m still figuring out how this creature is going to look and behave. I’m starting to get a feel for it though: Here’s a sneak peek.
Even before starting in on creating the boss itself, though, I decided I needed a new boss theme. Currently there’s a theme for the one existing boss, but it’s based off of her level theme and isn’t really broadly applicable (plus it’s an important fight and I don’t want to use it everywhere). Instead I wanted to create a theme that can be used for every non-plot-critical boss fight, something that could be repeated a lot of times without losing its significance. After a bunch of false starts over the course of a few days, I finally came up with this:
It’s always tricky to hew faithfully to the chiptune aesthetic while trying to achieve some nuanced compositional goals, but I’m pretty happy with this. The intro and sharp counterpoint maintain a bit of the horror vibe, but as a whole I think it maintains the momentum to drive the scene of desperate battle, and is complex enough to not feel repetitive while still feeling unified. I don’t know if the vibe will match every boss, but it should be fine for most of them.
Moving into March, I’ll be finishing this boss over the next week or two and overhauling the inventory screen to start with, then going from there to create a plan of action for tackling the rest of the project. Unsurprisingly I’ve been mighty distracted by Elden Ring over the past few days, and I’m sure that will continue – but I’ll make sure to keep my hand in and avoid losing all momentum, and keep on finding ways to feed my enthusiasm while still guiding the project towards some kind of final target.