As I'm getting closer to turning Project Jumper into an actual game, it's time to start putting some levels together. It got me thinking about the logistics of level design, and when you should get started on the process. For Jumper, I've put it off as long as I can, because I (intentionally) haven't really had any direction in mind as I make this game. If I include doors, teleporters, and spikes in the level, then I'm committing myself to those things. On the other hand, if I just throw together game elements as I think of them, I can slap them down willy-nilly onto the test map just to demonstrate them, but it doesn't really make for a good game level.
I suppose in a real project, the ideal solution would be to do all your planning first, so that it doesn't really matter what order you do things, you're always following the script. The thing is, that's not really practical for a solo project where you're not even entirely sure what you'll be able to execute successfully. It would suck to design 10 large levels that rely on a rope swinging gimmick, only to find out that you're not going to be able to make a satisfying rope. Or whatever.
On the other hand, if you DO make the levels ahead of time, it gives you direction in your coding. You already know what your game has to be able to do, it's just a matter of implementing it all. I think this is probably the best way to go once you've got some confidence in your ability.
There is a third option that occurs to me, though, and I just might end up implementing this for Jumper. Make small levels as you need them, each one implementing whatever new mechanics you've come up with since the last one. At least in Jumper's case, this could let me keep bolting things on indefinitely, or at least until the program just collapses under its own weight.
No comments:
Post a Comment