Intro/About

My name is Dave Ratti. I entered the 48 hour contest both times it was held while I was at UofM. My games were Marble Bandits and Blobby Waters. I now work in the Game Industry. I hope this article will be useful to those entering or thinking of entering the 48 hour contest. These are just my opinions and strategies that I formed from doing it twice. Some of my advice will pertain only to programmers but other advice will be more general that everyone can use.

Why Do the Contest?

The 48 hour contest is a great thing to do if you are at all interested in game development. You will learn a lot, you will have fun, and in the end you'll have a small game demo that you helped create. Its a great feeling and you only get one chance a semester to enter. Even if you dont have the skills now, you should keep entering: by the time you graduate you'll be good at it. Also the kinds of games that will do good in the 48 hour contest are also similar to the kind of game demos that are good to submit to game companies: short, simple and polished games.

Starting advice

You should go into the contest knowing what programming environment you will make your game with. You should re-familiarize yourself with it if necessary. I think its a good to go in thinking "I'm going to make a 2D game, I'll be using SDL to draw sprites, and this is how I set things up" or "I'm going to make a 3D game with physics library X". You *must* have some sound or music in your game (its not in the rules, but since your final score is a composite of several categories, a 0 in music or sound will destroy your chances of placing). So I suggest figuring out how to play an mp3 in the background using the library of your choice (I always liked FMOD), and at the very least you can use a freely available mp3 for music and not get a 0 in music/sound.

What kind of game to make

Short, simple, and polished. If you look at some of the games that have won in the past: SheepHerd, Animal Escape, Blobby Waters are all very simple polished games. They were all pretty much finished at the end of the contest and were easy to pick up and play. Its very important not to make your game too hard. If possible, avoid games where the player dies and has to restart, or anything that a player could be stuck on. You should periodically have others play your game during the contest without your help and see how they do. You really should shoot for having 80% of your game be seen if someone sits down and plays for more than 5 minutes. Remember the people playing your game wont all be experienced gamers: most faculty judges wont know how to circle strafe. Keep this in mind!

Design Docs? ROOFL

Theres no time for design docs. Theres no time for UML or flowcharts. This is a hardcore 48 hour, balls to wall, screw all your OO design principles and just make the goddamn thing work contest. However, something can be said about the process of desiging a game *while* you implement it:
  1. Start with a toy. Just try to put things on the screen that interact with each other. Basically make a game that has no rules. Have the player control something and let them interact with other objects. Stuff like "He can pickup these things and he gets a small speed boost" or "he can shoot these things and they spawn littler things". Just little stuff like that but with no real goals or rules. the key here is that you havent committed yet to any specific design or even genre necessarily.
  2. Figure out what is fun and start to design your game around it.
  3. Slowly start to apply rules to your game: A scoring system, a death system, and level completion system, etc. Slowly add these to your game and continue to test, making sure that the original thing that seemed fun is still fun.
  4. Polish polish polish! Dont cut it too close when it comes to adding game logic. Get your game up and running and give yourself plenty of tiem to just go in and polish things up. Make the game as clean cut as possible.

Pitfalls

-Making your game too hard. Dont be that team! Remember some of the judges are gonna suck bad at video games. If your game is too easy and everyone beats it, at least they will have seen the entire game. People like to win, its OK if they do. If its too hard then you will either have to skip them past the hard parts or they might not even see the entire game. You want them to see the entire game.

-Panic. DONT PANIC. You may find yourself 14 hours into the contest and feel like you are going down the wrong path. Stop, take a break, and think things through. Its ok if you change course during the contest, just do so in a way where you can keep most of the work you've done.

-Making a game too complex or one whose fun factor will hinge on something complex like good AI. Again, just keep it small, simple and polished.

Random tips

-Make a very conservative estimate about how much art your team will be able to produce in the 48 hours and design your game with this limitation in mind. Unless you have a dedicated artist, I guarantee you will be hurting for art assets. Its important to keep your art looking the same too: you cant produce half of your enemies and use clipart for the rest: they will just look out of place and different. If you are going outsource some of your art with freely available stuff, then make sure the art you produce will look good next to the clipart.

-Because of art limitations, I would actually recommend a 3D game over a 2D game if the programming skills are there. A lot can be done in 3D with just simple shapes, particle effects and lighting. You can still code most of your game logic like it is a 2D game. Its especially easy if you keep the camera in a fixed place during gameplay.

-BRING A WHITEBOARD. You can get a small one for $10 at meijier. This will save you much anger and smashing when trying to explain something to your team. Also great for making lists and writing funny messages about people's body odor.

Closing

I hope this helps. In the end just have fun and enjoy yourself. Im jeolous that I cant be there :)

Note: views and opinions expressed in this article are the author's and are not necessarily those of Wolverine Soft.