Rubygame: The Blog

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.

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).

Two bits of news about Rubygame and Rebirth today.

First, I laid out some goals / guiding principles for Rebirth. I don’t know if they’re of interest to anyone else, but here they are:

1. Ease of use. It should be natural to express game behavior, without needing to jump through hoops. Use of defaults and constraints to suggest a course of action and reduce the “burden of choice” on developers.

2. Flexibility. Rebirth should be able to handle games of many types and genres; physics or non-physics, action or slow-paced.

3. Object-oriented. It should focus on game objects and how they behave and interact, not on the mechanics of image blitting and event management.

4. Examples. Plenty of running example games to help users get started and see how the library can / should be used.

5. Documentation. Every module, every class, every method documented, plus tutorials with examples about various important concepts and features.

6. Behavior-driven development. Spec first, then implement. Full spec coverage, master branch is always green.

7. Small, incremental releases. Every feature should be a release, very release should add or refine a feature. Avoid build-ups.

These goals (especially 3, 4, 6, and 7) reflect what I consider to be Rubygame’s shortcomings.

Second, it’s becoming more clear that Rebirth could be just a layer on top of Rubygame and ruby-opengl. In fact, that’s just what I did last summer, in the original Rubygame 3.0 branch. Really, the work I’m doing now is just another refinement of the ideas that I was thinking last summer. (There’s probably some good code I can lift from that branch.) So, it might be that Rebirth will be an add-on to Rubygame, rather than a replacement.

There’s also the possibility of incremental revisions to Rubygame to bring it closer to my goals with Rebirth. The problem there is that it’s a slow process, and that carries the risk of losing interest. It would also lack the freedom to make radical changes that you get with something new.

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