Rubygame: The Blog - Home

Rubygame 2.4 released; Project seeking new maintainer

2008-10-25T03:20:00Z

I have two major announcements related to Rubygame:

Rubygame 2.4 is now available
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.

Status Update (October 24)

2008-10-24T23:42:00Z

I’ve finished the massive cleanup of the panda demo. I moved all the random shape drawing to another demo (demo_draw.rb), and turned the panda demo into a pretty good example of game structure. It has a Game class which organizes the clock, screen, sprites, event queue and handler, etc. The Game, the sprites, and the sprite group all use HasEventHandler, and nearly everything is event-based, even updating and redrawing the sprites! Plus everything’s commented to explain it, so it might actually be a pretty useful practical example.

I also decided to partially revert my simplification of MethodAction from the other day. Specifically, I added back in the behavior of calling the method first with the event as the argument, and then if that fails (raises ArgumentError), tries again with no argument. So, it’s less picky about whether the method takes an argument or not, which makes it easier to use, and reduces the number of confusing errors people will see. All good things.

Rubygame 2.4 will be released later tonight. I’m cleaning up, updating the NEWS and ROAPMAP, and other stuff right now in preparation to package it up!

Status Update (October 23)

2008-10-24T07:04:00Z

Worked on porting the infamous panda demo to use the new event classes and handler system. I’m also cleaning it up and doing some reorganization and documentation of it – about time, too! I don’t think that demo has even seen a proper cleanup in 3 years.

I also made a few changes to the API as I was working on the demo:

First, I renamed AllTrigger to AndTrigger and AnyTrigger to OrTrigger. “And” and “Or” just feel more natural to me. I actually wrote AndTrigger instinctively while coding the demo, before I remembered that it wasn’t called that. “And” and “Or” are more familiar logical concepts, too: “This trigger and that trigger match the event”, or “This trigger or that trigger matches the event.” So, they should be memorable.

Second, HasEventHandler no longer needs to be initialized; that means, no need for super() in your #initialize method. Before I made the change, I ran into a mysterious “nil has no method” error while coding the demo, because I forgot to initialize it. Well, having to explicitly initialize it is just silly and leads to errors like I myself ran into. So, now it initializes itself the first time it needs to.

The mechanism for that is simple. For example:

def handle( event )
  @event_handler.handle( event )
rescue NoMethodError
  @event_handler = EventHandler.new() if @event_handler.nil?
  retry
end

Anyway, I’m still planning to release the new version tomorrow. There will also be another important announcement tomorrow.

Status Update (October 21)

2008-10-21T23:17:00Z

Finished the 3 things I mentioned yesterday:

Added _make_magic_action and _make_magic_trigger to HasEventHandler. I moved the conversion behavior from magic_hooks to those methods, now you can use method overriding and inheritance to add custom conversion rules. (Oh, and I also renamed magic_hooks to make_magic_hooks.)
Put actions in EventActions, and triggers in EventTriggers. Added docs describing how to write your own action or trigger classes.
Simplified MethodAction. No more pass_event (it always passes), and no more rescuing ArgumentError, either.

I also merged the event_handler git branch into the dev-2.4 branch, and updated the NEWS file.

I’ll have to look everything over, but I think it’s done. I might do some extra fiddling around between now and the 24th, but I think I could release it as-is now.

Status Update (October 20)

2008-10-21T06:14:00Z

Finished the last two things on my list:

Specs for the mouse event triggers.
Add Joystick.activate_all and Joystick.deactivate_all.

But I thought up more stuff to add to the list:

Add _magic_trigger and _magic_action methods to HasEventHandler. These would be private methods that you can override to define your own custom “magic” conversion rules when using magic_hook. They would take precedence over the built-in rules, if there was a match.
Organize the trigger and action classes to be inside EventTriggers and EventActions modules, for obsessive cleanliness and so I can have a good place for documentation about making your own triggers and actions.
Change MethodAction to remove its pass_event argument. Just always try to pass the event, and if that fails try again without it. No need for pass_event (besides, I can add it back later if needed, but I can’t take it away after release or it would break compatiblity).

Also, I’ve set a deadline / release date for version 2.4: October 24, because the timing is right, and it has a 2 and 4 in it!

Status Update (October 19)

2008-10-20T03:02:00Z

Well, ”tomorrow” didn’t quite turn out, but I’ve got atiaxi’s ACTIVEEVENT fix merged in. Although he might want to read up a bit on the effects and uses of bitwise AND (“&”) versus bitwise OR (“|”). ;-)

My next step was to revamp the function so that it could possibly return multiple Rubygame events from a single SDL_ACTIVEEVENT. That wasn’t much trouble at all, and the results are now pushed to the dev-2.4 branch on github.

Here are the remaining to-dos for the Rubygame 2.4 release:

Specs for the mouse event triggers
Making joysticks enabled automatically (?)

I’m not sure about the joysticks thing, though. That would start sending joystick events to the event queue without any Joystick instances having been created, which could be an unexpected change in behavior. So, it might be something to consider for 3.0, but not for 2.4.

I could add Joystick.activate_all and deactivate_all (or some other similar named methods) to make it easier to activate the joysticks, though. Hrmm, I’ll think about it. Leave a comment if you’ve got thoughts about that.

Status Update (October 16, again)

2008-10-17T01:57:00Z

Added docs for the event actions, and also finally merged in atiaxi’s fix for Ftor.new_from_to.

I’ll merge his ACTIVEEVENT fix tomorrow, although I’m going to make so it can return multiple events, instead of just returning the first match.

Status Update (October 16)

2008-10-16T08:43:00Z

Even with the reduced number of commitments, I’ve been busy as always. Actually, I have a tendency to make new commitments, and a little side project distracted me this past week.

But, I made some progress tonight. I’ve finished specs for HasEventHandler #magic_hooks, and also made so you can pass already-made trigger or actions to it, as I mentioned last time.

I’ll have to look around some more to be sure, but I think all that’s left is:

Specs for the mouse event triggers
Docs for the event actions
Making joystick support enabled automatically
Maybe test that the new joystick events actually work. (I wonder if I have a working joystick somewhere?)

An October release still looks certain.

Status Update (October 5)

2008-10-06T01:55:00Z

EventHandler specs are done. I also added a couple methods (#has_hook?, #remove_hook) that were conspicuously missing. Pushed everything to Github.

Realized I haven’t specced HasEventHandler. Not sure I will. Maybe #magic_hooks.

Speaking of magic hooks, I need to make so you can pass it trigger or action instances.

Another status update

2008-10-01T05:05:00Z

It has been a while since my last post, so I figured I had better make a post to show I’m still alive!

I’m making progress on the documentation and specs for the event system.:

EventHook is fully specced and documented.
All of the event triggers are documented. All except the mouse ones are specced.
The event actions are specced, but not documented yet.
EventHandler is fully documented, and I’ve just started on the specs.

Hopefully development should pick up a little bit now, because I have freed up some stressful and time-consuming commitments recently. No set date for release of 2.4, of course, but I’d be very surprised if it wasn’t in October. I’m eager to get this update released soon!

Status update

2008-09-12T01:41:00Z

I just wanted to make a quick post about where Rubygame is now.

I finished the changes I mentioned last time about :left_shift and :right_shift being matched by :shift for keyboard triggers. Here’s how I wrote the code, if you’re curious:



# @mods is the array of modifiers for the trigger.
# evmods is the array of modifiers for the event.

def _mods_match?( evmods )
  @mods.all? { |mod|
    case mod
    when :alt, :ctrl, :meta, :shift
      evmods.include?("left_#{mod}".intern) or
        evmods.include?("right_#{mod}".intern)
    else
      evmods.include?(mod)
    end
  }
end

In addition to supporting general modifiers (vs left/right specific), this code is a lot more forgiving than before. Originally, I had just checked evmods == @mods, which was rather stupid of me, because [:shift, :ctrl] == [:ctrl, :shift] would fail, even though they are equivalent in this context.

All the work that remains for 2.4 is writing documentation and specs for the event actions, event hook, and the HasEventHandler mixin. Unfortunately, that’s not the kind of work that motivates me to take time out of my day to finish it. I’ve got the 2 hours per week scheduled, but I may need to increase that and push hard until 2.4 is done.

Keyboard Triggers

2008-09-06T04:37:00Z

Just posting a reminder to myself to improve keyboard triggers to be better about modifier keys. Right now you have to specify (as one example) either :left_shift or :right_shift, but there’s no way to say “I don’t care which shift it is, as long as shift is being pressed. So I need to make it able to take :shift and have that match either the right or left versions. The same applies for ctrl, alt, etc. (I was writing the documentation for KeyPressTrigger, and I noticed I couldn’t write an example of a trigger that matches Ctrl+Shift+A, without caring about left/right, without using two triggers nested in an AnyTrigger.)

I also want to improve magic hooks so that you can specify “Ctrl+Shift+A” and it will translate that into KeyPressTrigger.new( :a, [:ctrl, :shift] ). Because that would be really handy. But maybe that can wait until after 2.4? Dunno.

Update: Finished the docs for the event triggers, and pushed them to Github in the event_handler branch.

Schedules

2008-08-30T20:07:00Z

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.

RubyWeekend #2 Results

2008-08-06T07:18:00Z

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.

Opposite Islands by ippa: 34 points (10 + 7 + 7 + 5 + 5)
Cheese Master by elcugo: 28 points (10 + 7 + 4 + 4 + 3)
Mizutoka by jlnr: 24 points (10 + 5 + 5 + 2 + 2)
DungeonFarmer by Yahivin: 23 points (10 + 10 + 2 + 1 + 0*)
Cyber Deathmatch by Venut: 19 points (5 + 4 + 4 + 3 + 3)
Solunaria by jacius: 19 points (7 + 7 + 3 + 1 + 1)
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!

RubyWeekend #2 Voting Ends Tonight!

2008-08-01T20:23:00Z

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.