Rubygame: The Blog

Schedules are nice. You’d think I would have already figured this out, but having a schedule / weekly planner is quite good for making sure you actually put some time into the things you need to do. Like, say, working on Rubygame.

I have been occupied as always, but I’m learning to manage it and keep a regular schedule, and I’ve fit in a 2-hour slot for working on Rubygame every Saturday afternoon. I might pop into IRC now and again during that time, but I want most of it to go towards getting stuff done, and using IRC pretty much kills productivity entirely.

Hopefully this will mean that Rubygame keeps rolling along, slowly but surely.

Deadlines and work-related stress continue to stomp on my head. I have very little energy / motivation left for anything else, lately.

What’s that? Go cry, emo kid, you say? You’re right, enough of my whining.

Two things are becoming increasingly clear:

1. I really need to figure out a way to reduce the work stress, and have more motivation for other things.
2. Rubygame’s development model is very fragile.

#1 is not very interesting to you, so I’ll talk about #2.

Rubygame’s development model is fragile, for the simple reason that I’m the only “active” Rubygame developer. This has been true for most of Rubygame’s lifetime, aside from brief periods where some developer would come along for a while, then wander off.

And given the amount of time I’ve been able to put into Rubygame lately, calling me an “active” developer is stretching the word quite a bit. Really, there aren’t any active Rubygame developers. Nobody’s actively working on it. It’s just sitting there. (Sadly, this too has been true for most of Rubygame’s lifetime, aside from brief bursts of productivity.)

Clearly, that’s a problem. The obvious solution is to get more people involved, so that even when I’m busy, Rubygame doesn’t stagnate.

How would somebody get involved? Maybe like this:

1. Choose an open ticket that you think you could handle. Or something new. Whatever floats your boat. I’m not picky, I just want to keep Rubygame active and relevant.
2. Create a fork of Rubygame on Github.
3. Do the work in your fork.
4. Send me a pull request.
5. I’ll pull the changes, and if it looks good, merge them into the “official” Rubygame and close the ticket.

The nice thing about that system is that you don’t have to dedicate yourself to Rubygame if you don’t want to. Yeah, it would be really nice to have a dozen developers making weekly contributions to Rubygame, but not everybody has the time for that. The system would work fine even if you only make one contribution to Rubygame.

Anyway, that’s my idea. If it still seems sane in the morning, I’ll see if I can write up a call for developers and go fishing.

Alas, crunch time at work and other obligations have meant little to no time for either Rubygame or Rebirth the past few weeks. I’m hoping to get back into it tomorrow, since we just got past a deadline today and things will be winding down for a while.

A few noteworthy items:

• I’m maneuvering to have the forums from rubygameforums.com moved to forums.rubygame.org. Partly for my own nefarious purposes (Muahaha!), but mostly because the hosting provider for RGF.com is somewhat flakey, and Venut (who set it up) seems to be MIA these days. I’m hoping to get a DB dump from him so the existing posts won’t be lost, but it has been almost a week since I contacted him about that… we’ll see.

• Also as part of my evil master plan, I’ll be moving the rubygame web site from rubygame.sourceforge.net here to rubygame.org. It’s rather due for an update, as well.

• I’ve announced the date for the RubyWeekend #2 contest. It will be the weekend of July 25. I’ll post more about it as that date approaches.

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.

Is it a bird? A plane? No, it’s a new blog at a new domain!

Yes indeed, Rubygame now has its own domain – rubygame.org – and a shiny new blog to go with it, powered by the spiffy Mephisto app. All the Rubygame-related posts have been migrated over here from their previous location at my personal blog. (Although, there were some posts that have both Rubygame and non-Rubygame related topics, which I decided case-by-case which blog to put them on.)

In addition to the blog, I’ll be putting up docs, downloads, etc. soon. In fact, the RDoc-generated docs are already up. Eventually, I’m hoping to set up a better documentation system – I’ve been working on a Rails app for that, when I have the time.

Anyway, welcome to rubygame.org!

In recent months, I’ve been getting several emails a week from users asking if it’s possible to use Rubygame with Rails. While I was originally skeptical about how Rubygame could be useful inside a web framework, I gave it some serious consideration, and decided there was some significant potential there. (Namely, the potential to piggyback on the success of Rails.)

Working on the side for the past month, and particularly this past week or so, I’ve managed to make significant progress on the next generation of Rubygame: Rubygame on Rails.

(click for a larger version)

Rubygame on Rails is a plugin to extend the functionality of Rails, allowing users to create Rubygame applications that run entirely in the web browser. RGoR reimplements nearly the full Rubygame API using 100% javascript and W3C-valid HTML with embedded SVG.

Unfortunately, web browsers have some limitations that I haven’t been able to work around yet.

Due to the varying rendering implementations of web standards, RGoR applications sometimes look dramatically different on different operating systems and browsers. Due to severe issues in this regard, I was forced to drop support for IE entirely. However, I don’t foresee this as a problem, since the demand for games on the Windows operating systems has traditionally been fairly low.

Other caveats:

• RGoR apps may be vulnerable to certain types of XSS (cross-site scripting) attacks.
• Performance in the browser is somewhat reduced from performance with SDL, by a factor of up to 12,000x in some cases.
• Currently, the only audio support in RGoR is playing MIDI versions of 1990’s pop songs.

However, I hope to fix these and other issues in future releases.

I still need to clean up a little bit of the code and package it up, but expect a release candidate for Rubygame on Rails within the next week!