Ludum Dare, a tri-annual game jam where you are tasked to create a game from scratch that fits a certain theme in 72 hours, took place last weekend. I had decided a couple of months ago to participate along with one of my friends. At that point, I had probably been
playing working with Unity for a month, and been coding for 4 months. Basically, I was pretty green. Possibly the greenest. But what better way to learn than to just throw yourself into it? Worst case scenario is that it simply doesn’t work, and we had said early that not finishing on time was okay. We’d do a sprint over the 72 allotted hours, and see how far that takes us.
We decided quite early to work in 3-D, as he wanted to give speed modeling a shot. This meant we had to work in Unity, which he had no experience with. Thus, it was decided that I would do the coding, and he would do the art. Nice, clean split.
So I had about two months to figure out...essentially everything about game programming in Unity.
So I figured I’d start with the basics: programming a modular movement rig where I could encapsulate a characters behavior and switch it around based on context and environment.
This turned out to be a bit more complex than expected. It was fairly easy to achieve “okay” movement, but making it feel nice, smooth and reactive turned out to be really hard, as there are lots of ways to move an object through scripts, but I couldn’t find a straight answer as to what was the best practice.
Eventually I managed to hack together a nice character controller that I felt pleased with, and that was easy to maintain. This allowed me to then apply the same theory to the camera controller, so that I could change perspectives and behaviors on command. Movement will ALWAYS be a critical aspect of any game, so I knew I had to really understand this properly, because otherwise it WILL come back to haunt me.
Once the time for the jam came around, it was revealed that the theme would be “Sacrifices have to be made”. So once we’d woken up, we got on Discord and started brainstorming. We soon came up with the concept of a sheepdog that has to sacrifice parts of his flock in order to reach a certain goal, like a bone. You could, per example, fill up a pit with sheep in order to pass over it, or force sheep into electric fences to shut them down, things like that. It was decided that the sheepdog would move the sheep by barking, at which point any nearby sheep would scatter by running in the opposite direction of the sheepdog for a short while. When not running, the sheep would attempt to congregate into a flock.
For that to work well, the game would have to be two things: Cute and funny.
So I got to work on the mechanics. First up was making interactions. The sheepdog had to be able to bark, and that had to somehow signal any sheep within a predefined radius to run. I opted to implement this by spawning an expanding sphere collider on the sheepdog when it barked, which detected collisions with sheep. Once a collision was detected, the sheep fetched the vector to the sheepdog, and moved in the opposite direction.
Then I took to implementing the passive behavior of the sheep. I figured out that if I simply fetched the average position of all the sheep, I could have the sheep constantly attempt to slowly rotate towards this point while constantly moving forward, which would in turn move the average position of the sheep. This resulted in a surprisingly organic imitation of the way schools of fish behave, which I decided was good enough.
At this point, I essentially had all the mechanics complete. I implemented a simple spawner that created a sheep every X seconds until Y active sheep were on the map, and a trigger to deactive a sheep, confirmed that everything worked as intended in the editor, and built the game so my friend could see the progress.
This is where I hit a wall.
When I fired up the build, the spawner didn’t work. Which was really strange, as it worked perfectly fine in the editor. I started hunting for bugs, but couldn’t for the life of me figure out why the behavior worked in the editor, but not the build. I took me nearly six hours to finally identify the issue, which turned out to be a bug in Unity related to the tag system. At this point, I was exhausted. Most of the art was done, and all the mechanics were implemented. All that was left was some simple scripting for the traps and the level design, so I got to work on the environments and sculpting out levels. Problem was, as I previously mentioned: the debugging had left me exhausted. I had no creativity left in me, and it turns out that level design is really hard and time-consuming work. It certainly didn’t help that Unity in it’s base form isn’t particularly well-suited for level-design. It has some okay tools, but if you want to make sharp edges, you’re shit out of luck, unless you’re exceptionally good with heightmaps, of which I am not.
So in the end, as it was now sunday evening and I was out of time, I decided to do some graphics editing and establish an art style, and relegate the level design to another day after figuring out a good workflow for it.
This is what I came up with in the end:
As you can see, I’m not quite finished with the movement of the sheep yet, but aligning them to the slope of the ground is a fairly simple thing to fix. I just haven’t gotten around to it. They also don’t have the animations implemented yet, but they should be finished shortly.
All in all, I’m fairly pleased with what we accomplished in such a short amount of time, and I learned a TON about how difficult and time-consuming the various parts of a game really are. It was a great experience, and I implore anyone else considering participating in game jams to give it a shot.