The clock is ticking, and there is less than 5 days left to get your game into the Touch the Stars Game Jam! Don't miss your chance to win a $1,000 Grand Prize, get your game in before the deadline. Need some tips on how to do it fast! We're here to help with this tutorial.
So, you’ve joined a Game Jam and want to create the best game you can make. However, you’ve only got a certain amount of time each day. While you could run helter-skelter with every avenue of creation, you can get it done much faster with a little bit of organization. And if you are a solo developer, it’s even more imperative that you follow some sort of best practices.
Here are four tips to help you create your Jam game as quickly and efficiently as possible.
The best thing you can do is keep it simple. Creating a complex and deeply involved game for a contest not only decreases your chances of success, but also increases your chances of burning out. Therefore, you should keep it simple. If you’re creating a card game, focus on the card game itself, keeping other stuff, such as moving around the map and interacting with other characters, to a minimum. If you’re developing a shop simulator, avoid a full-scale dungeon crawl. Even when developing as part of a team (which gives you more leeway), the less “moving parts” your game has, the better.
Feature creep can kill any game. For a contest, though, you want to trim the fat even further. Only use features completely essential to your main gameplay. Anything else should be cut. Consider your core gameplay loop. What is happening moment-to-moment? If you are tempted to add a feature that doesn’t move that loop forward, you need to cut it. Don’t add a combat mechanic to a rhythm-game dating sim. Don’t add a dynamic day/night cycle to a completely indoor dungeon dive. You can always add more things later, but if it isn’t needed for your game to function for the Jam, then don’t add it. As a side note, if the core premise of your game is “A Dating Sim where you have to Subdue your Dates”, then obviously combat is a main feature. Examples are not rules.
Unlike the normal Dev Cycle (Early Alpha, Alpha, Beta, etc.), the development of a contest game doesn’t have the luxury of visiting, revisiting, etc. Instead, you must focus on submitting the game with as much polish as possible by the deadline. Therefore, you’ll want to break your game up into chunks (we call them “Blocks”). These are parts of your game that are complete sections. This could be the floor of a building, a room within a mansion, or a glade somewhere in a forest. You then want to work on the entirety of that Block, from start to finish, with everything other than custom assets. Map out the level, add activators, and program your logic.
Once the Block is created, and all you have to do is add custom assets, stop and test it until every bug is gone. Make it as fool-proof as possible. Then move onto the next Block. This has two advantages. First, it ensures that each part of your game is as bug-free as possible. Second, it gives you an idea of how long development of your game will take. If it takes you four days to do one Block, and your game has five Blocks, it will likely take you twenty days to complete your game. You can then adjust your ideas accordingly.
Please adjust your ideas instead of cramming to get them all implemented….
Think of the development of your contest game as one super-charged Alpha. Go completely in on features and gameplay and ignore any custom assets (graphics, music, animations, etc.) until you are completely finished, and it the game is as close to 100% bug-free as possible. Then add in your custom assets and test more, both to make sure the new assets work and to ensure that the game itself is ready for submission.
If you can visualize your game as Blocks, segment your tasks accordingly, and only add the graphical and aural polish at the end, you stand a much better chance of your entry carrying you to the finals, and maybe even placing.