Rubygame: The Blog

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!

Vote for your favorite games before it’s too late!

Rank the games according to your favorites, then send me a forum PM or email! Voting closes tonight, August 1 at 23:59 UTC!

See the voting forum thread for details and a list of the entries.

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.

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!

It’s amazing how much you can get done when you’re not banging your head against Autotest. I made 54 commits today, implementing the RSpec Rake tasks I wrote about earlier, and added 5 event classes, with specs:

• KeyPressed
• KeyReleased
• MousePressed
• MouseReleased
• MouseMoved

(Hrmm, I still need to add documentation. That’ll have to wait until tomorrow.)

As a reminder, version 2.4 will contain an alternative suite of event classes, as well as a new event hook system. The new event classes make obsolete the old ones, which will be removed in 3.0. So far, the new classes are pretty similar to the old ones, and I expect almost all of them to be drop-in replacements for the old classes.

P.S. It has been fun working with Git, practicing my branching and merging, and making small commits. If you want to check out the new event classes, I’m working in the cleverly-named new_event_classes branch. When I’m done with that, I’ll be merging it back into master.

Lighthouse by itself seems nice. Mostly, I like the simplicity and ease of use, but Github’s integration with Lighthouse seemed interesting as well. The idea of closing Lighthouse tickets by putting a special notice in the Git commit log sounds like it might be a vaguely useful feature. (Rather than, say, a useless gimmick.)

But I’m really not a fan of how it floods the Lighthouse project with every single commit I make. There’s a commit log on Github, where I can actually see the diff; why would I want a second, crippled, spammy commit log on Lighthouse?

Unfortunately there doesn’t seem to be any way to disable sending the commit logs while still keeping the ticket-closing, so I’m just going to have to disable Lighthouse integration altogether.

After my frustrating ordeal with Autotest last night, I decided that if Autotest didn’t want to cooperate, I at least needed to set up an easier way to manually run specs for a single file.

This rule allows more convenient access to individual spec files, without the hassle of rake spec SPEC_FILE="spec/foo_spec.rb".

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

require 'spec/rake/spectask'

rule(/spec:.+/) do |t|
  name = t.name.gsub("spec:","")

  path = File.join( File.dirname(__FILE__),'spec','%s_spec.rb'%name )

  if File.exist? path
    Spec::Rake::SpecTask.new(name) do |t|
      t.spec_files = [path]
    end

    puts "\nRunning spec/%s_spec.rb"%[name]

    Rake::Task[name].invoke
  else
    puts "File does not exist: %s"%path
  end

end

It dynamically creates and invokes a SpecTask depending on the task name you give it. For example, if you run rake spec:color, it will run the specs in spec/color_spec.rb. You can run multiple specs (rake spec:color spec:music spec:surface), or even run specs in a subdirectory of spec (rake spec:foo/bar).

For completeness, I also defined a spec:all task which runs all specs. This is pretty simple, but I’ll post it here in case it helps someone:

1
2
3
4
5
6

namespace :spec do
  desc "Run all specs"
  Spec::Rake::SpecTask.new(:all) do |t|
    t.spec_files = FileList['spec/*_spec.rb']
  end
end

Instead of writing specs for the new event system, I’ve just wasted an evening trying to set up Autotest to work with Rubygame’s specs. The challenge is that Rubygame is not laid out in a shallow lib directory like Autotest wants, so I’m trying to help it find out which spec goes which which file.

I’ve read about the dot-autotest file where you can define hooks and mappings to help Autotest out, but I can’t for the life of me get a working mapping. Here’s one I tried:

1
2
3
4
5
6
7

Autotest.add_hook :initialize do |at|

  at.add_mapping( %r%^lib/rubygame/([^/]*)\.rb$% ) {
    at.files_matching %r%^spec/#{$1}_spec\.rb$%
  }

end

I’d expect this to match, for example, lib/rubygame/color.rb – the regexp matches that string, yet the hook is never even run, and I have no idea why. And even when I have a hook that runs (e.g. with the regexp /(.*)/), $1 and the other match variables aren’t set, which vastly limits the usefulness of add_mapping.

Maybe if I spent several of my life digging through the ZenTest source, I could figure out what’s going on. But frankly, I’m fed up with it. It’d be less of a PITA to just manually run the specs, than try to coax Autotest into doing what should be a simple task.