It wasn't actually coincidence, of course; I didn't actually participate in Ludum Dare this time, but knowing that it was coming had me thinking about Gosu again. I just didn't have time this past weekend.

As for the library file, it's been a while so I don't recall, but I'm pretty sure that I used the vanilla gosu gem for that project, not my custom SDL one.

I know this is an old thread, but I felt I should point out that you definitely can distribute a game for windows using rubyallinone even if you don't have a access to a Windows computer. I did exactly that for my (rather terrible) LD-17 entry, and I think a few other projects as well.

The game itself was very bad, but it provided a big lesson in persevering through difficult packaging tasks: I was able, without access to a windows computer, to upload a functioning windows version of my game which used not only Ruby and Gosu, but also Chipmunk through FFI.

As far as I'm aware, there is no reason at all that the copy of rubyallinone.exe that I used (and still have on a thumb drive for ruby development using someone else's computer) shouldn't work for anyone who needs it, so I'll attach it here.

Okay, well, there is one reason: sadly, it's only Ruby 1.8.6, which isn't exactly the new hotness. But it's good when you just need an uninvasive ruby interpreter.

Edit: Incidentally, you'll need to include things like Gosu.dll and fmod.dll in the folder with your files... if you want to see how it looks, you can take a look at my LD17 entry. Just, for the love of god, don't run the game itself, it's very, very bad :-p

It's Princess Mystery Dungeon, my LD20 entry!

Basically, this is a Legend-of-Zelda-clone dungeon exploration game with a twist, that twist being that the dungeons are procedurally generated. Unlike, say, a standard roguelike, however, the game has the zelda staples of locked doors and keys, switches to hit, a dungeon treasure to acquire which is necessary to complete the dungeon, and a boss at the end.

Now, given the time constraints of LD48, there's not a ton of thrilling gameplay here yet; there is only one type of enemy (besides the boss), no story to speak of or audio at all, the 'puzzles' are very weak, and the game simply stops after you beat the boss. However, I have quite a few ideas for expanding the game in the future, after LD voting ends. Anyway, suggestions are welcome!

You're more than welcome to peruse the codebase, but I should warn you that it is incredibly sloppy and spaghetti-style and isn't a good example of how to do anything well except get a game done in 48 hours.

Downloads: Windows - Mac OS X - Source
These links contain a version of the game that is identical to the LD20 submission save for the fixing of two crash-to-desktop bugs and the addition of a prompt to start over after you win. For the original LD20 version and associated information, see the LD20 entry page.

Just throwing a note here in the forums (though obviously Ippa is already aware), I entered as well. My entry was a little Zelda-like using Chingu:  The Legend of Äkätä

Haha, yup, that's me, all alone in the middle of the Pacific :-p

I finally decided I needed some way to unit test my Gosu code. So, I started building Gosu::Mock.

adam-gardners-imac-g5:~/code/other projects/gosu-mock adam$ cat example.rb
require 'test/unit'
require 'gosu_mock'

class GosuMockExample < Test::Unit::TestCase
  class MockWindow < Gosu::Window
    def initialize
      super(200,200,false)
      @image = Gosu::Image.new(self,"picture.png",false)
    end
    def draw
      @image.draw(0,0,0) unless button_down?(5) # I haven't added the constants yet, but they'll come
    end
  end
 
  def test_window_draws_image
    window = MockWindow.new
    window.do_tick
   
    assert_equal "picture.png", window.drawing_events[0].content.filename
  end
 
  def test_window_doesnt_draw_image_when_button_is_pressed
    window = MockWindow.new
    window.user_presses_button(5)
    window.do_tick
   
    assert window.drawing_events.empty?
  end
 
end

adam-gardners-imac-g5:~/code/other projects/gosu-mock adam$ ruby example.rb
Loaded suite example
Started
..
Finished in 0.003881 seconds.

2 tests, 2 assertions, 0 failures, 0 errors, 0 skips
adam-gardners-imac-g5:~/code/other projects/gosu-mock adam$

Note that  Gosu-Mock steps in for Gosu; once you require it, the class your testing just inherits from Gosu::Window like normal, no need for a special 'testing version' of your class.

Gosu mock is *far* from feature complete at this point, but, I only started writing it this morning. You can get the source here, or see a more practical use of the library in my CuteDemos project.

I coded up a random demo to play around with the PlanetCute graphics from LostGarden.com (site sadly down at the moment). Code is here, you'll also need my CellGrid library-in-progress somewhere in your load path.

Loading takes a while because on each new screen it has to procedurally re-figure what belongs on that screen. This applies even if you've been to the screen before. Only the terrain for the current screen is stored in memory. Since the terrain is generated using Perlin noise, which always generates the same result for a given set of input values, the only thing I store in memory for regions other than the one you're in is the set of which tiles you've seen; even that in compacted into a bit string.

Adding to the delay is the fact that my perlin noise generator is a pure-ruby one; there's a readily available one written in C which would have been much faster (probably fast enough I could have been really extravagant and not even stored the current screen in memory, and just called the function as I drew), but I didn't want the headache of cross-compiling it for LD48. Plus, I got to learn about Perlin noise this way.

Explore the boundless reaches of an alien world as an intrepid purple dot of ambiguous origins!

CONTROL a courageous purple dot who is probably a robot, maybe!
EXPLORE procedurally generated planets of curiously infinite size!
GASP IN ASTONISHMENT at a game interface that brings new meaning to the phrase 'pixel graphics'.

Do you dare brave the adventure? Can you afford not to?

---

TLoPD:E1:PDtE was my LD16 entry, on the theme of exploration. I originally wrote it under severe time constraints (more like 10 hours work than 48), and the version posted at the LD site reflects that. However, I've since been making substantial updates to it, and it's looking a lot more like a game rather than a toy now.

Check it out! Note that you should ignore the packaged downloads and just grab the ruby source. You'll need Gosu, of course, and also the gem mixology.

Ask and you shall receive!

I ranked #8 for coolness... but that just means I voted a lot. I otherwise did very poorly, tying for *last place* in Overall. :p

Ah, well, there's always next time.

You can see exactly this method used in OperationLambda:

EmptyImageStub.rb:
module OperationLambda
  module ImageManager
   
    # EmptyImageStub is based on an idea Julian Raschke suggested in #gosu
    # on IRC. It provides empty RMagic::Image-like objects which, when
    # passed to Gosu::Image's constructor, have their to_blob method called,
    # to provide RGBA data. This allows the easy creation of new Gosu::Image
    # objects without accessing the filesystem, which can then be drawn into
    # with TexPlay.
    class EmptyImageStub
      def initialize(w,h)
        @w, @h = w, h;
      end
     
      def to_blob
        "\0" * @w * @h * 4
      end
     
      def rows
        @h
      end
     
      def columns
        @w
      end
    end
  end
end

Usage (from ImageManager class):
def empty(w,h)
  stub = EmptyImageStub.new(w,h)
  return Gosu::Image.new(MainWindow.instance,stub,true)
end

I've taken Scott Lembcke's Chipmunk Demos (which are included with the Chipmunk source), and translated them into Ruby, using Gosu for display (sort of). In their current state, they are uncommented source that doesn't actually do the drawing with Gosu directly, but instead uses only OpenGL (as do the original demos in C). As such, they're pretty good as Chipmunk demos (except for that 'no comments' thing), and do a passable job showing how to do with raw OpenGL what would be better done using Gosu::Image, but they're not exactly Gosu demos in the normal sense. At some point, thoguh, I'll be creating a branch which *does* use Gosu::Image for drawing.

Getting this code to run at all is fairly complex; the most problematic requirement is that you can't just download regular 'release' Chipmunk and use that. Instead, you must use Chipmunk's SVN Trunk, at least until Chipmunk 0.5 is released. You can see the README.txt file for more details (though, not *many* more details).

This is all pretty unpolished at the moment, but I figured it might be useful to someone. Have fun, or at least don't gouge your eyes out after looking at the code!

http://bitbucket.org/philomory/chipmunk-demos-ruby/

> Kind of sad that the singleton lib didn't even check for this very common problem :(

What's more sad is, this is, according to Matz, the correct behavior: http://www.ruby-forum.com/topic/179676

Here's my workaround: OperationLamba/app/MainWindow.rb:31
more here: MainWindow.rb:43 and here: MainWindow.rb:105

Well, you might want to take a look at my ImageManager, Tileset and Tile classes from Operation Lambda, though in my game I didn't pack sprites for different poses or orientations into single files. The only time I load multiple tiles from a single png is when loading animation frames. None-the-less, some of it could be helpful.

ImageManager, Tileset, Tile, my main tileset metadata file.

Here's an example usage, the main draw method in my GameplayMap class:


    def draw
      @background_image.draw(0,0,ZOrder::Stars)
      self.each_with_coords do |obj,x,y|
        xpos = x * Sizes::TileWidth
        ypos = y * Sizes::TileHeight
        @floor_image.draw(xpos,ypos,ZOrder::Floor) unless (obj.noun == 'Space')
        ImageManager.tile(obj.key).frame(obj.frame_fraction,true).draw(xpos,ypos,ZOrder::Things)
        obj.draw_beams(xpos,ypos)
      end
    end


Edit: By all means, please ignore all the font-related code in ImageManager, by the way. Though functional, it is hideous and not a starting point for your own work. I need to change it. The actual image-related code is pretty good, though. At least, it's served me very well.

I should also note (since this hasn't made it into source comments yet) that in the context of Operation Lambda, a 'Tileset' is a complete set of every tile image that is used by the game. This differs from what is probably the normal use of the term, under which you would have a tileset for each entity, such as a player tileset, a tileset for each enemy, etc. In other words, my Tileset class might be more appropriately called a 'theme' or 'skin'.

Anyway, hope this helps.

Edit again: Spelling.

Ok, took long enough, but I've made new packaged binaries for 1.0 alpha 3, now available for download.

You know what would be nice, at least in Ruby? If the Gosu::KbX & GpX & MsX constants were objects rather than fixnums (frankly, *any* class of object other than fixnum or symbol would be good. Even just bare instances of Object with no extra methods or functionality). Why? Because then I could easily monkey-patch individual keys to do things like

def Gosu::KbEnter.==(id)
   return (id == Gosu::KbReturn) || super
end
def Gosu::KbReturn.==(id)
   return (id == Gosu::KbEnter) || super
end

There are more elegant and flexible ways to do this, but this one is shortest. Regardless, none of them are possible with fixnums. I could, as a workaround, use the numbers that gosu already returns as keys into an array or hash which had values corresponding to equivalence classes... hmm. Maybe I should just do that :-p But I still like the non-fixnum-button-objects idea. If you made an actual button class, you could have a method like 'controller' or 'device' that could be used to differentiate between a Gosu::GpUp from one controller vs. the same button on a different controller. Though you'd have to go through some (minor) trickery to get  id == Gosu::KbA to work, since they'd not actually be same object. And you'd have object creation every time a key was pressed.

So, that's all getting pretty complicated, and maybe it isn't the best idea, but it's worth thinking about.

Edit: fixed stoopid

You know, I actually now think that this was a misunderstanding. I went through, did some random searches on github, and none of the projects I turned up had a downloads section, even an empty one. I looked briefly at Github's docs and did not find anything mentioning non-source downloads whatsoever. So I came to the conclusion  that github didn't offer this functionality. Later, I came across a github project that *did* have downloads other than the repository. So either this feature was very recently added, or, more likely, the downloads tab is hidden if there are no packages to download, and further it is poorly documented (or I did a poor job searching the documentation).

Regardless, however, I am quite happy with Mercurial and BitBucket for the time being. If someone wants me to throw the source onto github too, though, I can do that. I can even using the hg-git plugin for mercurial to push to github without installing git :-p

Edit: fixed stoopid

Well, all Mach-O format binaries (executables and dynamically linked libraries, anyway) have a list of dependent libraries, and these include the path. Including the path apparently has security advantages compared to the model Windows uses, but it's a hell of a lot less convenient.

In any case, Ruby-1.8 is pre-installed on OS X, so all users can be relied upon to have it in the exact same setup. Ruby-1.9, on the other hand, is not only not pre-installed; the Ruby folks do not provide a 'standard' installer for it either. So, you *must* compile it from source, or install it via a package management system such as MacPorts or Fink (which will, in turn, compile the source for you).

Different people will choose different options when compiling. The relevant ones are going to be the prefix (the path) and the suffix. For instance, my copy of the ruby-1.9 binary is installed at /usr/local/bin/ruby-1.9, and libruby.dylib is at /usr/local/lib/ruby-1.9.dylib . Julian, on the other hand, installed using MacPorts (last I checked), so his copy is installed in /opt/local/bin/ruby19, etc.

All that said, I seem to recall that there *is* a way around this, since anyone loading these libraries will necessarily have already loaded libruby into memory. I think it involves a feature called 'weak linking'? Julian has played with this some, maybe he can chime in here. Otherwise, I'll start looking into it.

Edit: Also, it occurs to me you probably want a universal ctexplay.bundle; the one I sent you is PowerPC only. I can compile it on an Intel mac later, though, but we may as well solve the linking issue before I bother.

Edit again: On the plus side, the fact that the only way to get ruby-1.9 on a mac is to compile it from source (either yourself or through macports) means that anyone who *has* ruby-1.9 also has, as a matter of necessity, a full compiler suite installed. So really you can probably safely just distribute a 1.8 bundle for mac, and people who want it for 1.9 can do use extconf.rb, which really not that hard. Compiling ruby itself is more complicated, and they already did that.

Okay, both issues are fixed in source, available in the repository. I won't have new binaries built until at least tomorrow, though.

Here you go!

Since I don't think you're copy of ruby-1.9 is configured with the same suffix as mine, and possibly not the same path, you'll want to execute:

install_name_tool -change /usr/local/lib/libruby-1.9.dylib <path to your libruby-1.9.dylib file here> ctexplay.bundle

to change the library embedded load path.

> Level 35 is broken. The red and purple lasers aren't properly reacting with the blue portal.

Oy gevault. Yeah, I see the problem. How it managed to slip by, I don't know, but I'll try and post a fix later today or tomorrow.

EDIT: Created Issue #3 to handle this issue.

The level probably needs *some* more direction than it has now, but, I think one shouldn't underestimate the fun to be had exploring, trying to figure out where to go. It's a balancing act. You need to have just enough hints that the player doesn't get frustrated and give up, but not so many hints that everything is easy and obvious. (Actually, having too many hints isn't as big of a problem as not having enough, but some of my favorite games of all time manage to hit a sweet spot where they have *just* enough hints to help you out when you're completely lost).

(Edit: spelling)

10 points for Maverick!

Also, just to let people know, I uploaded 1.0 alpha 2 today, which should fix the crash-when-you-die-sometimes bug, and the rendering issue Julian pointed out above.

I am indeed baking tiles into a blank background, when I generate the level-preview images. The reason I'm doing it so that I can draw six level previews on the screen at one time without redundantly looping through 6*14*20 = 1,680 tiles per frame. Also, baking them into a single texture makes it a *lot* easier to move whole level-preview-images around the screen without inserting multiple, independently-variable offsets into 1,680 calls to Image#draw (again, every frame).

Edit: Also, I'm beginning to think I should make the game automatically display the help screens the first time you play. Almost *everyone* has missed them. Which just goes to show that no one reads the readme, either ;)

Yeah, reading the in-game help is really important.

The controls are a bit of a problem. I endeavored to make them react pretty much the same way they did in the original game, at least as I experienced it in emulation. But it's a little awkward, and I probably should re-think them. Not to mention, the speed at which you move may need to be tweaked; I haven't looked at it in a while.

One thing that's important to realize is that if you press a direction other than the one you are facing, it takes one full 'move cycle' to turn to face the new direction, before you start moving forward. This is important, because if you couldn't rotate in place, some areas of the game would be impossible; however, it can add to the already existing impression that the controls are slow to respond.

It's also possible that the controls *really* are slow to respond, and I need to tweak 'em.

I actually did think about replacing Gosu::Font with another class that drew bitmap fonts, so I could use the original blocky fonts, complete with original gradients. But I haven't got around to it yet since it seemed that there would be a *whole* lot of edge cases to address, making it fairly complex to implement, and the implementation I can think of off the top of my head would be a *big* performance lose, in a game which already has performance problems. If you have any suggestions, though, I'd be more than happy to hear them!

Ask and ye shall recieve: there are now screenshots.

The game should have full gameplay support, since input is completely customizable and I'm not restricting it to only accepting button_ids that correspond to keyboard buttons. That said, I haven't tested it; did you try it and find it didn't work?

Edit: I'm 27, since you ask :-p

Operation Lambda
Announcing Operation Lambda: a remake of the classic game by Bret Victor. Make your way through a distressed spaceship, rescuing hostages and deflecting lasers in 100 levels!

The remake implements the original (IIgs only) game entirely in Ruby, so anyone can play! It also adds a level editor, swappable tile-sets, and other niceties. It's over 5000 lines of code, and Ohloh informs me it's only 3% comments. Clearly, I am a terrible coder ;). But! I made a game.

Where do I get it?
Operation Lambda is hosted on in my BitBucket repository. It is available as a Windows exe and an OS X app as well!

If there is demand, I'll try to get around to making a git mirror on Github. I picked BitBucket because GitHub wouldn't let me host the downloadable 'binaries'.

What do I need?
If you download the pre-packaged application, you don't need anything other than what's in the zip/dmg. If you're running it from source, you'll need Ruby, Gosu and TexPlay.

Other notes
The original Operation Lambda, and all it's graphics, sounds and level data, are copyright 1996, Bret Victor, and are used with permission. All the code and additional design in this remake are copyright 2009 Adam Gardner.

Operation Lambda is released under the terms of the Artistic License 2.0.

(edit: added screenshots, fixed markup, made it the post shorter and less email-centric (aka fewer linebreaks).)

Screenshots are: Level 1, Level 25, Level 84, the Main Menu, the Level Select screen, and the Level Editor.

I have no idea what it is, but I like it!

Though, you may want to fix your forum markup :/

I really like TexPlay, but I have a problem... the performance of the refresh_cache call you add to the instantiation of images (i.e. Gosu::Image.new(args)) is very, very bad for me. It adds anywhere from 0.5 seconds to nearly 0.9 seconds per image instantiation, and since I load more than a hundred images in my game, all at once, I've had to comment out the call to refresh_cache.

Interestingly, commenting out that call hasn't had any negative effect, so I've not been able to figure out exactly what it was supposed to do in the first place...

Most really good platformers I can think of off the top of my head don't use up for jumping; mainstream titles like the Metroid series, Castlevania series, and Mario Series; indie titles like Cave Story and Braid.

Basically there are a couple of reasons for this. Usually, there is something else more internally consistent for the up button to do, usually the opposite of something done with down. In a game with weaponry, you way use up and down to aim. In a game with ladders, you're probably going to use up and down to climb up and down the ladders. If up is also your jump button, then it's impossible to jump off a ladder.

Making the up button the jump button also makes it harder to steer yourself if you're using a gamepad with a single d-pad which can point in one of four directions (rather than four separate buttons). If you are trying to do, say, a running jump, you are going to be pressing forward on the D-pad. Moving your finger to the up button would usually slow your forward momentum. The same concerns apply to joysticks and analog controllers, though not so much to keyboards.

Frankly, for all but the most casual games, I would recommend at least considering giving the player complete control over the key->action mapping. That's what I'm doing (not that my game is a platformer, but the code of mapping the controls could work the same way). It's a pretty good idea, at least until you reach the level of control complexity of, say, nethack (where you are basically using every single key on the keyboard, both with and without shift, for a separate command).

Interestingly, I'm currently using the following code to get the names of keys, precisely because button_id_to_char() does not function for non-alphanumerics:

#helper hash to get Gosu button constant names
module OperationLambda
  GosuButtonIdNames = {}
 
  module_function
  def build_hash_of_gosu_button_id_names
    (Gosu.constants - ['MsNum',:MsNum]).each do |str|
      x = Gosu.const_get(str)
      if x.is_a? Fixnum
        GosuButtonIdNames[x] = str
      end
    end
  end
end

On the flip side, I actually *am* using char_to_button_id() at the moment, since there's no Gosu::KbLeftBracket and Gosu::KbRightBracket constants (that is, '[' and ']').

I may produce an SDL_mixer based gosu for OS X myself anyway; rather than trying to find an audio format which can be used with both SDL_mixer (windows and linux) and OpenAL (OS X), which I can convert to from .XM without weird audio artifacts, and which will sound the same on all three platforms with both engines. Plus, I don't really need setpitch() myself, anyway.

Note that I'm not trying to suggest that Julian should dump OpenAL and go back to SDL_mixer, just letting people know that if they are interested in SDL_mixer + gosu, I'll probably still be compiling a copy.

I managed to get a copy of gosu compiled for windows with SDL_mixer audio a couple version ago. As I approach the release of my own game, I'll be doing it again with the most recent version of gosu. Keep an eye on this thread for an announcement when it's ready. You can also find, in a post from February 6th, the Windows/SDL gosu for I think version 0.7.11.

Edit: To clarify, that's the thread I'll announce SDL-linked version of Gosu in, not the thread I'll announce my game in.

> Hey
> Thanks for the reply

No problem.

> what project/s are you working on at the moment?

None of my projects are online at the moment, but, I'm wrapping up a Gosu-based game, planning another game in my head (probably won't work on this one for quite a while, though), and I've got an FFI-based wrapper library on the back-burner.

> thanks for the art resources link
> I will check it out :)
>
> do you have any sprites or tiles that could be used?

Just want to make it clear, lostgarden.com is not my website, just a useful one I happened to find. There's not a lot you would use as sprites there (though there is a little). What they have quite a lot of is really excellent tile-based art to build backgrounds out of.

> Talk soon
> Shinobi Chef

- Adam

I can do ruby programming, beta testing, and possibly level and story design; my time, however, is somewhat limited, so I'd be most likely able to contribute usefully as a tester who could, after finding a bug, contribute a patch.

I have enough projects of my own that I probably shouldn't expect to pick up someone else's, but you've got me intrigued. The games you've listed as inspirations are well-loved by me (and many others, of course).

Incidentally, for art resources, you might check out the stuff at lostgarden.com . There's a lot of really high quality stuff there, and although it isn't necessarily intended for a platformer, I imagine some of it could be adapted to one, with some effort.

Actually, the plan is to link the Deployment Package to libruby dynamically rather than statically, but use a tweaked libruby which is itself statically linked to the necessary parts of Standard Lib (syck, stringio, etc). Or, if I can't get that part to work, just dynamically link everything as normal, bite the bullet, tweak the entirety of the standard library with install_name_tool, and include all of it in the deployment bundle, universal-style. It can all be stuck in a separate directory inside the bundle (Contents/lib/ruby/, perhaps).

Basically I want to see which approach ultimately turns out to be the simpler one. The only way to know for sure is to try them both, since I'm sure they each will have surprises waiting for us.

Hey, Julian, if I wanted to download current source to try and play with getting the App package to work the way we want, what revision would you recommend checking out of SVN?

This thread might be useful: http://www.ruby-forum.com/topic/105509

Here's an idea; is there some way to, when building a (native) gem, pass extra flags to the linker? Either with environment variables or the --build-options flag to gem install? I'm not sure if --build-options passes flags to the linker, or only the compiler, and the env variables might be ignored (though they shouldn't be). But if either way works, then people needing to bundle a native gem with their distributed app could be instructed to build it with 'gem install whatever --build-options -weak-lruby'. Worth a shot.

One possibility would be to recompile ruby-1.9 after editing ext/Setup in the source tree to make all the relevant modules (syck, stringio, etc) statically linked into libruby. At least, if I'm reading the docs correctly, that's what I think would happen. I don't really have time to play with that at the moment, though. If you try it and find that it works, then I can try building the universal version for you.

The problem is, though, that only solves the issue for Standard Lib bundles, not third party C-extensions from gems, etc. This seems like it could end up being something very difficult to do correctly; I imagine these were some of the issues _why had to deal with, since in Shoes he maintains a custom fork of Ruby. A quick scan of the Shoes Adventurer's mailing list shows a lot of contortions gone through to get native extensions to build.

Hopefully the situation with gosu can be made less complex, since you haven't actually forked ruby, but I think, as things currently stand, there is a limit to how simple this approach can be made.

Remind me, what was the advantage of statically compiling libruby into the deployment package, instead of bundling the universal dylib and dynamically loading it? It seems it would be easier to get binary gems to work with the latter approach (there may be other differences which tilt the balance the other way, however; that's why I'm asking).

Just tried it using rubygems, works fine that way too!

As for the app wrapper, I can't comment on it yet since I haven't tried your new one even a little bit. I might get a chance to play with that later tonight.

When you say it doesn't run, what *does* it do? Do you get anything dumped to the console, on the order of 'could not load library' or some such?

Okay, I noticed something really, really odd. I was just able to download the new 0.7.13.2 gem, and without using lib_name_tool, and do the following:

$ ruby-1.9 --disable-gems
require './gosu.for_1_9.bundle'
$LOADED_FEATURES.push('gosu')
require '~/code/other/QuickThing/QuickThing.rb'
^D

And it worked. A quick check with otool confirms that it's still set to link against the macports libruby location:
$ otool -L gosu.for_1_9.bundle
gosu.for_1_9.bundle:
        /opt/local/lib/libruby1.9.dylib (compatibility version 1.9.0, current version 1.9.1)
        /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current version 5.0.0)
        /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
        /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 824.47.0)
        /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 22.0.0)
        /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 567.37.0)
        /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 128.0.0)
        /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
        /System/Library/Frameworks/OpenAL.framework/Versions/A/OpenAL (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
        /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10)

The really interesting stuff happens when we set DYLD_PRINT_LIBRARIES_POST LAUNCH:

$ export DYLD_PRINT_LIBRARIES_POST_LAUNCH=1
$ ruby-1.9 --disable-gems
dyld: loaded: /usr/local/lib/ruby-1.9/1.9.1/powerpc-darwin8.11.0/enc/encdb.bundle
dyld: loaded: /usr/local/lib/ruby-1.9/1.9.1/powerpc-darwin8.11.0/enc/trans/transdb.bundle
require './gosu.for_1_9.bundle'
$LOADED_FEATURES.push('gosu')
require '~/code/other/QuickThing/QuickThing.rb'
^D
dyld: loaded: /Users/name/gosu-0.7.13.2-universal-darwin/lib/gosu.for_1_9.bundle, cpu-sub-type: 0
dyld: loaded: /usr/lib/libiconv.2.dylib
dyld: loaded: /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
dyld: loaded: /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
dyld: loaded: /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
dyld: loaded: /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
dyld: loaded: /System/Library/Frameworks/OpenAL.framework/Versions/A/OpenAL
dyld: loaded: /usr/lib/libstdc++.6.dylib, cpu-sub-type: 0
dyld: loaded: /usr/lib/libgcc_s.1.dylib
dyld: loaded: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
dyld: loaded: /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
dyld: loaded: /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText
dyld: loaded: /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/FindByContent.framework/Versions/A/FindByContent
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
dyld: loaded: /System/Library/Frameworks/Security.framework/Versions/A/Security
dyld: loaded: /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
dyld: loaded: /usr/lib/libicucore.A.dylib
dyld: loaded: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
dyld: loaded: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
dyld: loaded: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
dyld: loaded: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/WebServicesCore.framework/Versions/A/WebServicesCore
dyld: loaded: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
dyld: loaded: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
dyld: loaded: /usr/lib/libz.1.dylib
dyld: loaded: /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
dyld: loaded: /usr/lib/libbsm.dylib
dyld: loaded: /usr/lib/libcrypto.0.9.7.dylib
dyld: loaded: /usr/lib/libcups.2.dylib
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRaw.dylib
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
dyld: loaded: /usr/lib/libxml2.2.dylib, cpu-sub-type: 0
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
dyld: loaded: /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate, cpu-sub-type: 0
dyld: loaded: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage, cpu-sub-type: 0
dyld: loaded: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib, cpu-sub-type: 0
dyld: loaded: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib, cpu-sub-type: 0
dyld: loaded: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
dyld: loaded: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib, cpu-sub-type: 0
dyld: loaded: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib, cpu-sub-type: 0
dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
dyld: loaded: /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
dyld: loaded: /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
dyld: loaded: /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
dyld: loaded: /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
dyld: loaded: /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound, cpu-sub-type: 0
dyld: loaded: /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
dyld: loaded: /usr/lib/libsqlite3.0.dylib
dyld: loaded: /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
dyld: loaded: /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo, cpu-sub-type: 0
dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering
dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices
dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
dyld: loaded: /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib, cpu-sub-type: 0
dyld: loaded: /System/Library/Frameworks/OpenGL.framework/Resources/GLEngine.bundle/GLEngine
dyld: loaded: /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib
dyld: loaded: /System/Library/Extensions/ATIRadeon9700GLDriver.bundle/Contents/MacOS/ATIRadeon9700GLDriver
dyld: loaded: /System/Library/Frameworks/OpenGL.framework/Versions/A/Resources/GLDriver.bundle/GLDriver
dyld: loaded: /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLSystem.dylib
dyld: loaded: /System/Library/Frameworks/OpenGL.framework/Versions/A/Resources/GLRendererFloat.bundle/GLRendererFloat
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib
dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGATS.A.dylib

Note with intense interest what does and does not get loaded by DYLD here. I think you may have already won. The two librubies don't even have the same suffix, let alone path, but it's working anyway, probably because running the ruby command line app already loads my installed libruby and provides its symbols.

This may or may not help you in your work on the deployment template, but it's good news for the development gem, I'd say.

EDIT: Okay, I really should have used DYLD_PRINT_LIBRARIES rather than DYLD_PRINT_LIBRARIES_POST_LAUNCH, to get the full picture of what's going on. It gives the same results, except that this occurs immediately after invoking ruby, before encdb.bundle and transdb.bundle are loaded:

dyld: loaded: /usr/local/bin/ruby-1.9
dyld: loaded: /usr/local/lib/libruby-1.9.dylib
dyld: loaded: /usr/lib/libSystem.B.dylib, cpu-sub-type: 0
dyld: loaded: /usr/lib/libobjc.A.dylib
dyld: loaded: /usr/lib/system/libmathCommon.A.dylib, cpu-sub-type: 0
dyld: loaded: /usr/lib/libauto.dylib

Edit again: To be 100% clear, my previous edit hoped to clarify what was going on, not downplay it. It's just extra info I should have included the first time.

I see; so you mean to say that rubygems can't even detect what version of ruby is being used without an extconf.rb... that's obnoxious. There's no way to run rake tasks as part of the gem install process?

Well, I already gave you an XCode tools dependency, so another dependency isn't going to hurt you any further; to whit, install_name_tool is part of XCode tools.

Well, I downloaded the new gem, and I seem to have been able to use install_name_tool to switch it from looking for macports ruby to looking for my installation. My script was a little wrong, though, I had to tweak it.

Anyway, it seems to work, though I haven't really tried anything other than require 'gosu' yet.

Edit: OH, for ref, OS X 10.4, PowerPC
Edit Edit: $ ruby-1.9 -v
ruby 1.9.1p0 (2009-01-30 revision 21907) [powerpc-darwin8.11.0]
Edit Edit Edit: Tested it with a fairly simple game, it seemed to work perfectly. I'll try a more complex one tonight.

I don't have universal ones built atm, but I have a 10.4 Intel installation and a 10.4 PPC installation. To get libruby, I just lipoed the libruby from each together... I'm considering writing up a script to just go through a pair of ruby lib trees and lipo all the binaries together, now that you mention this. At that point, I can give you any standard lib binary extension you want.

Just a note going forward that I don't have reliable access to a 10.4 Intel machine indefinitely; I've got built 1.9.1 installation available to me right now, but I may or may not be able to compile future updates to 1.9 for Intel 10.4.

Fricking sweet!

Only one omission I've noticed from the Rdoc display: you can't navigate to files, in particular you can't navigate back to the main index (aka Readme) page, and although the RDoc page for Copyright exists at http://www.libgosu.org/rdoc/files/COPYING_txt.html , it is (as far as I can tell) impossible to navigate there.

But those are minor quibbles. Overall, three cheers!

You want a universal libruby 1.9? I've got one, I can email it to you.

Edit: Incidentally, I've been thinking a bit about a script which could figure out the appropriate path for libruby 1.9 and edit gosu.bundle with install_name_tool to point appropriately. Requires developer tools to be installed, but, how would you get ruby 1.9 without dev tools anyway? (IIRC, you need Dev tools to install MacPorts, yes?)

http://pastie.org/467123
That's a script that should do it; mind it only works if the two dylibs have the same interface, so different versions (or rather, incompatible versions) are not dealt with here. But it should allow one to take a gosu.bundle linked to MacPorts ruby 1.9 and hook it up to, say, one installed in /usr/local/ . Usage is, save it in a file, and edit the paths to point to gosu.bundle, then run the file with the version of ruby you want to use gosu with. I'd wager this could get incorporated into a rake task with some tweaking.

Note that I can't actually test this fully myself. I tried it on the gosu.bundle for macports 1.9 julian posted earlier, and it did re-link it, but since it was Intel only, I have no idea whether it worked, not having an intel machine handy.