Rubygame: Rebirth

I'm going to try an experiment. A clean slate, a new project, a new library. Shrugging off the baggage and legacy of the Old Rubygame, and starting fresh, as I talked about in the previous post.

I'm going to design a new library from scratch, applying what I've learned from the first attempt, but with no thought to compatibility. I'm dubbing the project Rubygame: Rebirth. Rather melodramatic, but it hits the right chord.

I'm going to tinker in a local git repository for a week or so, and then decide the future of the experiment. If it feels right, I'll put it up on Github, and take it from there. If it pans out, I'll trash it.

Here's the 'plan':

First, I'm going to write some simple games with the library, before it even exists. Each game will have a different complexity level. At the low end would be something as simple as Pong. At the high end would be a run-and-jump platformer with physics, textures, and sound effects. Obviously, none of the games will run at this point, but they'll be the sandbox for designing an API that I would want to use.

Once I have a few games written, I'm going to extract the core API requirements from those games, and express them as specs. Again, they won't pass (they'll be "not implemented"), but they'll be a more formal definition of the API-to-be. The API will be categorized by the complexity of the game that requires it, and mapped out as milestones to guide development, with the simplest things first, and the most complex things last. The games and specs will also act as progress indicators — as the library becomes more complete, the games will start to run, and the specs will start to be green-able.

Each new feature would correspond to a milestone, and each milestone would mean a new release. The first release would come when the simplest game (Pong or whatnot) ran successfully. Every new feature would be another release. Some releases would also have a new game that began to run due to the latest feature addition. Bug fixes wouldn't get their own releases, but just wait until the next feature.

And of course, all of these plans would be subject to change. I know myself too well to think that I can predict how this project will go. Things change, ideas change, people change. Nothing would be carved in stone, just sketched out in pencil as a guide.

I have no idea if anybody will care, or branch it and make changes. The plan doesn't depend on it, but it does allow for it — by laying out the draft API from early on, other people might help fill in the blanks. I'm not getting my hopes up, though.

What will come of this experiment? I certainly can't predict. At worst, it's a false start, and I trash it within a week. At best, it's the future of a new, reborn Rubygame.

Insert dramatic music here.


Edwin submitted a comment on #

Very interesting indeed. If this “reborn” Rubygame implements some of the concepts you have been discussing over the last few months (particularly event hooks), I think it will make for a more Ruby-esque experience. I like the current Rubygame, but I think that it lacks what Gosu has in examples and documentation.

Denor submitted a comment on #

I’ll second that it sounds cool, and it seems like you’ll be able to get a lot of what you wanted done without the baggage of the old rubygame.

That does leave me wondering what’ll happen to the current Rubygame 3, though. My game’s pretty heavily dependent on it. Will it continue as a side project, or is this the new face of the Rubygame?

I don’t mind, so much, I already rewrote a lot of the engine once when I moved from Rubygame 2.2 to Rubygame 3, it wouldn’t be a terrible pain to migrate to Rubygame 3000, but I’d like a heads up so I don’t get too used to things the way they are now :)

sparkymat submitted a comment on #

Same concern here. :) had migrated to Rubygame 3 some time back. Will it be obsoleted by RgR before its done

Have something interesting to add to the discussion? Email your thoughtful comments to