Ludum Dare 32: Post-mortem
Ludum Dare 32 was my first game jam and it may very well be my last unless I can get a more healthy relationship towards tight deadlines and working with smaller projects.
Ludum Dare is finally over. I hated it while it lasted, but I'm glad I participated and hopefully I learned a lot from the experience. I guess time will tell. I'm writing this so I can look at it later for reference and for anyone curious about why my game turned out the way it did.
Ludum Dare was easily the most stressful thing I've done in recent memory. It was like last minute studying for an important test or working towards a Monday deadline at work, except I did this completely voluntarily. I had this constant feeling that if I didn't spend every waking hour on the game I wouldn't make it by the deadline, but I also had this absolutely toxic idea that if I did spend every waking hour on the game I would complete it and it would be amazing. Taking a small break would perhaps have allowed me to see that there was no way I was going to finish this game and there was no need to spend 40 hours on it.
I worked on this from 07:00 to 03:00 on Saturday and 10:00 to 04:00 on Sunday, with only the tiniest of breaks for ingesting nutrition and disposing of it later. That's only 8 hours out of an entire weekend which I didn't spend in front of my computer. Not particularly healthy and not particularly fun. There are perhaps some people who enjoy that sort of stress, but that's not me. I knew this beforehand, but I didn't think this would turn into such an endeavor. I honestly thought I would come up with a 15-20 hour game idea and have time to go out with friends on Saturday and then just finish up the game slightly hungover on Sunday. Instead I turned it into an absolute nightmare.
The initial idea
The theme was "An unconventional weapon". I did not like this particular theme from the start. I had a lot of great ideas for some of the other themes, but I actively refused to think of anything for this theme because I felt like it would just result in a lot of shooter games with unorthodox projectiles. And from the 50 or so games I've rated so far that seems to be the case. The games I've rated the highest didn't seem to care much about the theme at all. Not that I'm throwing them under the bus, but it seems to me that you can win the overall category while having the lowest score in the theme category. I would have thought the overall score was calculated as a weighted average based on the other scores, but that's something I'll have to ask the Ludum Dare organizers about, not rant about here.
I spent the first 2 hours on Saturday trying to come up with a theme. I was considering not participating at all because I disliked the theme so much and I imagined the weekend would be rather boring if I was trying to make a game I didn't like, but I had talked so much about this leading up to it I felt like I had to participate. I then got the idea for a game where you used a teleporter to kill people just like telefragging in Doom and Quake. I felt like this could make for a fun game and it would be fairly unique as well. I had 2 simple requirements for my game. I wanted stylish graphics and gibs, i.e the enemies should explode into body parts when you teleported into them.
In both Doom and Quake telefragging happens sort of randomly and out of the players control. I wanted a game where you aimed the teleporter like a weapon. At first I thought of a game where you had to aim your teleporter sort of like you do when you line up your shot in a golf game, i.e. hitting something with the teleporter would require enough skill to be the meat of the game. You would first set the angle then the power and this would determine where you landed. If you landed inside terrain you would kill yourself. Enemies would be trying to shoot you with conventional firearms so you would have to constantly move around and try to kill them without killing yourself. Even though I didn't think of it at the time, in my head, this sounds a bit like Ronin, the upcoming ninja game published by Devolver Digital. I should perhaps have looked at that for inspiration.
As for graphics I knew I wouldn't have the time to create something complex and I really like stylized games. I was undecided about whether I wanted the game to be 2D or 2.5D, but in the end I decided I did not want to draw any sprites so I went with 2.5D. I wanted something which looked like Mirror's Edge. The bright red blood splatter would be in stark contrast to the white geometry of the levels, much like in the game Mad World. Unity 5 comes almost preconfigured for a Mirror's Edge look with its procedural skybox and the Enlighten global illumination.
To keep content production to a minimum I figured the game should be arena based or that I would create something procedural based on a few simple modular assets. I didn't want to spend a long time creating unique and interesting levels.
The problems began almost immediately. The first thing I implemented was the teleporter, but I initially implemented it such that you teleported to your cursor because that was faster to make. I found this to be so much fun I decided to keep it with no thought given as to how this would affect the rest of the game. Suddenly the game required no skill to play whatsoever. So to fix that problem I thought of how the teleporter could be used to solve puzzles etc. That's where everything went downhill. I was already adding features left and right to my original, simple design, without thinking about how they would affect the game as a whole. Truth be told I didn't have a design document or anything like that for my initial idea, it was just what I've written here, but it was at least a lot more focused than the product I ended up with.
I tried updating a work in progress thread on the official Unity forums while I was working. Looking back at that now it's easy to see where I should have stopped and refined what I had instead of adding more features to it.
My first test build was uploaded at 14:00 on Saturday. By then I had spent 2 hours coming up with the idea and 5 hours working on it. My next test build was 6 hours later and the game looked pretty much the same. Most of that time was spent learning how to rig and animate characters which is one of the things I felt turned out ok. But the remaining ~30 hours didn't really net anything I'm happy with. It was just a rush for the finish with features thrown in willy nilly. I would much rather have ended up with a polished tech demo of my core concept than the attempted finished game I submitted. People would probably have rated it even lower than what they are doing now, but I would be much more happy with it.
One problem with changing the teleportation mechanic and deciding the game should now be a puzzle game was that this clashed completely with my original concept. Where does telefragging fit into all of this? I had no idea. I was designing the game as I went by this point. But the biggest problem was that puzzle games require a lot of thought given to level creation which was completely opposite of my original idea.
So I ended up spending most of Sunday just throwing together, literally, a level in 3ds max. I had 1 test module already designed and I created a rock model which was basically just a tessellated box with noise on it. With these 2 models I just mocked up something which is something you would do for a game prototype I guess. Then with the remaining time I tried squashing as many bugs as I could and threw a bunch of image effects on the Camera to try and hide my horrible level. All the props were just created with primitives inside of Unity. In the end I ended up with a barely working prototype of a game with a ton of broken and clashing features just tossed in there to provide some gameplay.
The end result is very similar to The swapper which a lot of people have called me out on. This is entirely by accident. I have played The swapper, but I never thought of it both when coming up with the idea or when developing the game.
Other reasons for my failure
I was ill prepared. I know the Ludum Dare compo rules state you should create everything from scratch, but you can obviously gain experience beforehand and have it at hand when the competition begins. I also imagine a lot of Ludum Dare developers reuse snippets of existing code or look at it for reference. I didn't really have any of these. I have used Unity for nearly 8 years and I have plenty of experience with it, but I have no experience with creating a game within a fixed timeframe. Everything I've done with Unity has been hobby oriented and whether it took 1 hour or 1000 hours didn't matter. I also jump from project to project as I see fit without finishing or polishing what I have.
First of all I had no proper character controller scripts in Unity, especially not for 2D. I based my code on a very experimental 3D character controller I was making for another project which ended up taking a lot of time and the end result was lackluster to say the least. I also didn't have any of the boilerplate stuff you need for a completed game. Stuff like menus, tutorials, checkpoints etc. I ended up spending a lot of time on the in game help which doesn't work well at all, neither did the checkpoints. And there is no menu or even a way of quitting the game if you're playing a standalone version.
I also chose, not deliberately, the absolute worst type of game for a game jam. A graphically intensive, dark game. And I included no settings for tweaking brightness or quality levels. You can choose an overall quality level when launching it from one of the standalone builds, but every single one except for "Fantastic" is untested and possibly broken. This means my game will probably look different for everyone playing it and for some unlucky, or lucky, few it will be unplayable either because of performance problems or because it's too dark.
I should also have spent even more time in the week before Ludum Dare coming up with multiple game ideas for the different themes. I was watching Quill18's livestream while I was developing and he seemed to use Evernote to great effect with dozens of notes and ideas about all the different themes.
What actually went right
One thing I feel went right was the teleporting itself. It's not polished, but I had it working after just a couple of hours and it barely changed after that. It's not particularly original nor does it offer great gameplay mechanics in its current form, but if I had just focused on that one thing instead of on all the other crap I think I could have refined it into a solid idea and a solid game.
Another thing I'm happy with was the rigged and animated character. The rig is horrible and the animations are my initial test animations that I never had the time to redo, but it's an actual rigged and animated character and not a cube or similar. It didn't take that long to do either even though I had to google for tutorials and help for everything along the way. Creating the ragdoll for him was super simple and quick as well and I love ragdolls, they make any game better.
My plans for the future
I will participate in the next Ludum Dare if I can prove to myself before then that I'm able to make a game in 10 hours. Why 10 hours? 10 hours over the span of a weekend will give me time for doing other things and if something should go horribly wrong with my game, I will have plenty of time to fix it. It should also remove all the stress of working around the clock which was the thing I hated the most with this Ludum Dare. If the game ends up taking 15 or 20 hours then that's fine as well, but I will aim for 10 hours. The deadline is also at 03:00 the night before a workday here in Norway which is another reason I want to complete my game long before the deadline.
My plan is to learn how to do a 10 hour game before the next Ludum Dare by practicing doing exactly that. I will come up with a game idea and then try to develop that game in 10 hours with a timer running. It doesn't have to be in one sitting, but I will make sure I only spend 10 hours on it. After 10 hours has passed ideally I want to have finished game, but most likely the first few times I will not be, but hopefully I can at least see what I could have skipped, what went wrong, what went right etc.
And if these practice sessions show me that I'm unable to either make fun games in 10 hours or have fun making 10 hour games I won't participate in any more game jams. In that case they simply aren't for me. This may very well be the case because I'm the type of person who really enjoys polishing a single feature for a week, and I absolutely hate showcasing something I'm not happy with.
I will not attempt to finish Telefragger. I feel like it's the type of game that requires at least another 100-200 or even 300 hours to complete and even then I don't think it would become a good game. I will however consider giving my original idea another go. Perhaps as the first 10 hour game I make.
I used Unity, obviously, 3ds Max, Photoshop, Adobe Audition and LabChirp. I also tried using the Python scripts Autotracker-Bu and Autotracker-C for music, but I found those to be just awful. They just generated slight variations of the same song with no options for tweaking it as far as I could tell. I plan on learning FL Studio for the next one as it looks easy enough and making simple music is something I want to learn anyway. I figure I can use FL Studio for most sound effects as well.
I created all the sound effects for the game in LabChirp. I found it to be superior to the Bfxr/Jfxr/Sfxr programs recommended everywhere. LabChirp can create high quality sound effects I would even consider using in an actual game. I tweaked and combined some of the generated sound effects in Adobe Audition. I feel the simplest and most important tweak for any sound effect is making sure it starts and ends at 0 volume so it doesn't create a popping sound when you play it in game.
Here's my Ludum Dare entry page:
Here's my game page on this site with direct links to the Web Player, standalones, project files etc.:
Here's my WIP forum thread on the official Unity forums: