Droplet Post-Mortem

This is a look back at last weekend's RubyWeekend #3 game contest and the process of developing my entry, Droplet.

What went right:

What went wrong:

What I learned:

What I would do differently:

On working with Gamebox:

Gamebox is interesting, and much more mature than its version number (0.0.6 as of this writing) might lead you to believe. The game contest helped flush out several bugs and shortcomings, but Shawn has been super-fast to fix them. I'm sure it will polish up very nicely as he gets feedback from more people.

In general, I am wary of frameworks. Certainly, Rails puts a bad taste in my mouth these days (despite my positive initial reactions two years ago). I tend to find frameworks restrictive, and would much rather be handed a set of building blocks to assemble. For one thing, a framework makes assumptions about what shape I want the final result to have. And I find that many frameworks assume more than they should, and make it too difficult to do things the framework creator didn't anticipate.

Gamebox suffers from this a little bit, but not nearly as much as Rails does. This is evidenced by the fact that even an unorthodox game like Droplet could be made with it. For instance, a more rigid flamework would not have been able to handle the game objects being arranged radially or having no set appearance. There were some things that I had to work around, though:

There were a few other things that felt like work-arounds to me, but which I think I could have done better if I were more familiar with Gamebox, especially its Behaviors system.

Would I use Gamebox again? Sure! Especially for more conventional games, Gamebox is a great way to get a head start on your game. Even weird stuff like Droplet can be accomodated without a great deal of trouble. And at the rate Shawn is improving it, I'm certain Gamebox will soon be one of the most kickass game frameworks around.

… at least until Rebirth comes out. >;)

Previous post: Droplet Next post: Nice-FFI 0.1