Alright so you got a week or less to make a game, how do you do it?
Disclaimer: I have participated in 3 game jams where professionals also participated, and a similar lighting challenge. I have not won anything in these game jams, and they have made me actually hate the entire concept of game jams that last a week or less (see part 2, linked below). I want to get a job in or start a AAA studio as I have found indie work very tedious, rather lame and unimpressive, time and resource consuming, and not very rewarding (with exception). But if you want to make your own small game then by all means find a game jam! All these comments are from my experience, and a do as I say, not as I do sort of thing. This is intended for people doing things in a limited itme span (code jams, game jams) and/or people looking to do jams and join the video game development industry, or are already in the industry.
- Come up with an idea. This is the hardest first step to do, so you need to come up with a concept, in about 5 minutes. Trust me you don't want to spend a lot of time on the idea unless you actually have time like a whole month to make the game. Either way, the concept needs to be the smallest part of making the game. In fact you should start coming up ideas before the game jam starts, if possible, but since there's pretty much always a theme to limit your game, your idea probably won't end up compatible. In fact your idea might be dumb. But here's what your idea should be:
- Related to the theme, obviously. Of course themes often are open to interpretation, so often times the first thing that pops into your head might be the golden idea, so consider the next thing:
- Simple. Don't overcomplicate things- you need some basic mechanics. Come up with something the player will do or control, objectives, and a setting. Does it involve procedurally generated infinite worlds? Is it a complicated plot with deep characters? Does it involve networking in any minor sense? Does it cover something you don't have experience for? Do you have to package the game to submit? Does it involve complex VR interactions? If you answered yes to any of these, then your idea is too complicated, I suggest coming up with something else. (But if you feel confident then go for it.)
- Unique, but all things considered don't try to go too innovative or expansive unless the jam judging relies heavily on the theme itself.
- Get people, if possible. Unless you're an all-fields artist, sound designer, and engineer with a master's in one of those fields, a bachelors and minors in the others, I'll bet your final product will suffer in one or more areas. Focus on what you can do well, and let other people do what they know what to do to do what they do. In a group setting you'll need a leader, and given the small size of a game jam group this leader should not only have a good understanding of the idea, but also have experience in all other fields so they know at least what to expect from everyone.
- If you are looking to do a jam to learn or try something new, consider first if it's viable to do such in the given jam, and if it is then seek people to fill the role you would otherwise fill, and people that are willing to help you with the role you're trying out.
- Learn the tools. (Note, if you're looking to do a beginner jam, this might not apply to you as the purpose of the jam might be to learn the tools) You don't have time to figure something out because there are other people who already work with those tools on the daily that you need to compete with. When you sign up for a jam, make sure to plan on what you might need. Often game jams using specific tools will have resources to learn the tools, but like in point 2, if you don't have the skills and experience in the field that the tools is used for (like animation and Maya, or programming and any language), don't bother unless you got the time to take on practically an online course worth of self teaching.
- One exception to this- learn version control!!!! Regardless of who you are, backing up and sharing project files is an essential part of working in a group on a digital multifile project (like a game). Also know the difference between tools- Git is open source and great for text files, but not for images or large files; SVN is a bit old and might be a bit more difficult than git but can handle file checkout/checkin; perforce is made with games in mind but might require a paid repo depending on project size; other tools like PDM are specialized for certain things like CAD. Don't use cloud storage like Google Drive or OneDrive as these can create issues with conflicting files that can't be resolved.
- On the subject of version control- learn the primary engine being used!!! You don't need to know every single part, but the most fundamental features like making a new project, importing and exporting files that you'd work with, running the game, and packaging are essential. The alternative would be to shift the work of packaging or testing or importing to one person, and trust me unless it's their job to import your files, they'd rather be doing anything else. So learn the pipelines between the engine used and other software used so you can minimize the time consumed moving files around. (On that note, emailing files or sending them over chat isn't a form of version control, either; if anything that'll complicate things.)
- Use the resources available. You don't have the time to make every last bit in your game- if you can use models or sounds from other sources, then seek those models and sounds. Remember, a game is unique because of the ways these resources interact with each other to create a unique experience. Sure you can model a tree, but would a generic model tree act the same for your background props? Or do you need to find sound effects instead, because this custom modeled tree will actually transform into a monster?
- Prioritize.What is absolutely essential for your game? (You must make that decision, and it'll be different for every game and developer.) Essentially, I say work on those features until it's either at a production-ready state, or you subsitute it. If something's taking too long to get working, look to switch the feature (it can't be removed if it's essential). The best place to be in during a game jam is in a state of enhancing gameplay with new features and improvements, with a basic game done and essential features implemented well. Once or if you get to that state, you can then start making all the features you dream of. But beware- the more you add the more you might break. IF something essential breaks, shift your priority back to fixing what became broken. Take notes on what you change so if it takes too much time to fix, you can revert your changes for this new feature- bring things back to a simple, working state. But if everything's working and you got time then go for the extra mile.
- Package early, package often. (Also, test) I'd say it's more important to package often, and test those packages, because often there will be differences with a final product and and an in-engine test. Things can break for literally no reason in a fully packaged build, and performance can become better or worse. If a packaged build works well, and has all that you need, save it- cherish it- upload it early (you can resubmit, chances are you're using itch.io. Your next packaged build might not be as good. And don't package to the last minute unless you like to wait overtime or for your computer to bluescreen.
- Get stuff done until the last minute only if it's absolutely necessary. If you're at the state where you're only fixing stuff, then get as many fixes as you can get in, in- but never upload something inherently broken!!! If your game is solid and you figure you don't have the time to make something new, then take a breath and relax- you're done, and you aren't under the pressure to go submit something last minute. Play your game, test it until it's burned in your memory, and quickly fix any last minute bugs. However if you're behind, then you need to spend every last minute making sure your game is what it needs to be, or otherwise face the fact that what you upload won't be up to your vision, and it'll probably be broken.
- Focus on the game when you can. You only have a week to make a game that'll compete against industry professionals- you need to fit in the work that these professionals manage to do for most of the day. This probably means sacrificing free time to work on the game, or sneaking in time between classes to get work done. This is if you need to get in all the work needed for the game. If you however are in a good development spot, or have an accurate schedule to get work done, then this tip is flexible. And I would suggest not getting burn-out over making a game.
Check out more blog post articles here.
No comments:
Post a Comment