Getting Started and Getting Things Done
Most of my games aren’t amazing. Most of my games aren’t revolutionary. Most of my games don’t get lots of press. What my games do get is done. Now and again I’ll get a tweet that asks how I produce stuff quickly - is massages my ego a great deal. So, here’s a few suggestions that I try to follow and I’ve found it helps me get things done.
- Focus - don’t keep changing your mind. When you’re starting out the choice of language, tool, framework or engine doesn’t really matter that much. They all teach basically the same thing and they all have communities to get involved with. Choose one, GameMaker, Unity, Java, XNA, Flixel. It doesn’t really matter but stick with it. Don’t get tempted to change when you get stuck. All that happens is you waste time and get stuck again when you reach that point in.
- Persistence - you’re going to get stuck. You’re going find it frustrating and it’s going to seem impossible. Given time you will make it through. Don’t give up because it’s hard even though you may well want to throw the computer at the wall by the end of it. Take a break, step back and then come back and beat it. It’s all part of development and it’ll always be there.
- Start Small - and work up. If you try to take on a 3D multiplayer physics based game with distributed AI processing as your first game you’re likely to fail - quickly. It doesn’t have to be stupidly small but try to stick to one thing at a time. Simple 2D fun games are a great way to start (and continue if you’re me).
- Ask for Help - you’re going to want to ask for help, but you need to be careful how you do it. Most experienced developers in the communities related to the technology are willing to help out. However, you need to be polite. You need to listen and take the time to try and understand the answers. Most important, don’t expect an answer. Everyone is busy. Everyone has limited time. If you get an answer great, if you don’t then go back to step 2. Keep trying to fix it yourself, post your progress. People are more willing to help someone that is trying to help themselves. DO NOT get angry and shout and stamp your little feet about people not using their time to sort out your issues.
- Be Proud - show other people what you do finish. Always be proud of anything you achieve. It may not look like much to you but other people may find it interesting. Get your stuff out there on twitter, tubmlr, facebook (if you have to). Get it on the forums and get screenshots of what you’re doing visible. Every time you achieve something you should be massively proud of yourself. Every time you get a game running, get people to try it, the feedback will probably help you grow as a game builder more than anything else.
Getting Things Done
- Don’t Obsess - your code is your code and I know you love it but how beautifully shaped and how wonderful the architecture is doesn’t matter one bit to the end player, especially if the game doesn’t ever get to be playable. Do not obsess about your code. Make it work. Make it quick enough. Make it pretty. In that order. If you don’t have a lot of time you can just do the first step and apply the second two once they’re actually needed. The sooner you get a game working, the sooner you’re going to get player feedback and the sooner you’re going to feel motivated to keep working.
- One thing working, is better than 100 half working - get something working as soon as possible. Even if it’s as simple as your guy walks left and right. The sooner you can see something, the sooner you’re feel the game and know whats needed. If you try and build the game on many fronts at the same time, apart from lacking motivation, you’re going to get confused quickly. Not to mention not being able to know whether anything integrates well until the last moment.
- More than one way to skin a cat - there are many ways of approaching any problem in software. There are normally a set of “right” ways that are well explained in long tutorials on the web. You don’t have to do it the “right” way. Take collision, you go off and read the tutorials and you start implementing the perfect way that covers every possible collision response that any game could ever need. It’s hard and it gets buggy quick. You’re not entirely sure you understand what you’re doing, but you just keep going. WAIT! STOP! In your game the collision is much more simple, you just need one type of detection and one type of response. How about you just code it the “wrong” way for now, just make it work and if it doesn’t feel right later replace it. At least it’ll be playable and you can move on instead of getting bogged down.
- Libraries and Middle-ware - nearly every problem you come across there will be a library that can do the work for you. Be careful! Dependencies and the bugs inside them are a big time sink. If you don’t need to use a library, don’t. If you’re not sure it’s going to save you time, don’t use it. That doesn’t mean never use any 3rd party code, just be sure you know why you’re using it.
- Have a plan - a simple changeable one. I keep a text file with a list of TODOs in. Sometimes I even add categories like Bugs, Game, Infrastructure. Keep a list of everything you need to do and cross it off as you go, it’s a nice sense of achievement but it also keeps you focused. However, don’t overcook, you don’t need a big tracking framework and you want it to be changeable in a second. You’re coding away, you think of something, you stick it in the plan and keep going on what you’re doing.
- Get Involved - talking to your peers, showing your work and getting feedback is key to staying motivated and keeping progress flowing. Helping out new developers, writing down how you’ve achieved stuff and building a network of developer colleagues can also be very rewarding, not mentioning as serving as a rest break between coding sessions. You never know who you might meet and end up teaming up with!
Well that’s it really, hopefully it’s a useful list for someone. It at least gives me something to post to people asking :)