At the end of last month’s update, I mentioned that my entire work schedule was being taken over by starting a game jam project called “Join the Madness”, and that this project’s scope threatened to balloon way out of control. Well, balloon it did, and what was once ambitiously hoped to somehow be a three-week project has become something more like a three-month project – and that’s a pretty ambitious estimate. Making a Metroidvania within the scope of a game jam is a tricky proposal, even if the game jam is relatively lenient on time (as this one was). It’s been done well before, but I have to assume that those developers had more self-restraint than I do, because no sooner did I start on the project than my mind was flooded with ideas for it and I felt compelled to realize them to the best of my ability – an urge that consistently gets me in trouble when it comes to art.
For those who are unfamiliar with the jargon, a ‘Metroidvania’ is a genre of game where the player finds additional abilities as they progress and these abilities allow them to explore progressively more of the world – so, for instance, they might find the ability to swim and be able to explore an otherwise inaccessible water section. Going into the jam, the only seed of an idea I had was that I wanted to work on some sort of fast-paced action-packed platformer, where you had to deal with complicated rooms full of enemies. There was initially no reason to make it a Metroidvania – the reason it became one, though, is because while I love having abilities like double-jump and wall-climb, I also wanted to be able to design challenges around the player not having these abilities. Making the game a Metroidvania isn’t strictly necessary even then: You can give the player abilities without making them tools for exploring a map. However, I have enough affection for the genre that once the idea emerged it was impossible for me to put it back away again – even as I knew it effectively threw any hopes I might have had of finishing the project on schedule directly out the window.
I started thinking about what Join the Madness might be: The premise emerged, that one by one people in an unnamed city keep disappearing – and gradually, so gradually that it takes a while for people to notice, a tower begins to grow from the ground with the faces of the people who disappeared embedded into the walls. It keeps growing in height and circumference, and surrounding buildings get pulled in and absorbed into its mass, and every day more people go to the tower drawn for reasons they don’t understand. The player character wakes up one day certain that they are the one chosen to bring an end to this madness, and set out to the tower to destroy it.
The concept and tone of this are definitely influenced by my recent playthroughs of Bloodborne and a couple of the Skautfold games (themselves clearly influenced by Bloodborne). I find myself strongly drawn to the ideas of surreal cosmic horror, which I have been in one way or another since playing Alone in the Dark and the Silent Hill games. I also found myself very intentionally pulling tonal and design elements from Metroid and the much-maligned second Legend of Zelda game, both game experiences I find very mysterious, abstract, and compelling. Since coming up with the concept I’ve also come up with some more ideas I’d like to tie into that, some characters I’m excited about writing, and some narrative themes that seem to clearly be emerging – but I’ll wait to talk about those until I have more to show.
I don’t remember quite how I ended up with the art style I settled on – I think I was originally just planning on keeping a small color palette, influenced by other pixel art games, most notably Loop Hero – but once I started building a mockup in black-and-white I loved the feel of that so much it became the game’s aesthetic. Currently, everything in-game is one of four colors: Pure white, pure black, pure red, or dark gray. Each of these serves a specific role: White is interactible sections like terrain and enemies, black is background, gray is detail to convey the space, and red is blood – which is thematically tied to healing effects and successful attacks. I initially had a script to dynamically change these colors based on a palette, but a collaborator on the project pointed out that it would make more sense to create a post-processing effect that just swaps the colors out after rendering. Thus, each room in the game can have its own unique palette, and this can even be animated over time. I don’t know what all I’ll end up doing with this, but the possibilities are fascinating. A variant on this idea I’m tossing around in the back of my head is to replace each color with textured pixels, so I could render a background image through them or something, but this is an idle thought for the time being.
One of the most gratifying aspects of the first couple of weeks of development was having an opportunity to really make use of my sprite shaders, which I’d spent the last few months on, in an immediate and practical application. The ability to quickly and easily experiment with different modes of color and lighting was exactly as useful as I’d hoped it would be, and I quickly got some ideas for additional fixes and features – such as the dithered lighting mode, necessary for maintaining the stark art style while having lighting effects. I also found out that I’d overlooked major issues when I started trying to create the first project build, and found out that it had so many shader variants that it would have taken literally days to compile them all – a helpful object lesson in the difference between the shader_feature and multi_compile key-words! I would have been incredibly embarrassed to have released them with that mistake, so in the end I’m glad that I wasn’t able to get around to it.
Speaking of which – I need to figure out when I am going to get around to it. I’m still frantically working on this project as much as I can, and having a very hard time fitting anything else into the schedule, as evidenced by how far behind I was on last week’s essay and this DevBlog. To finish the sprite shaders up I’ll need to review my changes and make them a little bit more robust as well as complete the documentation, which is now out of date in addition to the other edits it required. This is also going to be a rather busy month in other ways as well, since my vaccination is finally completing soon and I’m going to be immediately leaving on a trip to visit friends and family. Most likely I will only get a chance to publish to the asset store around the start of next month, unfortunately.
The biggest obstacle I’ve encountered on this project so far was the map editor I mentioned in passing last month. What seemed like a straightforward problem became a tricky problem – what seemed like a tricky problem became a tangled nightmare. A day’s work became a week’s work, and when the entire project is intended to take less than a month (as it once did, though that seems so long ago now) these kinds of setbacks become incredibly stressful. The reasons it got out of control were, in order: The difficulty of working with Unity’s Tilemap system, the challenges of representing a coordinate grid where y is up with a list of objects where y is down, the additional difficulties of figuring out Unity’s custom EditorTool sytem, and finally eventually just a bunch of normal bugs which I was largely able to solve in a few hours.
It works now, mostly – though when I tried to get screenshots, it kept getting errors, so apparently it still needs some time. Let’s not speak of it again.
Rather, let’s talk about the project’s audio. Since I chose this very restrained pseudo-retro visual style, I looked into how I would approach emulating NES-style chiptunes and, to a lesser degree, sound effects. I ended up gravitating towards a similar set of solutions as the Shovel Knight team described: Approximately emulating the NES’s number and variety of sound channels (four channels, one noise channel, one triangle wave channel, and two square wave channels), but occasionally allowing myself to use a channel beyond the original set of four. I was not scrupulous enough to look up what waveform the expanded chipset NES carts actually had access to – I just wrote a piece that needed an extra square wave, and decided not to worry about it. Similarly, I found a somewhat expanded port of the old sound effects creation program SFXR to Unity, which I implemented into the project early on – however, much of the code ended up being unsuitable, so I ended up stripping out pretty much everything except for the core synthesizer logic and replacing it with my own. I may end up stripping that out as well and making my own sound effect synthesizer asset later, but this is a diversion that will surely have to wait until after this project is complete.
Since this was a game jam, I made an open invitation to anyone who was interested in working on the project, and someone took me up on it, offering to do any extra programming work that I could use on the game. I’m not very experienced at working with other team members, particularly from a leadership position, so I definitely feel like I could have done a better job coordinating our efforts: I offered him the UI programming, since it had to be done, was relatively separable from the rest of the game so our efforts wouldn’t interfere with each other’s, and it wasn’t something I had a strong sense of needing to be done a specific way I’d have to communicate to someone else – or so I thought, anyway. I sent a mockup of what the inventory screen might look like, and he ended up implementing that directly as the inventory screen – which unfortunately meant that when I created the final inventory screen art, he ended up having to redo some work. Each asset created, I’d end up needing to rewrite pieces of – not through any fault of his as a developer, but just because the game it needed to interact with was so rapidly in flux that I was the only one who was really in a position to know how it would fit together. It worked out okay, and I’m grateful for his help, but it certainly gives me pause when considering how to work with teams of potentially several people in the future! It is, perhaps, a discrete skill-set I will have to learn.
There’s a lot more to talk about on this project, but I’ll leave it at that for now since most of the rest of it regards design work which is still largely in flux and untested. I’ll probably be talking about it more for next month’s DevBlog! In the meanwhile, I’m hard at work getting everything put together for a viable vertical slice, a full-featured subsection of game, for later this month.