LONG overdue. Second game jam, first one as a team. The experience was even better the second time around, but that’s probably due to the multiplayer aspect.
Ai’n Av Diortem is a Run-and-Gun platformer. The idea was a combination of two of our other Minimalism ideas: One was a game where you “level backwards”, ie you lose your equipment/abilities as you progress. Think Super Metroid, but in reverse. The other was a straight-up Super Mario Bros. style platformer without any background textures: you use light sources (initially: the sun) to cast shadows, and those shadows tell you where physical objects are (since you wouldn’t be able to see them). We ended up reversing the latter, so light was cast on a black background rather than shadows being cast on a white background. By combining the two ideas (a SMB platformer with weapons) we were also able to integrate things like gib physics and blood streaks/splatters to the visual aid mechanic, so that you weren’t just relying on casting sources of light.
We were thrilled with the idea and excited to execute on it…
…but we ran out of time.
What went right?
Theme: Speaking over dinner on the eve of the jam’s start, we were talking about what themes we’d like to play with. Minimalism was on the bottom of that list. As you might have guessed, we were somewhat crestfallen when the theme was announced. But we were here and we were ready to go, so after a minute of sighs, we headed to the whiteboard to drum up some ideas.
It went very well. We had a few ideas relatively quickly. We scrapped some, combined others, and made compromises as necessary. Within 15-30 minutes we were set on not just a game, but the title of it, as well.
Team: Our setup was good and we worked well together. I’m not a particularly skilled pixel artist and spent a significant chunk of my time last LD getting the graphics to look presentable (it ended up paying off; I nearly made it into the top 100 for Graphics last time). In addition to lacking the skill, I easily get frustrated by it and burn out very quickly. Having a dedicated graphic artist offloaded not just the artwork, but a lot of the character and environmental design from me, allowing me to focus almost exclusively on coding/gameplay design. And that, I can do for hours on end without budging an inch (except to go to the whiteboard). Partway through the second day, we also recruited an audio guy to handle sound and music, so now we had all of our bases covered. A trinity of game jamming.
Workflow: Since we were all working in the same physical location, we were able to add assets into the game with almost no process cost. Assets were just dropped into the network folder that the compiler pulled from, so once something was done it was dropped in the right location and automatically included. Nobody was waiting on anyone else, and the “process”, as it were, didn’t eat up time.
Scope: We had an initial scope that sounded achievable – it wasn’t – but as time went on we were able to easily identify what was core to the experience and what we could cut for time, developing a bucket list of features and things to add into the game post-jam.
Fun: If there was a limit to how much fun we could have, then it would have been a problem. But there wasn’t, so we had an awesome time.
What went wrong?
Scope/Ambition: Even cutting back a lot of the features and levels we wanted to include but couldn’t, we weren’t able to deliver on a lot of the core concepts. We scratched the surface of what we were aiming for in the last room, but took shortcuts to get there and it inevitably felt like an elaborate tease.
Polish, Lighting: The lighting seen in the game was a compromise. It was implemented initially as a quick trial-run to see how it felt in game and once it was in, I tried doing a pseudo-raycasting lighting engine where light would bend around corners, not pass through walls etc. I think some of the code is still in the LD26 source, but suffice to say it A – did not work quite as well as I wanted it to, and B – actually looked worse than the blocky lighting we ended up reverting to.
Polish, Physics: Another thing that received too much attention was the physics engine. It’s still not “correct” in that it doesn’t follow proper laws of physics, but we had something simple and fun earlier, but I kept tweaking it, rather than spending more time on the enemy programming and level development. It wasn’t a huge waste, but the additional hour or two spent on it could have been better used elsewhere.
Polish, Decals: “Decals” refers to the burn marks and blood stains that appear on the environment. As necessary as it will be in the grand scheme of things, it wasn’t entirely necessary to code for the jam. That is to say, it wasn’t prioritized correctly. We needed it, but we didn’t need it yet.
Controls: Bugs aside, the control/character physics were initially tested in a few debug rooms, but we didn’t have enough time to playtest it in the actual game, and it didn’t work well with the level designs we ended up going with.
tl;dr: Time Management. All of the things that went wrong with our LD26 experience can be boiled down to poor time management. We dreamed big, we thought big, and we attempted to deliver big – far bigger than we were capable of in 72 hours. I’m still quite proud of the end result, which still resulted in something very playable, but we got so caught up in our ambition that we ultimately failed to deliver on the theme, reducing it to a little room at the end that screams, “Hey, look at what we were going for! Neat, huh? Bet you wish we finished it!”
Not to be discouraged – we’re actually doing another game jam this weekend, to finish what we started. Or at the least, get much farther along with what we started. There are a lot of ideas we want to explore with the game engine and design philosophy our LD26 jam has left us with, and we’re going to cover as many of those ideas as we can. Look forward to it!
