Rubygame: The Blog

Slowly but surely, I’m working towards Rubygame 2.4.

As a reminder, 2.4 is going to be about events. In particular, a new Events module with a suite of SDL-based event classes to replace the old event classes.

The reason for this is to clean up the API; all the events are tucked away in their own cozy little module instead of cluttering up the Rubygame namespace, and they’ve got nicer class names. The documentation and code are also nice and clean, and all the event classes are thoroughly specced. The class interfaces are also more tightly controlled, for example freezing attributes to prevent modification.

The new event classes also do away with the massive list of integer constants (K_ESCAPE, MOUSE_BUTTON_LEFT, etc.) that were cluttering up the code. Instead, they use symbols for key names, mouse buttons, etc. This also makes the code you write a lot nicer to read.

Another nice improvement is that the KeyPressed event now has an attribute with a Unicode string containing the glyph (if any) that was generated by the keypress. This is very nice for text input, for example if you’re programming a GUI.

All the new event classes are finished, written in Ruby. I’m currently implementing the C-side event conversion. The code is much cleaner and nicer to read this time around, let me tell you! (One would hope so, given the years of extra C experience I have under by belt.) After the new classes are in place, I’ll mark the old event classes as deprecated; they’ll be removed entirely in Rubygame 3.

The new event classes are only half of 2.4, though. The other half is the new hook-based event handler system, including the much-anticipated “magic hooks”. The code for that stuff has been complete for a while, but it still needs to be cleaned up, documented, and specced. Once that rolls out, you can kiss your huge case-when blocks goodbye, my friends.

Given how often and suddenly I get swamped with work, predicting a release date for 2.4 is futile. But, I’d say it would take only 3 or 4 more afternoon/evening sessions to get it polished off. Whether that will take a week or two months is impossible to say.

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

I’m pondering Duck Typing tonight as I write event classes and their associated specs.

Here’s an abbreviated spec for the WindowResized event, which holds an [x, y] array with the new size of the window:

1
2
3

it "should reject non-array objects as size" do
    lambda { WindowResized.new( 20 ) }.should raise_error(ArgumentError)
end

Giving the number 20 as the size doesn’t make sense, and you’d run into an error sooner or later. In this case, without any checks, the error would probably show up when you tried to set the Screen mode again to the new size. Because of the delayed effect of the event queue, the backtrace wouldn’t have anything to do with the real problem – that you gave the event an invalid argument.

So, the rationale behind this spec is that the class should complain loudly at the soonest opportunity, so that the location of the error is easy to find.

To make this spec pass, I might write the following:

1
2
3
4
5

# this is not duck typing
unless size.kind_of? Array
    raise ArgumentError, "size has to be an Array"
end
@size = size

The spec would pass, but the code would be pretty inflexible. Suppose someone wrote a Size class which had 2 elements, but wasn’t actually an Array. This check would reject it, even though it might have been usable. A conundrum!

Duck typing to the rescue, right?

After thinking about it for a while, I realized that the size parameter doesn’t have to be an Array per se, it just has to be something that can be converted into an Array before I store it. Since anything that can be converted to an array should have a #to_ary method, I could check that it has that:

1
2
3
4
5

# getting warmer...
unless size.respond_to?( :to_ary )
    raise ArgumentError, "size has to be convertable to an Array"
end
@size = size.to_ary

The spec still passes, and I’m getting more duck-typey. Or at least chicken-typey. We could go a step further:

1
2

# quack, quack!
@size = size.to_ary

Since the goal was just to complain loudly if the argument is invalid, and we’ve decided that an argument is invalid if it can’t be converted to an Array, then we don’t really need to check that it responds to anything. Just try calling the method! If it doesn’t have that method, you’ll get an error, just like you’re supposed to (although we’d have to tweak the spec to expect NoMethodError instead of ArgumentError). If it does have the method, you have a (presumably) valid parameter. So, it’s all good.

It would be even more duck-typey to have no checks at all (and no specs for the checks), and instead just assume that everybody who uses the method has read the docs and knows to pass the right sort of thing. But as I explained earlier, not checking is not a good idea here. (Well, maybe in this specific case it would work out fine, since users wouldn’t usually be creating their own instances of this event. But in general, no.)

So, what’s my point? I don’t have one. I just wrote this as a thought experiment to help me decide what to do. Thanks for listening!

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.