Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
When you start a new game project, what do you do first? How do you begin? What gives you the best head start toward completing the project rather than burning out before it gets anywhere?
Mods please help with the tags... I have no clue how to categorize this... :)
Prototype. Try to implement your game concept using some sort of quick iteration tool. Try python or just some easy-to-work-with open source api to get your "game idea" running. Try to simplify as much as possible, use balls instead of characters, get the vision down on some sort of visual representation. That way you can always look at it, discuss it, debate it and give feedback. Put a set timeline for each prototype (maybe 2 days? maybe a week tops?). That way you only get to do as much as you want to do in the prototype.
Sometimes you might be able to plot your idea down on a little piece of paper if it's simple enough. Once you have your idea set, start planning to see what kind of systems and mechanics you need. Try to structure the time-lines for things and see if it's possible to commit to them. If you're a bunch of people that want to make a game together, you need to do this together. Do it over a beer, either in person or using a voice-chat program. Once you know what to do - everyone can start with what they're doing. Make sure that you have communication. Try to have a team-meeting with a frequent interval dependant on how much time you guys want to put down.
If you are making your own game, remember that time is limited and you can't do everything pretty. Maybe spheres and cubes will be enough to get your graphics going if you're a programmer. Realize your limitations and work with them rather than against them.
I hope these few tips help :)
As a teacher, I see a lot of student hobby projects that fail. Invariably, the single highest reason for failure is overscope: the project starts out as this grand vision of a huge thing that's too big to possibly complete, more and more people are brought on until it collapses under the weight of its own design, and everyone leaves feeling frustrated and demoralized.
The best remedy for this is to constrain your scope ruthlessly. Instead of saying "how do I keep my energy up enough to finish a long project?" you should instead be saying "how do I design a project that's short enough that I can finish it before I get bored with it?"
"Game jam" events (make-a-game-in-a-weekend sorts of things) are a great way to get started, and they're great for building good habits when making rapid prototypes. At WORST, you spend a weekend making a lousy game... you probably learned something in the process... AND you saved yourself months of working on an idea that ended up not being as cool as you originally thought. At best, you find that you have something really special, and can start adding small features one at a time until you have a full-featured project.
On my own small hobby projects, the other thing I've found that helps is to start with a complete list of all known development tasks that need to be done, ordered, and scaled down so that each individual task is doable and testable in maybe 30 to 60 minutes, tops. It is very energizing to do a small task, see it working in the game, and crossing it off the list... which then just makes it that much more likely I'll do the next thing on the list since the last one was so easy, and then the next... sort of like eating potato chips.
Another hint: whenever you successfully implement a new feature, make a backup (or use source-code control, which is basically the same thing, but not everyone uses source control if it's just them working on their own personal project). That way if you totally screw up the code at 2am and can't figure out how to get it back in a working state, the project isn't dead and doesn't have to be restarted from scratch; instead, you just roll back to the last completed and working milestone, and try again.
I would say the really important thing is to always have something showing.
I mean, you could spend ages and ages on a data driven entity system, with deferred rendering and really high FPS, and all that. But chances are you'll get bored of having nothing to show, and give up. Whereas, if you first try getting a few models on the screen, move them around, and go from there, you'll have a much better chance.
I think the first is bottom-up development; working from a framework up to the actual content, and the second is top-down; working from getting some content and building up from there.
A little point, but something that really helps.
As a lone developer I find it helps to implement sound early on. I find it motivates me to work harder on the other features because even in the first few weeks (with graphics limited to brightly-colored polygons, flaky collision detection, missing controls etc.) the sound still gives it a feeling of being "nearly there."
I once worked on a project that was seeming to do everything right. They'd set up a website/bulletin board for everyone working on the project to collaborate. They'd presented everyone with specific timelines and goals and the game itself was a good concept. Despite this, it still only took about 2 months for people to start dropping off the map. After 3 months, development was finished and the game was never completed.
So if you're working in a team then I think you need incentive. You need someone continually in contact with everyone making sure they're doing the work and reminding them why they want to keep doing it.
If you're working alone; I'm not too sure. I'm terrible with artwork etc. so I mostly concentrate on the engine side of things. This is always enough to keep me interested :)
Developers will always tell you not to move onto new areas until you've finished the one you're working on now. If you're trying to build a game by yourself then I don't think it's too heinous if you decide to break this rule. Working on something fresh is a good way to keep your excitement levels up!
There are a lot of good answers, but I'll add mine as well:
I would like to expand on the last point a bit, since I've seen it happen multiple times: never build a framework first. There are many reasons, but basically, you won't have the necessary vision to do things right, you will waste a lot of time thinking about what-ifs and you will lose morale when after X days/weeks of working, there will be nothing to show for it.
The problem is that framework are often necessary to the end product, so, what's a coder to do? Start building specifically, with hard coded values. When you'll need to change a value, make it modifiable in options. When you need to make two similar things, abstract the similar pieces together, but keep the rest specific. If you keep doing this you will actually end up with a framework that springs into existence due to necessity, instead of wasting time on what-ifs at first.
After you build you Xth game, then you can consider starting with the framework, you'll have enough experience by then to pull it off.
I had two or three notebooks worth of ideas before I actually started developing my first game. I spent several months playing similar games for research purposes--determining which features I liked or didn't like. I generally try to focus on the mechanics first and tackle the look and feel later (but being careful not to ignore usability). I'd recommend having a rough but thorough design before you dive into development. Don't try to nail down every detail too early, as your design will necessarily evolve to accommodate playability issues, technology limitations, etc.
Make sure your idea is full by brainstorming it and writing down some key design goals. I go through a process I call finding the game 'soul'. IE what is the main reason I'm making this game. From here I flesh out some more concepts and ideas that will support this main goal. This entire process can take hours, days, weeks, or longer depending on how the idea comes to you.
From here, get something visible and kinetic. I find that being able to play with the game and get feedback from it is vital in keeping motivation up. I tend to implement visual and sound effects, as well as simple input handling and processing just so something is 'happening' and it feels like a reality rather than a dream.
No matter how your development strategy goes, I cannot emphasize enough that you don't get wrapped up in trying to design and code a game "engine". Every feature that has no visible or tactile effect on the game will offer very little reward. To help offset this with the essential core systems, put up development info on screen. IE FPS, AI variables, and any other text that will help expose that something is there that wasn't before. There is nothing more draining than spending 10 hours coding a system, compiling, and having the exact same experience as before.
I wrote an article several years ago about finding your games soul that you may find of interest here: http://deleter.phatcode.net/index.php?page=articles&a=8
edit: And one more thing that I see mentioned in another post I want to elaborate on. Play games not only while designing your game, but any time you aren't feeling very motivated to work on your own game. I find that playing similar games helps me remember why I want to make my game and helps give me that extra boost I need to keep going.
In addition, you can build up an "inspiration bank" of pictures, videos, music, and sound clips that all contain elements of what you want to put in your game. Any time you need direction, return to these sources to help guide your decisions. This will help keep you motivated and on track.
I usually focus on the UI first. It helps me envision how the game will play. Also I tend to work on easy thinks first so I do not get bogged down in something.
Start with a game concept, set the reason for the game, gameplay, look and feel of the game you want to make.
From there you can start making a features and asset lists so the programmer and artist can at least start working on something, while the designer does some thinking or tweaking the game mechanics.
This way you at least have some code and assets within a few days or weeks to boost morale and kick start your project.
For me, it helps to mentally 'map out' the game idea before starting it. I'll try and figure out the main mechanics, a basic structure of the internal game, maybe some little details about how i want it to work. Then i apply rubber to road, and start work, bending or breaking parts of my mental map where the code needs a different setup. I might write some things down (a backstory, maybe the key features), but at that point the design is usually shifting too much for a document to be useful.
Otherwise, i kinda stall out with it ending up being a faled project early on :/