NOTE - This post has been imported from the original post medium.com

This past weekend I competed in my first ever gamejam. This one in particular was the Ludum Dare (LD). It’s something I’ve wanted to try for many, many years. Out of the two options in LD, I opted for the compo. The compo is the more hardcore version, everything you submit must be created from scratch and created alone. That means music, sound effects, art, and the game itself must be created from scratch in 48 hours.

In this post I’m going to discuss a few aspects of my experience. I will break it down into these parts: Game Idea, MVP, Game Engine, Art & Sounds, Submission.

If you’re interested in seeing what I made, it can be found here.

Game Idea

I read somewhere before the jam started to take the first hour and come up with a GREAT idea. That first idea I came up with? The one that fit the theme perfectly? 50–60% of submissions were THAT idea. I wanted to come up with something creative, something unique. The rules say your game doesn’t have to match the theme, but I knew from the start I wanted it to relate.

I took the first hour to come up with my idea, and I absolutely do not regret it. Day 2, when other people were completely switching gears and changing their game, I had my idea still rock solid and looking awesome. It not only helped me save time in the long run, but it helped my confidence as I kept down the same path.

The theme they announced was The more you have, the worse it is. My idea was a side-scrolling shooter, you kill mutants and give them an antidote to turn them back into ally soldiers. The catch, and how it related to the theme, is that after a while those same allies turn back into even stronger monsters. So ultimately the more allies you have, the harder the game is. An ally after converting back to a monster An ally after converting back to a monster

There were a few other stabs at the theme, built into other parts of the game. An example of this is a monster I dubbed “The Bagger”. As you kill mutants, their bodies stick around. You can revive them, or you can destroy the bodies. If you opt for neither, this “Bagger” enemy would eat the bodies and become stronger. Matching the theme that the more bodies you have, the tougher the game is.

MVP

Once I had my game idea down, I started by writing out a list of my absolute minimum features to make before submission. As with any form of creativity, the greatest ideas come after you’ve started. I held fast to my original list, when a new idea would pop-up I would simply add that to my v2 feature list. I focused on getting only the bare minimum completed at first.

The v1 list looked something like this:

  • Player, ally, monster, and bullet images
  • Move player around map and be able to shoot
  • Monsters that move towards player and attack/kill the player
  • Be able to shoot and kill monsters
  • Allies that follow player and shoot at monsters
  • Ability to give antidote to dead mutants and turn them into allies

Now looking at that list, it seems like it would be a boring game. No scrolling, no animations, one screen with no background but a single color, it honestly looked pretty bad. But my goal by the end of v1 was to have something to play, even if that meant it was ugly.

First image from the game (~4 hours into the jam) First image from the game (~4 hours into the jam)

I also began prioritizing the v2 items as I went. Things like a game start and game over menu, animations for all characters, and sound effects started to make it onto my board.

I managed to hit my v1 goal by the end of the first night. I took that as a victory and got some sleep. The next morning I started on my v2 features, which by that point included an entire new monster type.

Game Engine

Most people I saw competing in the jam were using game making tools with some form of GUI. I had been itching to try out a new game library for Javascript, so I took this as an opportunity to sit-down and learn one. I picked CraftyJS. It is a fantastic library. I absolutely loved the way it handled collisions and its “component” system. However, the 4–6 hours I took to learn this after the jam started was probably a mistake. While everyone else was drag and dropping their sprites onto their game, auto calculating the animations and clicking “go”, I was learning how to code the animations to even load and run properly. I spent a lot of time re-inventing the wheel from my decision to not use a real “game making tool”, and I think that was a mistake.

I will definitely take the time before the next LD to actually learn the tools I will be using. Having a decent level of comfort is almost a requirement if you plan on actually competing in any way. Granted I knew I had no chance of placing anywhere respectable just based on experience alone, but if I had 8 more hours to dedicate on game design or art it would be a completely different game than it is now.

Moving forward from this jam, I plan on porting my game over to a variety of game making tools to find which one I like best. GameMaker studio, Godot, and MonoGame are a few I’m eager to try out. I came into this thinking that I could make something just as good with Javascript , but ultimately I want to make great games not say I have the coolest back-end technology.

Art & Sounds

I knew going into this jam that art & sounds would be my biggest slowdown. I’m definitely not an artist, and I’ve never created my own sounds from scratch. It took even longer than I thought it would. Using my mouse I was able to draw up sprite sheets for the animations, but it took FOREVER to do each one. I used Piskel for my sprite sheets to save some of the headache. Next time I will be using GIMP with a sprite sheet plugin to give me more tools. I will also be buying a graphics tablet to make drawing a LOT easier on me.

I also made the mistake with my art of drawing the characters in 16x16. I took this approach because I assumed it would save me time being smaller and make it easier to draw. The problem was that then the game looked tiny on the browser. For the first day, I just used the zoom function in chrome to see it better. On day 2 I realized I needed to fix something, the first thing that came to mind was using a CSS transform to expand the canvas and make it larger. I did this, but it was at the cost of image sharpness. It caused the canvas to look somewhat blurry, which was one of the first comments on my submitted game. In the future I will likely draw everything in a larger size (64x64) and just use larger brush sizes to get the same 16x16 effect while maintaining image quality.

For the sound effects I used ChipTone which made the process rather easy. With the templating built in I was able to randomize sounds until I found one close to what I wanted. At that point I could tweak it to something perfect for its purpose, then download the .wav file.

Background music was the most difficult thing I had to do creatively for this project. I had no idea where to even start. I ended up on http://www.soundtrap.com, which was a great way for a noobie like me to make some music. I listened to a few sample beats then threw together a few instruments I liked on a short (< 30 second) loop. I did end up spending about 2 hours on this part between finding a tool to make music and creating a song that I felt matched my game the best.

Submission

Submitting my game was something I had failed to fully account for. I assumed I would host it on Github, utilizing Pages to allow direct access to play in browser, but I didn’t think about other things that go along with submitting. Namely I hadn’t considered the cover art, screenshots, a description, details on the controls, details on game objective, and more.

I planned to submit an hour before the deadline, 8 PM, but I ended up submitting at roughly 8:58 PM (2 minutes before deadline). When 8PM rolled around, I finally stopped working on new features and started trying to gather everything for submission. By the time I had it submitted, it was about 8:45 and I was playing through a few times to check that everything was working. This is when I found a critical issue. If you died and clicked the mouse, the game would freeze and not allow you to restart without refreshing the page.

It may not seem like a big deal, but I wanted the people playing to hit enter and give it a second shot as easily as possible. I didn’t want them to try and play again, only to have it lock up. A bug like this just made the entire game seem less polished, like more of a dud submission. I scrambled to find the answer, knowing I had only about 10 minutes to figure out and fix it before it would really be too late.

The issue ended up being a failure to unbind mouse click on an object that is destroyed on the end game screen, AND an issue with keybindings only listening for the first key after death. I was luckily able to fix both of these and submit just in-time.

Next time I plan to stop new features about 2 hours before the deadline, to give me plenty of time to polish up anything that may have been overlooked during development. I realized as well in that last hour that I hadn’t spent enough time just playing the game and tweaking it. This led to the game being somewhat unbalanced after it was submitted, but it was a price to pay for adding more features.

Conclusion

I had an absolute blast grinding away on a game in under 48 hours. The deadline really made me break my game down into the most bare bones version I could to ensure I completed it. I learned a lot about game development by doing everything myself, and got a good look into why people opt for better game making tools than Javascript. I think in the future when competing I want to focus more on the game itself than on the technology behind it. I’m looking forward to getting feedback on my game over the next few weeks as well as playing other people’s submissions!

If you want to check out some of the other submissions to the jam, you can find them here!