Growing a Game Organically: Water Frequently

I forget why the idea popped into my head, but I remember it popped loudly. In the unforgiveable amount of time that has passed since my last on-topic post, I've been thinking a lot about how to begin this project's implementation. I am wholly dissatisfied with the idea of designing the entire thing first and then implementing it -- I need to write some code and get at least one triangle displayed on my ridiculously fast video card.

Today I'm going to load up on Diet Sprite and finish the series of webcasts that I began a while back. It should take several hours, but I have little else to do this weekend before flying out to LA for PDC '05.

Oh right... the thought. So I'm thinking to myself that one approach to starting some code would be to design the entire game first (or the first version of it, anyway) then hack my way through it, meeting any and all requirements I set out for myself in a checklist fashion. Or, thought I, I could just let this be a hobby instead of a deadline-oriented project. I could instead make small pieces in a logical progression, and let the game grow organically.

The order in which things are done would be important, and even more important would be the coding style that produces very modular building blocks. Much like I assume God or whoever built the universe, I'd have to start with the most atomic piece I can think of, and then build on that, and build some more, and build more depending on what is needed (according to me). First task might be to create a simple tile: a 3D block that represents a unit of space in the game. With an almost Platonic concept of a tile form, I've produced something useful without having lost the freedom to change course. Then I might augment that with decorations or behaviors. Then maybe inanimate objects within tiles. Then maybe some physics to govern how those objects behave. With a tile model (and its constituent parts) in place, I could build a tile grid. With a tile grid full of tiles, I can begin adding random generation to the mix, making sure to compartmentalize that functionality such that it can be upgraded in the future without affecting the rest of the engine as it evolves.

To some I'm sure this seems obvious. But it hit me like a ton of bricks, as I'm usually a very process-oriented (and deadline-oriented) person -- have something usable at every step in case someone schedules a demo for the next day without telling you until the next day. But this new job is doing wonders for my problem-solving and learning skills -- I can see that I can combine play with process.

It's like Legos, if Legos were run through a multi-stage graphics pipeline.

Time to get started.