For this year’s second Brackey’s Game Jam, me and a bunch of other people worked on an action rogue-lite where you play as a mechanized research spider that uses it’s own clones to defend itself. I was responsible for some of the game’s not so quality code and for all sound design work. Here’s what I learned by working on it for 7 days.

The importance of communication

Being involved with others at this scale is pretty new to me. I was lucky to be in a team where everyone had equal chances to propose their own ideas or provide criticism. However, as we approached the deadline it was harder and harder to do this, due to time constraints. Still, the final concept for the game was an amalgamation of different ideas of different people smashed together into one.

We all had random ideas flowing around, but these were the ones that set the pillars of what would become Steel Silk:

• A Badland-like game where you use your clones to get to the goal.
• A recycled spider-like player controller made by one of the team members.
• A rogue-lite in the veins of The Binding of Isaac or others, that spawned from the suggestion to add some elements of procedural generation.

During the actual development we had to scrap some stuff here and there, partially because of limited time, and partially because of some misunderstandings. For instance, I made a few tracks for the game, but it was decided that it was too dark and too “horrorish”, and so we made the decision to replace them with someone else’s. In the end, this choice proved to be beneficial.

Overall, I was surprised by how similar our visions were sometimes, especially during the polishing phase. It was also easy to land on compromises when everyone had substantially different thoughts on a topic.

At some point, we had to do work on implementing graphics into the game. For this, I was even more surprised as it was close to what I have imagined it to look like, and even though it was still rough, it was close to what we had in mind.

Sound design

I won’t go deep into the details of sound design process for Steel Silk in this post, however I plan to record a dedicated video on my channel showcasing the process behind the game’s audio. What I do want to mention is how using FMOD bought us an extreme amount of time polishing audio.

Audio is notoriously annoying to implement. In my game, Jump Adventures, there’s a ton of code just for procedural soundscapes and audio variations. Instead of focusing on more important aspects of the game, I spent a lot of time doing seemingly trivial tasks (pitch shifting depending on parameters, playing random audio clips). I really wanted to include more interesting audio behavior into Steel Silk, but I was fearing it will eat up a ton of time. Not with FMOD.

If you’re a sound designer, FMOD is your friend. If you’re a programmer and want things to just work, FMOD is also your friend. For you as a programmer, if you want to play a sound variation when the character, say, gets hit, it’s a single function call and a few for optional parameters. That’s it. If you’re a sound designer, you just provide the sounds, drop them into FMOD, and randomly modulate the parameters whenever it plays, without even having a copy of programmers’ tools.

That’s a pretty trivial example, and it’s not really that bad. However, there’s the case where I absolutely lost it when working on Jump Adventures, and that’s music. I’m not a big fan of playing the same loop over and over again and switching to another whenever you move to the next level or switch back to the menu, I want the music to feel smooth and sound as it is indeed composed by someone as you play.

For Steel Silk we went with a simpler approach due to time constraints, but the idea is there.

The importance of well written code

Well that’s pretty obvious, but a lot of game jam projects miss on that in order to save time to implement features instead. I think that’s unfortunate, and thankfully, I was working with the person who would rightfully criticize my spaghetti bolognese.

It’s true that you save tremendous amounts of time thinking less about quality of your code, but you’ll be lucky if it won’t backfire on you in the last moment. It did for us, and eventually it was easy to track down and fix. I don’t want to imagine what would happen if we didn’t pay attention to that.

In conclusion

Steel Silk was a short, yet an incredible journey. I am happy with how certain aspects turned out like graphics, sound and music. I see a ton of potential and means of expanding and polishing the actual gameplay, as it is the only pain point of the entire project. I also learned some sound design tricks that I will be definitely applying in my upcoming game, Jump Adventures.

Hope that Steel Silk and this blog post will be a good way to make sure that wait for my next game will be less boring. I’m trying my best to have something out by the end of this year, but as it stands, there’s a lot of issues that I face along the way and I’m not sure if I’ll be able to keep up with my plans. I really wish I’ll have a trailer/teaser/sneak peek out within the next month or two, but no promise there.

I’d like to thank ConfiG for making sure my code is up to the standards and teaching me various aspects of Unity, Ucrash for doing a stellar job on graphics and music, and sbeve for showing interest in joining the game jam. Unfortunately, he wasn’t able to help us during the actual development but I still appreciate everyone’s involvement in the beginning and throughout the development process!