Erebos Postmortem


I had a blast participating in PIGSquad's August Summer Slow Jam. The genre was horror and the theme was "Don't Let it Out".  When I found out about this jam at the beginning of the summer, I got really excited about working on a horror game. In anticipation I began thinking about the kind of game I wanted to make. Needless to say, what I ended up making was quite different.

Now that it's been a few days since the game was released, I want to jot down what I think went well and what didn't go so well opportunities for growth.

What went well:

Limited time

I've been trying to make a video game for longer than I can to say. Decades. My hard drives are vast graveyards full of unfinished projects. Sometimes it's because the "honeymoon" period of an idea finally ends and a new shiny idea comes around. Other times it's because I've learned so much about a tool or framework that the only thing to do is to start over with the new knowledge because it'll be so much better this time. You can only restart the same project so many times before something else comes along. Finally another culprit is loss of momentum. I could be doing well for weeks and then something happens; a new game comes out, work demands more of my time, need to spend time with friends and family, etc. It then becomes difficult to go back to the project as new ideas have now been given fertile ground to grow in my mindspace.

This is why the game jam was so great! Two weeks was well withing the honeymoon period, I knew that I couldn't just stop and come back later because the jam has a deadline. Did I get new ideas during the jam? Absolutely, but I didn't feel like I needed to pursue them because, it's only two weeks, I can get to them later if they're still interesting.

The jam supplied me with both accountability and a deadline. In my personal projects, it doesn't matter when I finish things. I can take a night (or week or month) off and nobody bats an eye. However, you don't have that luxury in a jam! That deadline creeps ever closer. And before participating, I told all my family, friends, and coworkers that I was doing this and they were all expecting to see a game in two weeks. I knew I had to deliver something, I couldn't let them all down.

Limited palette

I'm not a very good artist. Graphics and music are my weak points. However, unless I wanted this to be a text adventure, I needed to do something. I chose to go with pixel art because I figured that the lower fidelity the assets, the easier it is to hide my art crimes. Early on, I decided to limit myself to only 8 colors. I chose the nyx8 palette and I'm so glad I stuck to it even when I was dying for another color. Your mileage my very but, I feel that limiting myself to those colors made all my assets looks cohesive and improved the overall look of the game. I think I will keep myself to similar restrictions in the future. There is a definitely a difference between the assets I started making early on and the ones I was making the day before submission as I was finally getting comfortable drawing pixel art, but the fact that I used a small palette smoothed that out a bit, in my opinion.

Slashing features, cut early, cut often

As I hinted earlier, I was planning on a very different game. Unconstrained, any good idea can make it on your plate of things to add to your game. On a deadline, there is no such luxury. The game originally was going to have a stealth mechanic with sound propagation so the monster could find out if you made too much noise and you'd have to find a hiding spot or it would get you. As cool as that would have been, I needed to throw it out the window (or at least save it for a future Deluxe Director's GOTY cut of the game). My original vision had to be paired down to what I thought I could do in two weeks, and then cut down again when I realized how optimistic I was.

What is left is my original idea condensed to its essence, only the most important parts of the game made it into the game. It's hard to do, especially if you have pet features that you really want to implement (I reeeeeeally wanted to do sound propagation) but at the end of the day (or jam) I'd rather have a game without a feature than implementing my feature and not have a game.

Publishing to HTML

I think one of the most important things I did for Erebos was to make sure that there was a web build that can be played directly from game's page even though I think that the desktop is the best experience. An HTML build is extremely convenient for players. They can start playing your game with one click. It's much less effort than downloading the game, extracting it to some temporary directory, launch it, tell Windows that's you trust the game and stop blocking it.

It's all about convenience. If the analytics for Erebos are to be believed, 6x more people played the browser version than downloaded it. The most traffic to the game was from people searching for games playable in browser.

Choosing the Godot Engine

Just before the jam, I was trying to pin down the technology I'd use for the game. I had used Unity on and off for years and didn't like how much fighting I had to do in order to get a 2D game to work the way I wanted it to -- but I do like that could output the game to web and a bunch of desktop platforms. I'm also pretty proficient in C++, so I thought that maybe writing something from scratch could be the way to go. This would give me maximum flexibility to do what I want, but I'd be on my own trying to get it to run on the web, and I'd never get an OSX or Linux build. Plus I'd have to build even the most fundamental things from scratch. Two weeks is not enough time.

Ultimately, I chose to go with Godot as it was the best of both worlds. A battle-tested game engine that export to a whole bunch of platforms and it treats 2D as a first class citizen.While its built-in scripting language, GDScript is OK (not a fan of the python-esque feature that white-space indicate code blocks) it's very light-weight and easy to learn. Godot's node based approach to everything made things really easy for me.

I'll definitely be using it again of future jams.

Opportunities for Growth

Crippling bugs at the 11th hour

One of the biggest problems was finding and squashing bugs. Because this was a solo effort, I didn't have time to properly make sure that bugs I fixed didn't propagate issues in other parts of the game. I was still learning about the best ways to do things in Godot so I wasn't writing the most optimal code. Normally, this is the part where I would start over with what I'd learned, or at least go back and change everything but I didn't have that luxury during the time limitations of the jam, so I had to march onward and do better with newer code I wrote. This made it difficult and annoying to fix bugs.

Another issue is that I let some bugs linger for much longer than they should have since I was busy working on the next part of the game. This had the effect, at least once, where the fix required me to touch every interactable object in the game! If it'd tackled it earlier, I would have had fewer things to touch and be more confident in the fix -- this was 2 hours before the deadline! I was sweating bullets.

Another nasty bug was with a feature I literally cut an hour before submission. I had a dialog that would pop up and ask you a yes/no question when you're about to trigger an ending. "Do you want to engage the self-destruct? Yes/No". I felt that this was important for players as after one play-through they would understand that these choices lead to an ending. Unfortunately, if you used a controller, the yes/no button refused to listen to the key presses on the controller. This meant that you couldn't beat the game without putting the controller down and using the keyboard, so I had to rip it out. With less than an hour left, I didn't have time to be devastated by the decision.

The monster came in too late

In a horror game where you're stuck on a spaceship with a monster, the monster is arguably very important. For some reason I kept postponing working on the monster and it only made it into the game 2 days before the deadline. On the plus side, it meant that my art skills had leveled up a bit and I'm unreasonably happy with how it looks. The downside is that the monster doesn't pose nearly as much a threat to the player. It shows up during the second half and, you don't even need to encounter it to get two of the endings! I wanted to do a lot more with it, and I could have if I'd just spent more time on it earlier, although that probably would have cost another feature. If I revisit this game for the the aforementioned Deluxe Directory's Cut GOTY edition, I will want to do more with it. Maybe tentacles can menace you while you're in the mid-decks? 

Not enough time for polish and ambiance

With a monster that was described by one player as "chill" (and they're not wrong), ambiance is the only other way for me to inject horror and creepiness. I had plans on adding more ambient sounds through out the game. There are a few parts where I wanted to add a camera shake that would be very satisfying. If using the controllers, I wanted to use the rumble for various effects -- maybe once the engine is turned on you'd have a very low level rumble on the controller, just enough to let you feel that the ship's alive again.

I wanted to have the lights flicker in and out randomly to keep things tense once the engine was on, but I couldn't get it work good enough that it wasn't seizure inducing.

On the art side, I wanted to make more decals to add to the environment to break up the look of things. the bridge and engine rooms are so sparse. Can you tell that the cargo and lifeboat bays were the last parts of the game I made? To me, they're best looking because there is so much more detail there.

Choosing the Godot Engine

First I want to iterate that I like the Godot engine and I will definitely be using it again, the team of people working on it are amazing. That said, I've had to fight Godot in some unexpected ways. Sometimes, I found myself just editing Godot's scene files by hand (at the risk of introducing bugs) just because it was so much faster than going through the editor. Godot's 2D shadows are maddening as they would completely obscure the object casting the shadow. For example, if I had a crate in a hallway, you could see the shadow cast by the crate, but the crate would also be completely covered. I'm sure that there are reasons why this behavior was chosen but I can't thing of a reason I'd ever want it. Unable to find a way around this, I had to remove shadows from the game. Shadows would have been so cool and made the game feel more claustrophobic. Furthermore, though Godot has an excellent 2D engine, it baffles me that its tile map doesn't support animated tiles. You'd have to build your own hack on top of it. However, with version 4 being in active development, I'm hopeful that these will be ironed out in the future.

Final Thoughts

All in all, this was an awesome experience and helped me fulfill a long standing life goal of completing a game. The feeling of happiness and elation can't be described. I'm already looking forward to the next jam as I find myself quickly needing another fix.

Files

erebos_html.zip Play in browser
Aug 31, 2020
EREBOS v.1.0.0 - Windows (Jam Version) 22 MB
Aug 31, 2020
EREBOS v1.0.0 - OSX (Jam Version - UNTESTED) 24 MB
Aug 31, 2020
EREBOS v1.0.0 - Linux (Jam Version - UNTESTED) 24 MB
Aug 31, 2020

Get Erebos

Download NowName your own price

Leave a comment

Log in with itch.io to leave a comment.