Rubygame: The Blog

I have two major announcements related to Rubygame:

1. Rubygame 2.4 is now available
2. I’m stepping down from my position as project maintainer

First, the happier news. Rubygame 2.4 is, finally, done. This release contains the much-anticipated event handler system, which allows you to define how your objects respond to events (e.g. keyboard presses, mouse clicks, and even your own custom, gameplay-related events) in a dynamic, object-oriented way. I’m very proud of this system, because it is flexible, extensible, and powerful, yet at the same time easy to use and made of very simple parts.

Rubygame 2.4 also includes a new suite of event classes for keyboard, joystick, and mouse input, and all the other things. They are a full replacement of the older events, and I strongly encourage you to upgrade your games to use them (use EventQueue#enable_new_style_events to do that).

This release also includes a patch to enable key repeat, contributed by Roger Ostrander (atiaxi), and several bug fixes. See the NEWS file for the full details. Downloads for Rubygame 2.4 are available at Rubyforge. Precompiled gems for Windows and Mac are not available as I’m writing this, but I’ll post them at that same spot as they are sent to me. (Hint, hint.)

Now then, the more serious news.

After 4 years of off-and-on work on Rubygame, I have finally decided to step down as project maintainer altogether. From my vantage point, this is long overdue. Anyone reading this blog over the past 8 months can see the reason why I’m stepping down: I just don’t have the time, energy, or motivation to be a reliable maintainer anymore.

So, Rubygame 2.4 will be the last release of Rubygame I make, but I hope not the last release of Rubygame ever. There are plenty of ideas on the ROADMAP, and the Git repository has a lot of code in the dev-3.0.0 and old-3.0.0 branches that could be cleaned up and released.

But the project needs a new maintainer with the time, enthusiasm, and experience to keep it moving forward.

If you’re interested in being that person, please send me an email: jacius at gmail.

It’s time to announce the winners of the RubyWeekend #2 Contest!

Third Place: Mizutoka by jlnr!

Second Place: Cheese Master by elcugo!

First Place: Opposite Islands by ippa!

Congratulations to our winners, and thanks to everyone who competed or voted! It’s no easy task to create a game in 48 hours, but I hope everybody had fun and learned something new!

Here are the full rankings, with a breakdown of the points each game received.

1. Opposite Islands by ippa: 34 points (10 + 7 + 7 + 5 + 5)
2. Cheese Master by elcugo: 28 points (10 + 7 + 4 + 4 + 3)
3. Mizutoka by jlnr: 24 points (10 + 5 + 5 + 2 + 2)
4. DungeonFarmer by Yahivin: 23 points (10 + 10 + 2 + 1 + 0*)
5. Cyber Deathmatch by Venut: 19 points (5 + 4 + 4 + 3 + 3)
6. Solunaria by jacius: 19 points (7 + 7 + 3 + 1 + 1)
7. Playground Wars by kiba and qubodup: 12 points (4 + 3 + 2 + 2 + 1)

* 0 = the voter did not rank the game at all

See you next time!

The RubyWeekend #2 contest period is over, and now it’s time to vote for the winners!

We had seven official entries this time:

• Mizutoka by jlnr
• Cyber Deathmatch by Venut
• Playground Wars by kiba and qubodup
• Opposite Islands by ippa
• DungeonFarmer by Yahivin
• Solunaria by jacius
• Cheese Master by elcugo

We also had a late entry, which you are encouraged to play (even though you can’t vote for it):

• Super StarHawks Gaiden by misspledd

Check out the entries thread for info, screenshots, and downloads, then rank and vote for your favorites!

The theme of the RubyWeekend #2 game contest has just been announced, marking the start of the contest period! If you’re participating, you’ve got 60 hours to work on your game before you have to submit it!

The theme is “Opposites”. Will your game be about fire and ice, or black and white, or big and small… or something else? I expect to see lots of different interpretations on this very abstract theme!

Remember, we’ll be hanging out in #rubygame on the freenode.net IRC network all weekend, and posting in the Contests forum at rubygameforums.com. Drop by and visit us between coding sessions. :)

Good luck to all the contest participants, and don’t forget to have fun!

The second RubyWeekend game creation contest is this weekend! The official rules and time have been posted, and everybody’s gearing up for some programming fun this weekend!

The contest starts at Friday, July 25, 2008 @ 16:00 UTC (find it in your time zone) and ends Monday, July 28, 2008 @ 04:00 UTC (find it in your time zone)! The theme will be announced at the start of the contest period.

We’ll be hanging out in #rubygame on freenode.net all weekend, and posting in the contests forum too. Hope you’ll join us!

The second RubyWeekend Game Contest is almost here! The weekend of July 25 - 27, compete with other Ruby programmers to create a game in 2 days!

A theme will be announced on July 25 at the start of the contest period. Then, create a game based on the theme, working alone or in pairs (2 people). You can use any Ruby library available (Rubygame, Gosu, Shoes, etc.) for your game, as long as your game code is written in Ruby.

For more info as the contest date approaches, or to check out the winning games from RubyWeekend #1, check out the Contests forum on rubygameforums.com:

http://www.rubygameforums.com/viewforum.php?f=10

Hope to see you there on July 25!

- John

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.

The RubyWeekend contest finished up this past Sunday/Monday (timezone depending). We got 7 entries: 4 written in Rubygame, 2 in Gosu, and 1 simple ‘game’ just using the text console!

You’ve still got a few days to try them out and vote for your 3 favorites! There are also screencast videos of all the games in action, and post-mortems from the developers talking about their experience.

• Entry descriptions / downloads
• Videos
• Vote for #1 favorite
• Vote for #2 favorite
• Vote for #3 favorite
• Post-mortems

Despite some organization troubles and short notice, the contest was a lot of fun for all involved. We’ll probably have another contest next month!

I’ve established a Github repository and Lighthouse project for Rubygame:

• Github Repository
• Lighthouse Project

Why the switch?

1. I’ve beheld the tree of Git, and it is beautiful, with many branches. Subversion just doesn’t cut it anymore.
2. Github kicks ass.
3. SourceForge’s issue tracker has never cut it. It’s a user-unfriendly piece of garbage, and always has been.
4. Lighthouse seems to kick ass, too, based on my initial foray.

Assuming this works out, the Subversion repository on Sourceforge will be “frozen” after committing a note to let people know what happened (as well as an announcement by email, naturally). Of course, I have backups of the whole repository in case things turn south later on. The issue trackers will also be closed, after open issues have been moved to

Eventually I’ll be migrating the web site here to rubygame.org. Generally, I’m keen to move away from SourceForge, as I’ve grown weary of their awkward working procedures and increasing commercialization.

A bit of short notice, but we’ve having a small game creation contest starting this Friday, June 13 at 20:00 GMT 16:00 GMT, and lasting until Sunday Monday 04:00 GMT . The contest is called RubyWeekend, as a cheap knock-off of Pygame’s “PyWeek” (just like Rubygame is a cheap knock-off of Pygame, right?). The idea is to promote Ruby as a viable language for writing games, and have a lot of fun doing it.

The contest starts when the theme is announced on Friday – then you have to write a game with that theme before the contest ends on Sunday!

Think it’s impossible to write a game in just 2 days? The key is to come up with a fun and creative idea that won’t take a lot of time to implement. You’ll also have to manage your time well, not letting yourself get stuck on little details, and deciding when (or if) to sleep! It’s a lot of fun, and a huge adrenaline rush!

You’re not limited to only Rubygame – you can use whatever you like, as long your game is written in Ruby. That could be Gosu, Ruby-Opengl, Ruby/SDL, Rails (for a web game), or even just a text game with plain Ruby. It’s up to you.

Even if you can’t dedicate the full weekend to writing a game (especially on short notice, if this is the first you heard about it), you could write a simple little game in an afternoon and evening, just for the fun and experience.

I hope you’ll join us in writing a game with Ruby this weekend!

I’ve decided on the relationship between Rebirth and Rubygame. Or rather, the relationship came naturally, and it seems agreeable, so it’s the direction I’m going to go.

In Rebirth 0.1, the View class wraps around Rubygame’s Screen class with a different API. As you can see in the source, View just sets the screen mode, then stores the Screen as a class variable. (Right now it doesn’t do anything with it, but it will for setting title, etc.)

This arrangement came out of simple laziness – I did the least amount of work to fulfill the specifications of the View class. And it works really well having Rebirth sitting on top of Rubygame. Rebirth can be pure Ruby, and take advantage of Rubygame’s features – opening a screen, loading images, getting events, etc. Features that Rebirth doesn’t need (Rects, Surface blitting, etc.) it can just ignore.

What this means is that Rubygame will continue to develop on its own, and Rebirth will be a new based on top of it. This is good for both libraries, in fact:

1. It keeps my interest and motivation up, because I get to work on something new and fresh.
2. It gives me an excuse to use and improve Rubygame as well, adding new features I need for Rebirth.
3. It won’t interfere with games that are just using Rubygame (no major backwards compatibility breaking).

So, that is the happy news!

Rebirth 0.1 is done. All it can do is open and close the View (equivalent to Screen in Rubygame – in fact, built on top of Screen). So, you probably don’t want or need to download it. It’s immortalized as tag release-0.1 on Github.

0.2 will be done when keyboard events are done. 0.3 will add a Rectangle class, so there will actually be something to see. You can read the ROADMAP to see the rest of the releases that are currently planned (up to 0.8 so far).

I’ve set up a Github project for Rebirth. There’s not a whole lot to see there yet – the bouncy ball game, a partially complete paddle ball game, and some not-implemented specs for event hooks and shapes. But you might be interested to take a look at the style so far.

• Bouncy Ball
• Paddle Ball WIP
• Event hook spec
• Shape spec

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.

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!