I'm come to realise that I keep hitting a Catch-22-esque dilema with most of my game projects. Since I innately want to do the project "right", I want to properly design the software architecture, use scripting, have proper tools to aid with content creation etc. The problem is that since I'm new to many aspects of this and completely rusty with the rest, I don't know what makes a good design without practicing it first with a project. This results in a loop of indecision and I usually don't end up implementing anything for fear of it being "wrong". I also end up ballooning up the game design aspects since "if I'm going to spend the time doing it right, might as well make it as good as possible." Inevitable result: project gets put on ice. It's a thoroughly stupid cycle now that I've written it down.
I've tried a number of times to break this cycle only to fail, but I'm bloody-mindedly persistent enough to try again. I've known for a while that the best way for me to learn what I need to learn is to make a few little game. The problem is choosing a game idea that doesn't require too much extra knowledge at once. Most of the ideas I have would be far better done if I had my own content creation tools (map editors etc.) or knowledge of scripting. Or I feel the idea is too good to do as a learning exercise, as I'm bound to screw it up. But to counter that, I don't want to do anything too boring either. It's a real condundrum.
Thus I feel my best option at the moment is to try and choose a really simple game idea to do for the rest of July, while I simultaneously play around with Lua (my scripting language of choice, due to me already owning some books on this) and wxWidgets (my windowing system of choice, for same reasons). The idea has to be something that would not be much better tackled once I've got some familiarity with both Lua and tool development - that means nothing with extensive pregenerated maps, a lot of scriptable events, or a sophisticated interface. I'd also like something that doesn't require a huge amount of difficulty to do; simple A.I., simple art requirements etc., so I can work on the message passing and control systems as a learning exercise.
But coming up with a good simple idea is hard - most of the moderately original ones I have are too complicated or would most likely be no fun. I might have to bite the bullet and do a rehash of a classic gaming idea, so I won't be too upset if I make a pig's ear of the whole thing. If inspiration strikes and I come up with an original idea that I think fits all the criteria and is good enough to do then that's great, but instead of just waiting for that to happen I might as well try a clone in the next few weeks as a learning exercise. But now the question is, which clone?
So far I'm leaning towards one of the following:
- A Tetris variant (not classic Tetris, but maybe Tetris Attack, Super Puzzle Fighter, Dr. Mario etc.): pros: easy to do, fits objectives quite well, cons: done to death, hard to come up with an original variant
- A Pengo variant (not sure how well know this is known these days): pros: nice little arcade game, cons: would like to think of a good way to improve this rather than just make a clone, would possibly be better with a map editor or format (but not that much of an issue with Pengo compared to other tile based maps).
- A Scorched Earth variant: pros: still a lot of fun, cons: real danger of getting too carried away with this one, might be better with scripting
- Some kind of space scrolling shmup, pros: potential for some originality, not much graphics required, already got some ideas, cons: would be better with scripting and especially music synchronication, might be better suited as a second or third game (once I've got up to developing that tech), chance of going overboard on design
Does anyone have any recommenations from these three, or would like to make a suggestion of their own?
As for projects: this may sound a bit extreme, but it worked well for me. Pick three or four projects and commit to failing them. Now, I don't mean you'll promise yourself to not finish - just promise yourself that you'll code yourself into an absolute corner, and when you can't possibly get any more done, then and only then will you shift to the next project. Don't let yourself think about finishing or perfecting it - just commit to failing. Choose projects such that even locking yourself into a corner requires you to learn a few things, and you're all set.
The advantage of this is that it's extremely hard to do. Almost invariably, you'll get far enough and find a way to break out and finish the project - except your standards of "finished" will be radically lower, so you'll actually accomplish it. In the event that you don't finish, you'll have no qualms at all about throwing it out and doing something else. And even if you come out of it with no viable projects to show, that's not important - what's important is that you have plenty of experience. Even better, you probably have experience in how not to do things, which is essential to learning the best ways to do things. (It is true of virtually every single programmer ever that one cannot really appreciate a good system until one has been forced to work on a bad one.)
Just be sure to keep your code - don't delete anything. Then, come back to it periodically over time, and keep looking for new things about it that suck. As long as you can consistently come back and find some new area to critique that you never noticed as "bad" before, you're still improving and learning.