by Gary Gorski » Mon May 01, 2006 1:14 pm
Well, the best advice I have is to program. Remember, the first attempt I had at making a game turned into something that ended up in the scrap heap. It's not hard to design a game - anyone with some creativity can do that in a notebook. The hard part is being able to take what you envision and turn it into what happens through the code. If you can make yourself learn and stick with it there's no reason why you can't learn how to make a game.
One other thing that was helpful was to look for small victories the first time around. I knew what I was doing back then wasn't probably very good so I was willing to accept that all the work I was doing might end up just as a learning experience which it did. I remember how excited I was when I got the code to program a jump ball. Yeah, that sounds dumb and now progamming a jump ball is simply one of a thousand tasks on my to do list for a basketball game but when I was first learning it was really cool to see the code actually do something and because I saw small victories like that along the way I was able to keep at it.
For someone doing what I do now that's a terrible way to go about it. The right way is to plan out the entire design and then work through it in a very organized fashion but for someone first starting out I say just dive right in and make it do something because otherwise you will get bored and quit. You'll be doing it in a way that is less than optimal and probably the least efficient way of doing something but at least you'll gain the confidence that you can do it and that's really the most important thing IMO because coding a game is a long haul with many frustrations along the way and until you actually prove to yourself that you can make parts of your game happen with your code then its really hard to work through those tough spots which usually are the reason why the people who do not follow through with their projects end up quitting.