Ludum Dare is great, a challenge to make a game in 48 hours from nothing. Every year more people join in, resulting in thousands of entries by the end of the weekend. This is the second time I’ve participated.
Running into time wasting problems is pretty dangerous when you only have two days. Preparing before you start is key. While there is some value to learning new software under pressure, it’s better using tools you already know. C#, Blender & Unity in my case. Prepare your environment before the weekend starts, too. I set up Chronolapse for making a timelapse and OBS for livestreaming. Avoid surprises once you start Ludum Dare because of software that doesn’t work.
Saturday – Stuck
With a theme of “connecting worlds”, I set out to make a twin-stick shooter. Monsters attacking you through portals from another world, while you jump through portals to different floors for momentary escape. after wasting a few hours, I wasn’t feeling it.
Keeping the pesky rival tribe out of your village didn’t feel as responsive as I wanted.
I spent most of Saturday thinking about what to do, developing every idea as fast as I could. Luckily I had some motivation from people watching my livestream, something I wasn’t used to. Having an audience watching your every move is both daunting and motivating.
By Saturday night I was able to find a pleasing style. While working, I would check George Broussard‘s stream from time to time, who was working on DINO BOLT, which is super fun. It helps your sanity to talk with others who are going through the same crazy weekend as you. The “Share on Twitter” button was something I learned from watching George, which I’m including in all my mobile games now.
Sunday – Build It
On Sunday morning I started to pin down the gameplay. I kept polishing the environment but it wasn’t until evening that I had a clear goal in my mind of what the gameplay should be. Two islands attacking each other, with an AI giant on the other side protecting its own village. I wrote all of the fundamental gameplay code during the final hours.
The gates turned out really well, launching creatures to the other side as they step through.
The key asset in game development is “tricks”. This is true for most crafts, but I do feel an intrinsic nature of “cheating” in game development wherever you can. A good example is the giant, which I was rigging and animating on Saturday afternoon. This made me pretty nervous, knowing from past competitions how time-consuming animating can be. After running into problems with skinning the bone weight, I animated all monsters through code. Rocking them back and forth on a sine wave works well. Knowing these little math tricks can save you much time.
Most code written during the last six hours was pretty horrifying. Despite that, the game appears to be glitch free. You need to go into Ludum Dare assuming your code is throw away, anyway.
Monday – Ship It!
With differing timezones, the deadline ends up being a bit different for everyone. For me, it was at 3 AM on Monday morning. I had the gameplay working well enough with 2 hours to spare. Thanks to the Unity 4.6.0 open beta, I spent the last 2 hours setting up a menu system with game instructions.
It’s easy to forget how much time the final build of a game takes. Screenshots, descriptions and coming up with a title. The deadline creeping up, I found the game crashed on Mac, too. Everything always goes to chaos in the final hours, I got lucky and found a solution fast.
I sank 32~ actual hours of work into development and I’m pleased with the result. Some 1000 lines of code, a character model, one handful of environment props and a few sounds generated with BFXR. Some of the gameplay mechanics, such as rhythmic movement, aren’t what I hoped for. After a lot of tweaking, it still doesn’t feel right. I’m thinking about turning it into a full game, though. When that happens I’ll look for better gameplay mechanics.
If you’re interested in game development, make one! If you’re having difficulty finishing one, Ludum Dare is perfect.
I created Compute Thought, a short cyberpunk graphic adventure game for #Nar8, a game jam about telling a story. I’m by no means a writer, even after years of working on games, I’ve always focused on gameplay or level design first. This was a good opportunity to try something new. You can play the game on itch.io or check out the source code (C# / Unity) on GitHub.
The opening scene went through many iterations.
Compute Thought is a story about a detective, who investigates the murder of a scientist. Set in a world where humans and androids live together, but prejudice remains. Cyberpunk is an intriguing theme, with movies such as “Blade Runner” or “Ghost in the Shell” to reference for ideas.
The first scene would set the tone of the game, a detective standing over a body. The player would interact with the environment to investigate the death. I wasn’t happy with the style at this point, the result looking different in my mind than rendered on screen. Outdoor cyberpunk environments are often dark and gritty with wet reflective surfaces.
After a few failed attempts, I focused the game on indoor environments only. The player would wake up and familiarize with the point-and-click interface. Then leave the apartment and move to the crime scene. This would have been an action scene, where the detective moves in, gun drawn, and barges in to confront the android. This was all simplified and cut in the last few days to finish the game.
Technical & Code
The fun part was implementing the point-and-click interface, as I enjoy programming in C# the most. When hovering the mouse cursor over the bounds of an object, a copy of the object’s 3D model gets shown. This copy gets generated when the game starts and given an additive shader. The object is then pushed around a bit to create a neat highlight effect.
When clicking on an object, the character will find a path to, and use it. This brings up a dialogue screen. Every dialogue I wrote uses Twine, a great tool for creating nonlinear stories. These get stored in files, assigned to each object in the editor and parsed when the game loads. Choosing a dialogue option loads the next node and options from the Twine dialogue tree. They can include tags too, which I use to trigger events, such as receiving an item or drawing your weapon.
Building a scene in the Unity editor.
Creating a usable computer was something I’ve wanted to do for a long time. It takes keyboard input and plays clicky noises for each keystroke. The input gets checked against an array of available commands. The text gets generated off-screen, then rendered-to-texture on the computer display. It’s a shame I didn’t add more commands, there was support to browse the entire hard drive contents on there. Since it was a last minute feature I added to establish what the victim was working on.
Environment & Characters
I use Blender for creating characters and environments; shaded with Unity’s real-time lighting. A strong directional light acts as the sun, rendered with HDR & bloom effects on the camera. For the skybox, an additive texture outside the windows helps the glow effect. I keep everything simple and flat shaded (except for characters, computer panels and blood to make them stand out).
The computer terminal sits close to the camera in the final scene, to signify its importance.
Modeling and animating the main character were the hardest tasks, since I usually make “cute” things. I’ve never done much character art before; animating a “realistic” human felt like I bit off more than I could chew. A proper walk cycle is one of the most fundamental animations to create, so I went through a few different iterations on there. I wouldn’t say the end result is anywhere near perfect, but it does the job well enough. The character sliding around when moving from idle to walk bothered me more.
On the last day of the game jam, I started testing the game on different computers. Two laptops would render the game too bright on certain resolutions, refusing to render shadows. The visual style of the game was a bit of a “hack”, relying on real-time lighting. Without it, the sun would make the scene over-bright and unappealing. I’ve yet to receive any bug reports of this, though. I’m hopeful my last minute tweaks resolved it on most hardware.
After releasing the game, I received some bug reports of players who couldn’t get past the computer. There was a message above the computer which read “Use Keyboard”, which I’m guessing players were trying to click on. I changed the message to “type using your physical keyboard”. I’ve not received any bug reports since.
I’m satisfied that I was able to create this game in about 2 weeks during my free time. I’ve already written more for this postmortem than dialogue in the game, reminding me that I’ve still much to learn. This was something different than I usually make, in either design, programming or art style. With more time, I would have liked to flesh out the existing features and add more interaction. For a narrative game, it’s weak in this aspect.
This was a nice test run of itch.io, which has been super great. Compute Thought gets played about 8 times a day on average, which is not mind-blowing, but okay for a game jam title. Most likely a lot more than my Ludum Dare #29 game ever did.