Rubygame

There are times when I am tempted — so sorely tempted — to break compatibility between Rubygame 2 and Rubygame 3 in a huge way. Wipe the slate clean and rebuild, carrying over only the best ideas from the Old Rubygame. If I were going to do that, here's what the New Rubygame would be like:

• No SDL. Certainly no SDL_mixer or SDL_gfx, which have been great annoyances to me — the former for its flakeyness, and the latter for its lack of a precompiled Windows DLL (which I only care about because it significantly raises the barrier for Windows users to try out Rubygame).
• Instead, OpenGL and OpenAL. Mostly for the robustness and wide cross-platform adoption, but also for the sexy feature factor. "Hardware accelerated" looks good on a résumé.
• Chipmunk integration from the start. "Real-time physics engine" also looks good on a résumé.
• Higher level Sprite and other classes, with more controlled APIs, and a well-defined system for extending them. Plugins preferred over inheritance.
• Hook-based event management.
• No Rect. No Surface. No draw_* methods.
• Instead, shapes — for collision/physics, and for drawing. Drawing styles with attributes for fill and border. Images would be textured quads. Inspired by SVG.
• Total independence from screen resolution. Objects exist and interact in world space, and can be viewed at any size or rotation with no worries about doing rotozooms and storing temporary images.
• Generally, more focus on objects and behavior, and way, way less focus on managing pixels.
• Fully specced, BDD all the way, and clear example games demonstrating how to use each feature.
• Way cooler than Gosu. ; )

So what's stopping me from doing all this awesome stuff? It's not the effort or the time involved — new things like this are interesting and motivating, and it would proceed easily and quickly. And certainly, dropping all the baggage from Rubygame would be liberating and motivating in itself.

The problem is, New Rubygame wouldn't even be remotely compatible with Old Rubygame. The core concepts are fundamentally different. Upgrading old games would practically mean rewriting them. For some games, it wouldn't even be possible to upgrade, because the feature set would be so different. New Rubygame would be a whole different species, a whole different library from Old Rubygame.

So here are the possible roads forward:

1. Continue adapting the current Rubygame, adding new things and deprecating older things, slowly and incrementally progressing towards a better Rubygame.
2. Start over with Rubygame 3 as a whole new creature. Scrap the old library, leave old apps in the dust.
3. Start a new, separate library to implement this new vision. Rubygame continues on its own.

Food for thought.