In the initial planning phase we knew we wanted to create something simple that we could pull off. The aim wasn't really to make a good game. It was to make something that tested the limits of our tools and current skill set.

Play here: https://ldjam.com/events/ludum-dare/45/slave-unchained

The Beginning:

Slave: Unchained is written entirely in a custom engine. As you can imagine that makes everything a pain in the butt. At the start of the 48 hours I had a barebones, skeleton of a tool. There was no infrastructure to save or load scenes. There was very limited support for sprites and sprite animations, and tilemap functionality was... limited.

This all had to be written on top of the development of the game.

A lot of these problems were sleeper problems. I.e. they don't rear their head until later on in development. For example, how do you know what features you need until you need them?

Luckily, I knew this was going to happen, so from the outset I knew compromises had to be made in order to account for the extended time required to implement features.

The theme was the first to go. The theme made the scope too big and the scope needed to be very very small. I've been burned by scope creep too many times. Establish your scope and then half it. You'll get half of that done in double the time. You will crash and burn if you dream too big.

Another compromise was sound. I am not a sound designer, and as much I know the importance of good sound design and good music it was something I knew I could not learn, implement and then polish in time before the deadline.

The Target:

There were a few things I definitely wanted to do. The major one was tight movement. Collision response is difficult to get right. I think we did a good job here. You know when collision is an issue when the players start to notice it. If you never notice it, it means it's behaving like you expect and the suspension of disbelief is maintained. We did well in this regard.

Another goal was to implement something visceral and impactful. The gameplay had to be punchy and weighty and there had to be some consequence to your actions (not moral consequences). The permanent blood had been something I'd been thinking about for awhile. It adds an extra dimension that sells the illusion that you exist in a world. It's also astonishingly violent which actually wasn't my intention. But it felt good to play, so I made it more bombastic and extreme.

The Gripes:

OpenGL sucks. What works on some cards will not work on others. Sometimes it's your own fault. You didn't read the specification. Sometimes it's entirely openGL's fault. What is a fatal crash on one system is not on another. This will often be accompanied without a warning or error code. What is expected behaviour on one card will not be expected on others. This was a headache and soaked up the majority of the post-development and update stages.

Conclusion:

A custom engine grants you one thing and one thing only. Adaptability. The only problem is that it comes with a substantial cost. Time. What will take you N days in one engine will take you exponentially longer in your own. But in another engine you are always constrained by someone elses implementation. Rolling your own means the constraint is only yourself. Sometimes you don't want that. But for a small scope project, without real world demands it can be a rewarding experience.