codebite _


Hibernaculum is a video game me and my friend Quaternius made for Ludum Dare game jam #38.

It's a simple game where to progress to next level you need to collect all the puzzle pieces and solve a riddle. The player can move only left or right, and is stuck in a snow globe. Thankfully the player also controls the rotation of the world, so one can position the world as best suited for the player character.

Now if you don't know what Ludum Dare is, in short it's a game development competition where you have to create a game, based on theme announced at the very beginning, in 48 or 72 hours (depending on rule set). More at:

But, how did the development go? Well, today I am going to answer that question from my perspective.

The bad stuff


As always, nothing can go 100% smoothly. Some bad stuff happened, and we should learn from it.

Character controller

I rewrote the character controller 3 times during the the whole jam. The last one I didn't even use and reverted back to 2nd version. So why?

The 1st version's problem was ground detection. It was physically-based, used Rigidbody and a trigger under the player model to check if it's grounded. It worked great on flat ground, but on the hills/angled terrain the jumps were multiplied. The problem was of course that the trigger was still detecting ground on the angled terrain even when the player was visibly in air. Adding OnCollisionStay() event listener to calculate the terrain's angle helped a bit, but in the end it transformed into a hack and still didn't work properly. I think that the problem was in the accuracy of the single collider. Maybe if I'd use a raycasting technique and cast few rays in different directions from the feet of the player it would work better.

But instead of doing that, I remembered that Unity provides a CharacterController class and so I decided to rewrite and use it. After few failed attempts to simply reuse 3rd person controller from Unity's Standard Assets, I wrote it from scratch. Now CharacterController is not physically-based, but in the end it didn't matter. I faked the smooth jump with a timer and tweaked all the values till it felt nice. It worked.

So why did I rewrote it, and went back to it again? Well I thought Unity is broken or something, the CharacterController controller (that redundancy) could slide on top of colliders. Wait what? Yeah. After wasting hours trying to tweak the controller and messing with colliders I decided to rewrite it again. Thankfully in the middle of a rewrite I had an epiphany. It wasn't the controller problem. It was because my world was constrained Rigidbody. After changing the world to simply be a bunch of colliders everything worked!

So what's the lesson here?

  1. Know your tools. If I knew better how CharacterController and Rigidbody interact with each other, I wouldn't have this problem;
  2. Don't reinvent the wheel. Especially for game jams and alike;
  3. The problem in complex systems may not always be in the last thing you changed. If that piece interacts with other pieces, maybe those other pieces can't handle the new thing.


Puzzle design

So even though we designed our game pretty good and considered many things, we didn't think enough about puzzles. Even though they were like the next main mechanic after the world rotation. We decided on few possible puzzle ideas, and that player needs to collect pieces in the world and that's that. No actual puzzle design. We just sort of went with "we'll figure it out as we'll go". Now, sometimes that works, but I think if we'd settle on few puzzle ideas before hand we'd need not to rush in the end with riddle idea because implementing puzzles just wasn't happening with that little time left and no clear idea.

So the lesson here is: PLAN, PLAN and one more time PLAN ahead.

Unity + Linux = 💔

At least on Arch Linux.

1st of all, I really appreciate that Unity does the Linux version of the Editor at all. But it's not yet fully ready to be used in production. I won't go too deep into this coz it's not that exciting anyways. Here some examples of what happened to me while I was developing Hibernaculum:

  • Freezes;
  • Crashes;
  • OnGUI redraw errors inside the editor;
  • Placing objects in the scene instead moved the previously selected object to that place.

Lesson here: test your development environment before actually using it to develop stuff.

Unity + git = 😕

Missing materials, empty models, scene merging... Sounds annoying yet? I did everything internet said to set up Unity for git, except the "don't use git and Unity" part. I guess they were right. I don't know why, and how those things happened, and frankly I don't want know. But it was very annoying. I think it was .meta files, and git incorrectly merging them? I'll need to test this more if I want to use Unity and git. But maybe, just maybe, I should learn another version control software. Broaden my horizon so to speak.

Lesson: Know your tools. (x2) and Test your development environment before actually using it. (x2)

The good stuff


The idea

This is pretty awesome, I am usually either simply okay with my idea, or don't like it in the end. This time the core idea was simple and unique enough. Even though it provided some difficulties in regards to level design (the whole "things should only be placed where player could reach them aka tangent of the circle"), I think it's pretty unique and cool one.

Teamwork 🤝

So this was the first time I worked in a team for Ludum Dare, and my first time Jamming not doing Compo. This means I could ignore all areas I am not good at, since I had the amazing talent of Quaternius for Art and Music, and focus on coding. The Jam also offers more time which is always nice.

Working in a team is also why we picked a nice idea in the end. We brainstormed together and threw tons of ideas into the mix. Then we talked about our ideas in more detail to each other, and then rated them. In the end we had 2 ideas to choose from and we rated them again more in depth. That was the best brainstorming session I ever had.


I know I said that we didn't have clear and defined goals for puzzles, but everything else was there from the beginning. It's very refreshing to have a plan for Ludum Dare and simply stick to it. Even though we cut a lot of content in the end, and of course the whole puzzle fiasco, we had a clear idea of what the game is from the get go.

Asset Store

Unity's Asset Store is amazing. I was trying to code the shaders for the game, but we didn't like them and it was getting too complicated (I am not that good with shaders, let alone whole Unity's shader model), so getting onto Asset Store and finding what we liked for free was very liberating. Now, we could only do it because it was Jam, not Compo, but still it was nice.



In the end, it all was very nice experience. Especially considering I didn't want to participate at all and was demotivated at the time. But Quaternius did the right call, and made me do it, and for that I am grateful.

If you want to play the game you can do so right here on my website, just click HERE. Now the WebGL version is a bit laggy and you can download all the builds from my Google Drive folder HERE.

If you took part in the Ludum Dare you can rate our game at website.

Back | Top