Tips When Starting a New Game
Jan 07, 2013—
So you’re ready to sit down and create a new game? Great! But are you sure you have a plan that will give you the best chance for success? What follows are some helpful suggestions to keep you from falling into some common pitfalls of game development, which could leave your project dead in the water before you even begin coding.
- Pick a game you can be passionate about.
- Pick a game of realistic size that you can accomplish.
- Use Prototyping to refine your ideas.
- Take breaks! Pace yourself.
- Get feedback early and often.
- Focus on creating the game, not the code behind it.
- Don’t polish too early!
- Don’t be afraid to change things.
The Right Idea
The first thing you need when starting a new game project is an idea for your game. Yes it’s obvious you need an idea, but choosing the right idea takes more careful consideration than it seems. You, like many game developers, may have an assortment of game ideas kicking around in the back of your mind, ranging from the vague notions of doing something in a particular genre, to well-defined gameplay intricately woven with a story. One idea might be something to try on a rainy day, while another you feel is the game you’ve been dreaming about for a decade. From that mixed bag of game ideas, the right one to work on involves a balance of two things: passion and scope.
You must choose a game you can be passionate enough about to not lose interest, but at the same time one which is of a reasonable scope and complexity such that you can actually finish it. Many developers (this author is no exception) start developing a game because they want to create something, but end up abandoning it midway through because the desire to finish it wanes. In the beginning of a project, morale and excitement are high, but after the novelty wears off all that seems to be left is tedious work. Consequently, we leave it to be finished some other day when we “have time.” (Hint: we never do.)
Scope is your best Hope
Another potentially fateful decision is to choose a game idea that’s simply too big. AAA game studios, with hundreds of staff members take years to create most games, and yet somehow indie developers can fall into the trap thinking that a game half the size of a AAA game will miraculously only take them a year to do alone. The simple fact is that it takes a long time to create a complete and polished game; inevitably more than you think it will. Only after you’ve gotten a couple games of increasing size under your belt will you have a solid sense of how long and how much effort it will really take to create that game you’re thinking of starting.
Although you may be perfectly capable of diving straight into that three-year epic game project as your first real game, it’d be an extremely sobering bummer to find out midway that you’ve burned yourself out due to unforseen problems, delays, and unrealistic expectations, wouldn’t it? Choose a game that will keep you interested all the way until it’s completed, and isn’t so large that you can’t complete it within a reasonable time frame.
Once you’ve settled on at least some general idea of what the game will be, rather than starting off on what will become the final version of your game, create a quick and dirty prototype. We can easily fall into the trap thinking our idea is rock solid, only to find out later it’s a dud. How many games have you played that looked good, but just weren’t any fun? An idea might sound great, but you want to know that it’s fun, and that’s what the prototype is for.
Another super useful reason to prototype is to flesh out the ideas you’re not sure of. If you have a dozen games in your mind and you’re not sure which is best, spend a month prototyping a bunch of those games to validate and cull them, deciding which is the one you want to then invest all of your time and energy into. By prototyping numerous ideas first, you no longer need to be afraid of picking the wrong idea. The fear of failure can very often cripple a budding game developer, and prototyping is a great answer to that.
So what should you keep in mind when creating a prototype? The goal of a prototype is to learn things about your game, not to actually create it. Rather than focusing on creating the game correctly, focus on quickly creating a barebones version of it. To do this, you might use a different language or tool than what you expect to use for the final game.
For instance, even if you’re planning on creating the entire game from scratch in C++, consider using a higher level language like Python or Flash, a tool like GameMaker or Unity, or maybe even create your prototype as a mod to an existing game so you can start chugging away at gameplay immediately. This is an approach used by indies and AAA game studios alike. Naturally, if you’ve never used the other language or tool before there will be a learning curve, but as with all things, once you get the hang of it, you can be a lot more productive, not only on this project but other ones in the future.
When bulding your prototype, you shouldn’t be concerned about using proper coding techniques, or the limitations and longevity of your code. Your prototype doesn’t needs good graphics, or even any sound effects. Even if you’re planning on making your game in 3d, consider if you can create the prototype in 2d setting to save a huge chunk of time. Whatever gets you to that point of having a playable game the quickest, do it. The sooner you can play your game, the sooner you can refine it to make sure the gameplay is right.
Finally, once you’ve learned everything there is to learn from your prototype, toss it. Starting fresh in your final environment, knowing you have a game that will be fun, you can take the proper time to craft your code well, without having that uncontrollable compulsion to rush things just so you can get to the gameplay. In the end, the final game will be more robust and polished.
Keeping Momentum Up
Getting the game idea off the ground is a challenge, but after starting work on the final game, there are other hurdles and hazards as well. Time management, critical feedback, planning, and motivation must all be carefully managed to avoid burnout or a complete crash and burn at the end of the project.
Creating a game of any significant size takes a significant amount of time and effort. Programming productivity often ebs and flows. For a time, a surge of raw coding power can be shooting from your finger tips, allowing you to blaze through your task list like a katana through a melon, but then follows a seemingly everlasting period of tedium and depression where something “so simple” ends up taking many times longer than expected to solve. Sometimes the work can still be interesting, but let’s face it, sitting in a chair all day can be boring!
Planning BreaksAAA studio memeber about their long hours.) One of the simplest ways to be more productive and keep morale up during a long development project is to take breaks. Don’t sit for 12 hours at a time, even if you are being super productive, because tomorrow you’ll probably be burned out and just want to eat chips and watch tv. Take a couple short 15 minute breaks and physically get up and go do something else. Feeling lousy? Drained of energy? Exercise is a great way to combat laziness. If your eyes are drooping and your brain is wandering and it’s only early afternoon, get up and do a couple dozen jumping jacks, or jog for half a mile. Physical exercise increases blood flow and releases endorphins making you feel better, and the more often you do it, the more positive the effect. It really does work.
If you’ve ever watched a live announcement of a new surprise product, then you know the anticipation and excitement can be magical. As game developers we want to capture that same kind of magic when unveiling our game to an unsuspecting public.
Although you may be making your game the way you want it to be, don’t lose sight of the fact others will be playing your game, especially if you plan on selling it. If you get feedback on your game early and often, not only will your testers find bugs and mistakes, but they can also point out flaws in your gameplay or give you new ideas. Certainly, many of their suggestions may not be suited to your own vision of the game, but even if onl one or two really good thoughts come about from all of the feedback you get, isn’t it worth it in the end?
Also, falling in love with your game so much to the point of ignoring any criticism can blind you to the fact that there may indeed be real problems with it. Don’t be afraid to step back and reconsider changes.
Focus on the Important Things
Remember you’re creating a game, not a game engine. As programmers, we naturally like well written code that is flexible and powerful, and try to keep one eye looking forward at things that we might need in the future, and plan for them now. As game programmers, especially with such highly professional games to compare our own too, we can easily fall into the trap of thinking of everything we might need, and start building a “game engine” more than a game.
For example, once you have a little gameplay working, you may want to add your first few sound effects. Now not only do you start thinking about how to play those sound effects, but you also start to wonder about how many others there will be, and how you’re going to manage them. Are they all going to be in memory at the same time, or loaded at the beginning of a level? Perhaps you can simply load them on demand, but when are you going to purge unused sounds from memory? How will you map which sound effects are used by which level? Perhaps you could write it in code, but it’s probably better to do from a data file, right? So what format will that file be in? You want to design the file format to be flexible from the start so you don’t need to rewrite it, so you should think up everything you might need and allow the format to contain that information…
Something as simple as playing one sound effect can easily cascade into a huge amount of work up front because of we want to be sure we do it “properly.” Your thoughts and planning may be carefuly formed, but the problem with predicting what you will need is that it’s a prediction, not a guarantee, and developing whole systems up front before using them, can easily lead you to create more work in the long run because you wrote code adding capabilities you didn’t need, you have to change some code in the future because it won’t really fit together with other code you haven’t written yet, or because two weeks from the time you write that code you’ll think of a simpler idea.
In programming, we very often can’t know everything about what we will need, and instead have to set our sights on what we do need. So rather than spending the time on complete and robust “systems” up front, start off by simply accomplishing the smallest atomic goal, writing the least amount of code possible to create a reasonable solution. In the future, once your requirements have settled down and you know much more about what you really need from a given “system,” then you can take the time to modify what you have to make it everything it needs to be. Then in your next project you have a new base to start from — with the experience learned from previous projects, you’ll know about the true realities of what you need, and can adjust how you start off.
Don’t Polish Too Early
All game developers should take the time to polish their games, and although it can be a time consuming process it can also be really fun. Beware, however, that it’s a trap. Don’t fall victim to polishing too early in your development process. It’s easy to get sucked into focusing on polish early on; Once you have some gameplay and sound working together well, it’s easy to be tempted to immediately start replacing placeholder art, adding particle effects and juicy animations. All worthy things to do, certainly, but don’t let it distract you from completing the rest of your game. By spending too much time on polish early on, you risk letting your long-term motivation atrophy, losing the ability to add more to your game. By putting polish on something, you’re also subconsciously declaring it finished, and are less likely to alter it even if it’s flawed.