7 Tips to finishing a game in 48 hours
Let’s start by asking, what is a game jam?
A game jam is where one or more game developers (programmers/artists/sound engineers/etc.) create a game within a short period of time, usually 24-72 hours. If you’ve never participated in one, the Ludum Dare competition is held about three times a year, and is a great place to start.
I’ve participated in a few game jams myself and in this article I’ll be sharing with you my tips for creating a polished and fun game! So whether you’re working by yourself or in a team, hopefully these tips will help you out during your next jam.
1. Choose an art style which allows you to create assets quickly.
In 48 hours you won’t be able to create a huge amount of art with a single artist. You really have two choices - you can spend most of your time on a few assets, or you can spend a short amount of time on many assets. The latter implies that quick art is low quality. This is not true. While creating intricately detailed assets will usually take a long time, stylized art can be created very quickly. The trick to making gorgeous art in a short period of time is constraining your style. A perfect example of this is pixel art and low resolution graphics. In Stray Whisker, I decided to constrain my art style in a few ways. I knew that the cat’s animation would be prominent and require many frames to make it fluid, so in order to have enough time to do all of these frames I used a single colour and a low resolution. Each frame took seconds to draw, but the sheer number kept the animation smooth. I used single colours for all of the assets, and the backgrounds typically only used three colours each. Other examples of constraining art styles include games creating in black and white, monotone, or only using simple shapes such as triangles, circles and squares.
2. Create a low barrier for entry.
If you actually want people to play your game, you need to create a low barrier for entry. That is to say, make it very simple for people to start playing your game. iPhones are not the best platform to develop for during a game jam, as your game will be quite difficult to distribute quickly, and only people with an iPhone can play it. In contrast, web games, such as a flash games, are very easy to distribute, are typically cross platform and can be run without any installation required. However, not all games suit the web based format. CPU/GPU intensive games such as 3D ones or games which require fullscreen for immersion should stick to compiled binaries.
Low barrier for entry can also be taken to mean, “make it easy for people to get into your game”. For example, don’t have a wall of text that is required for a player to read to understand how to play your game - players don’t read, don’t force the player to watch long cutscenes - save them for your bigger projects, and let them get to the fun elements of your game quickly - game jams can produce hundreds of games and if yours isn’t immediately fun, they may just move onto the next one.
3. Use tools you are familiar with.
Game jams are a great opportunity to:
- learn new game development skills
- make a new game
Some people use game jams solely as a chance to learn a new language, toolkit or other piece of software. That’s great! I’ve done this on a few occasions myself to improve my C++ skills and learn new libraries. However if you want to finish your game and make it the best it can possibly be, I highly recommend that you use a tool that you’re already familiar with. If you’re using something that you’re inexperienced with then it’s going to slow you down and you’ll struggle to finish.
4. Make sure you have a title screen and credits.
Every good story has a beginning, a middle and an end - your game should too!* In a game jam you should aim to finish a game. This means that it should have all the basic elements that you’d expect from any other completed game. A title screen with the title of your game and a “Press space to start” shouldn’t take more than 15 minutes to implement (or 1 minute if you’re particularly familiar with your chosen tools), and will add a lot of polish to your hard work. Similarly, a credits screen will let players know who made the game and give you the chance to credit your sources. I usually combine the end screen and the credits screen into a single image. Without these two elements, your game will come across as a “fun demo”, a “nice prototype” or an “interesting toy”. However, if you include them, you’ll have a polished game. No matter how bad your game is, a title screen and credits screen will always make it appear like a finished product.
*Unless you’re making an open-ended free roaming game or you derive some sort of awesomely artistic meaning from having no proper end! In a case like this you should still include a credits screen which can be reached from your title screen or menu.
5. Choose a decent screenshot.
When it comes to submission time, if you actually want people to play your game then don’t forget to add some awesome screenshots. Make your primary screenshot one which includes all of the action or your best graphics. Make sure that your screenshot looks good even when it’s resized to a smaller resolution thumbnail. Remember that if you’re submitting to something like Ludum Dare your game will be among hundreds of others and an amazing screenshot is a great way to stand out.
6. Include a README.
README.txt - it’s a file that’s seen with a lot of programs. But what’s in a readme?
Whatever you want to put in there! Typically I use it as a way of communicating my contact information and the purpose of a game to anyone who is interested in simply more than just playing the game.
You should include:
- Name of the game
- Brief description (1-2 sentences)
- Date and reason for creation (name of the game jam)
- Your name (and/or your team’s name)
- Contact information (website, email, twitter, other social media)
And also importantly:
7. Include a license.
In most game jams, games are required to be released open source. Even so, it’s good practice to include a license with your game so that people know what they can and can’t do with your software. If anyone wants to sell part of your work, they will hopefully contact you (this is why you put your contact information above).
I typically use a creative commons license. In particular I use this one: http://creativecommons.org/licenses/by-nc-sa/3.0/, which basically states that nobody can profit from my work, and if they redistribute it they must credit me. Additionally, if they create a derivative work it must be released under the same license.
Game jams are a lot of fun! Use them as an opportunity to make a game, polish it to the best that it can be, and release a finished product. Finally, don’t forget to make them easy for people to pick up and play.
Andrew Sum - Articles on Game Design & Development
My name is Andrew Sum and this is my blog on game development.
The aim of this blog is to write high-quality, thoroughly engaging articles on game design and development. I want to make this blog a useful resource for game developers and anyone else interested in the processes involved. In making this blog I hope that these reflections on game design and development will also help me to improve my own skills and consolidate my knowledge.
I’m 21 and I live in Australia. I’ve been creating games as a hobby for as long as I can remember. I’m the developer of Faerie Solitaire (with Brian Kramer), Stray Whisker, Dungeon Dash and ZDay20. I’m currently studying a Bachelor of Science (Major in Software Engineering) at the University of Melbourne, which I am aiming to finish in February 2012. Besides these things, I’m an avid gamer and I play games from a wide range of genres (though I am a big fan of FPS!). You can find out more about me on my website: http://andrewsum.com
If you have any requests for articles or questions, please do not hesitate to ask!