Sexy Progress vs Compatibility

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.


Comments

Mitchell submitted a comment on #

I think you should do whatever will be more fun to write. I’d like to help you any way I can.

Denor submitted a comment on #

You’ll probably end up dependent on SDL regardless, however; even with OpenGL you’ll need something to handle input, windowing, etc. For loading textures, unless you’re only going to support .BMP, you’ll probably want SDL_image (though you could just directly use libjpeg, libpng). For text rendering, SDL_TTF (or, again, libttf).

The good news is that (A) you’ve already written wrappers to those, and (B) OpenGL and OpenAL will eliminate the dependency on SDL_gfx and SDL_mixer, respectively.

John Croisant submitted a comment on #

@Denor: You’re right, I’ll probably end up using SDL, for exactly the things you described (windowing, input, image/texture loading). That’s fine with me.

And yes, definitely no SDL_gfx or SDL_mixer. :D

James Jeffers submitted a comment on #

Warning: http://www.joelonsoftware.com/articles/fog0000000069.html

John Croisant submitted a comment on #

@James: Warning noted, but respectfully filed away as “largely inapplicable”, for the following reasons:

  • I’m not trying to recreate the same thing again from scratch. I’m making something different (though in the same genre.)
  • I’m not doing this because the code is hard to read or messy; but because I want to explore another style of API.
  • I’m not rewriting everything. Existing code that fits nicely in the new library will be copied over.
  • I do have the same team: me. And I am more experienced, both in general and with regard to ruby and game development.
  • Rubygame / Rebirth aren’t anywhere near the level of complexity as Netscape. Starting over isn’t as big of an investment.
  • Rather than wasting resources, this move is aimed to renew the most important resource involved: my own motivation.

So, I appreciate the concern, but this situation is rather different. Still, I’ll take to heart the more relevant parts. Thanks. :)

dStulle submitted a comment on #

The first option sounds most fair to me.

But personally I would prefer to make the radical cut, just because I am desperately waiting for rubygame 3.0 and its new features before I start writing my game.

By the way, do you know how many games using rubygame are out there. I’m having a hard time to find those. It would be nice to have a list on the website with all the games like on pygame.org or libsdl.org.

Have something interesting to add to the discussion? Email your thoughtful comments to comments@rubygame.org.