One Torch

This years Ludum Dare game jam topic was “You Only Get One” and our team (Clifford Bohm, Thomas Leonard, David Phillips, Jorden Schossau, and me) decided to join. The game jam was 72 hours.

I have to admit, when we read the topic, we were quite puzzled. I think we discussed about 2 hours before we converged on the actual game. But we first had to come to the following conclusion: using “you only get one” as the game mechanic will not allow for a nice game, so we decided to make it the theme rather than the mechanic.

In the end we decided that the player has to lead a group of cave men (or other ancient humans) through a cave into safety, but the problem is that this group has only one torch to illuminate the otherwise pitch black cave. And of cause the cave is full of dangers and some puzzles. The tool to make this game was easily found: Unity3D, using C#, Maya models, Photoshop, and Reaper audio sequencer for the sound and music.

We didn’t want to user to micromanage, so everyone simply follows the leader – the one with the torch, however you can make the followers stand and wait, something we called “freeze”. A frozen follower will remain anywhere, also in the dark if necessary. But followers can not stay forever in the dark, at some point we wanted the ones waiting to get so scared from the darkness around them that they wander off and maybe fall into a pit, get lost, or get killed by some yet undefined horror in the dark. In the end we gave that up, and just kill followers who wait longer than 2 minutes in the dark. When the Leader comes back close enough and they see the light again, their counter resets to zero. But why should players wait in the dark at all? We came up with three basic reasons we could use to setup puzzles:

1) pressure plates will open gates, as long as someone stands on the plate the gate is open. After the gate, there is another plate that can hold the gate open, and one can go back to retrieve the one left behind.

2) fragile bridges break when too many people stand on them. This way the player had to either go back an forth and use the leader to shuttle folks back and forth, or stand in such a way, that the player can steer one follower after the other over the bridge

3) a spider who attacks always the closest. This monster can either block the way or make a certain terrain impassable. One can use a follower to lure the player somewhere and use this distraction to get around the spider. This allows for quite a variety of possible puzzles

screenshot3

Cliff worked out a couple of puzzles, and I added a few very basic tutorial kind of levels that introduces the concept of spider, gate, and bridge without being overly complicated. In the meantime Thomas started to get these levels into 3D models. The problem was, that at first we thought we could use Unity Terrain, but it turned out that the look wasn’t right, and also bridges were impossible. So after 24h of work, levels needed to be implemented in Maya – so be it. David made all the other models, and everything like gates, prison bars, arches, bridges that didn’t requite animation, which went very fast. The problem were the animated characters like the leader, the follower, and the spider. I have to say I love mechanim! It is incredibly easy to control programmatically, it blends nicely, and once the animations are there, it is implemented very fast … once the animation are there. David and I already use mechanim for other games, but we somehow forgot the peculiarities and quirks. At first the spider was in the wrong orientation, and together with the NavMesh which does the pathfinding in the level, the spider was animated to walk forward but the NavMeshAgent moved it backward … David needed to redo the spider. We ran into similar problems with the animations for the humans. When you have a model from Maya you can make one large stretch of animation and cut that into the different movements within Unity quite easily, it just sucks to animate that. If you use the same model multiple times and export different FBX files with associated animations, you can put them together in Unity but only if the all have identical avatars. Saving different animations doesn’t guarantee that. If we would be able to ensure that always the same avatar is used, everything would be peachy. We need to revisit this issue. Also, one animation was off, and we needed to change that last minute, however we were lucky, and the same avatar was used, so I could pull the new animation on the old GameObject.

Jory took care of the sound manager in the meantime. I haven’t studied it properly yet, but it worked very well. If we would have more time, I would probably opt for a different system, but this one worked out flawlessly. Besides that the sounds are helping enormously with the mood and feel of the game. Also the winning and intro music is super great, and nails the theme and feel of the game. I have to point out that dedicating someone to this is a great help, and this part is not only super time intense, but also requires talent.

Talking about the feeling of the game. Cliff and I spent about 2 hours to optimize the light of the torch, and I learned a ton about lighting which I never ever did before. Did you know that a flame is emitting mostly the same color of light, but the intensity and location is what changes? Initially I played around with noise on the Red, Green, and Blue values of the emitted color. It turns out that moving the source around using a particular noise function combined with other probabilities (trade secret of us now, sorry) gives the super cool torch light effect you see in the game. We didn’t make a flame, or actual torch for the game, the light sort of comes from above the Leader, but that didn’t bother anyone so far.

For me the most annoying part as usual were the last 5% of the game… Cliff prepared the 2D art, but I needed to throw everything together, making the intro, the level select menu, the outro, the game over screen, and connect the levels in the right way. Next time, I might want someone who exclusively works on that to make the whole game experience more rounded, and take away that workload, or I am going to write my own class in advance…

All in all, we were all very happy with the result, and if this game gets nice reviews, we probably try to make it into a bigger more complex game.

screenshot2

If I would redo the whole project with the knowledge I have now, I would insist in making the animations and 3D models first and then make the user controls. Doing one, changing the other, and redoing the first, just to redo the other again sucks. However, now we know how, I would wish for more elaborate models and animations, which will result in an even better visual experience. Also, I would have loved to spent more time on the levels, with everyone involved. We more or less drew a sketch, implemented it in 3D, incorporated the game elements, and test played it. In order to improve the whole thing, we should now redraw the levels, make better models, and optimize the game elements better – when turning this into a full scale game I would even try to make levels more modular, which would allow to optimize the different components individually and stitch together larger levels, and reuse already established components.

When brainstorming about the future, we also thought about other puzzle concepts, and different mechanisms. Also, the followers are just four more humans hanging out, we should individualize them, and let each one have exactly one special ability like: immunity to spiders, extra strength to operate a pulley, special weight to operate special pressure plates, less cowardice to be able to remain longer in the dark, super fast to outrun spiders or traps … also the characters should get individual voices and maybe also should be able to run and not just walk. In addition the player needs to get a better overview about the state each character is in, and I already have a hunch how to do that.

In terms of extra puzzles I am thinking about a raft that can be pulled over water, bridges that crash after a certain number of usages, an elevator that requires the pulley to be used, traps that are only triggered by some characters, … more ideas are very welcome.

Another thought that bugged me a lot is the gender question. While I am not saying male of female, the characters look like men, but there is no reason to only have men. Using women however easily creates stereotypes: Should we make the women the strongest, or fastest, or the one immune to spiders, or the one carrying the torch, or the fastest … some are biased, some aren’t. Maybe we make all of them female in the full version of the game.

 

Anyways, play the game here

Cheers Arend

Leave a Reply