Design and learn by prototyping.
Prototyping I've found to be a great exercise in teaching myself to pump out better code, faster. If only I could find some time to be less tired and motivated to do more than a 1-2 hour burst of coding. Only one project have I ever wrote or actually developed a fleshed out design or layout of the application. My framework has been the only big enough and intricate enough project to make that worth it. Everything else, I just get an idea and once I have time, I sit down and just code until I can see something on the screen. Then hack in all the other ideas I had with it. If it's looking good, I'll go back and clean it up or actually take the time to design it on paper then re code the whole thing.
I still see alot of posts on gamedev that are all along the lines of "What's the best way to do this?". I've come to believe there is never a best way to design and build an application. Sure there maybe a best way to optimize a small operation, such as the best way to sort a list with specific parameters. I'm talking about full fledged applications / games. The best way can only ever be found by coding the project and seeing how your implementation works. Even then, after you've come up with the best way as you see it. Down the road you'll probably think of an even better way to do it as you learn new techniques.
That's why prototyping is so great. It lets you see your design ideas in action. You get to actually see how your code interacts as a whole. I still always find so many flaws in my ideas once I've coded them. There is just way to much an project that you'll never be able to plan for everything, and why would you. All the time you spend designing and just thinking about your game, is time you could spend coding and actually seeing if it works. Believe it or not, even after you've got your design down, once you start coding. You're design is going to start changing constantly to fix flaws you can only find by running the actual application.
Now I'm talking about the average coders projects, not the next "Skyrim", or projects that take on multiple programmers (which i see over done on such small projects in the help wanted so often). Most average projects at best are on the size of a platformer, or top down shooter. I'd even say a single player rts game falls in this category as well. All of these can be thrown together as a prototype with very little pre planning or designing.
*Warning I get rude here*
If you have to spend more than a couple hours fleshing out the basics of what you're trying to create with something this size. You really should ask your self, "Do I know enough to finish this project, let alone in a timely fashion?" If you find yourself perusing the internet for solutions or asking how to implement your concepts on the forums every time you sit down to code. You're probably biting off more than you can chew. There is a huge difference between asking "How do I move a sprite in the direction it's facing?" and "How do I add a technology tree to my RTS project?". I see the later style question, asked alot on the internet. If that is you, you should go back to the basics and work on alot simpler projects until you can come up with solutions to these questions on your own.
*rudeness hopefully over ;)*
Prototyping is also great practice in churning out lot's of code that works. Programming is one of those things that is best learned kinetically, the more you do it, the better you're going to be at it. Code, code, code and code some more. You don't have to prototype a whole game. You want to be prototyping features and ideas. Take for example, the trading card based game I've been working for a while. Everything in it was prototyped by myself, before I ever designed the complete system. This took me through several iterations, were even at one point I ditched the whole idea of using the card mechanics. I prototyped the idea of loading a series of cards as a deck and being able to draw cards into your hand and place them on the game board. I prototyped the interaction of the actual game pieces and how the went from being cards to being an interact able object on the game board. I prototyped the animation system. I eventually even prototyped the idea of using a whole different base engine for the game.
Doing so helped me see how the actual concepts fit together, how they might fit better if I did things different. I got to play the game in different ways and which forms were boring and which were fun to me. I found lots of organizational flaws and the bugs they caused. All of which has helped me put together a far more accurate design of the game. One that so far, I have yet to go to implement something in the design and said "Nope that design sucks, how am I going to fix this without breaking the rest?".
a couple quick vids to demonstrate a little of what I'm talking bout here. Note this game was originally intended to be a blend of tower defense and trading card games.
My first prototype was fleshing out the card system. Loading a deck of cards, and drawing them into your hand then placing them onto the game board.
[media]
[/media]
Shortly after a couple more prototypes I put together one that ditched the cards and used a set selection of towers. This eventually felt boring to me and started realize my brain was just copying another famous tower defense game ;)
[media]
[/media]
The most recent I threw together a version that uses pathing rather than the row based design.
[media]
[/media]
In short what I want to get across to all you beginners, instead of asking how to do make a game. Just start coding the smaller parts of it. then code, code, and code some more till your idea is complete. You can clean the spaghetti mess up later.
Happy coding and have fun... Ill leave you with this
[media]
[/media]
