Rubygame

New discussion group

2011-07-16T17:40:00-05:00

As promised in the previous post, I have set up a new Rubygame discussion group to replace the forums and old mailing lists. It’s hosted on Google Groups, so you can treat it as either a forum or a mailing list, whichever you prefer.

Thanks to Roger Ostrander for volunteering to manage the mailing list. If anyone else would like to help out with that, you can still contact me at jacius@rubygame.org.

Forums will be archived

2011-07-15T21:36:42-05:00

The Rubygame forums will be archived beginning next Saturday, 2011-07-23. See the previous blog post for information about why the forums are being archived.

The archival process will take place in two steps:

The forums will be made read-only on 2011-07-23. No new posts will be allowed on or after that date. The forum database will be backed up and preserved offline.
Some time after 2011-07-23, the forums software (phpBB) will be taken offline. Posts that are of lasting value (as judged by me) to the Rubygame community will be preserved on the web site for posterity. Other posts will no longer be available online.

The following alternatives are available to replace some of the uses of the forums:

For getting help or talking with other users, you can join the official IRC channel: #rubygame on freenode.net.
For showing off software you have created that uses Rubygame, you can edit the Showcase wiki page

After the forums close, there will no longer be any non-realtime discussion/support venue for Rubygame. But, I will create a new mailing list for that, if at least one person volunteers to moderate the list and deal with spam. If you are willing to do that, contact me at jacius@rubygame.org.

The New Rubygame.org

2011-07-12T01:33:22-05:00

For the past few weeks, I have been working on renovating the Rubygame web site. Today, I have finally deployed the biggest chunk of that effort: migrating the home page and blog to Jekyll. I have also recently migrated the wiki to Github, and will soon be shutting down the forums.

This strange flurry of activity has a simple explanation: I’m putting Rubygame into a state of indefinite hibernation. Back in January, I made a post calling for a new project lead. I did receive several offers to “help out a bit”. Unfortunately, no one was interested in taking an active role to drive Rubygame forward, which is what it really needs.

But, I did receive quite a few emails from people expressing their appreciation for Rubygame and their hope that it would continue to be available, even if not actively developed. (Thank you to everyone who wrote; it’s certainly nice to hear.) So, all these changes to the website are steps to reduce the amount of regular maintenance needed to run the site, so that I can leave Rubygame inactive but available for the indefinite future.

Blog Changes

WordPress is a nice blog engine, but it requires regular upkeep: applying security updates, moderating comments, etc. With Jekyll, every web page is just a static HTML file, so I don’t have to do anything except when I want to upload a new post. Serving static files is also a lot more efficient than dynamic content like WordPress, and it’s very simple to set up HTTP caching and gzip compression.

One other effect of the site now being static HTML, is that there are no comment submission forms on the blog posts anymore. For some blogs, that would be a downside. If I did want comment forms, I could use an off-site comment systems like Disqus, which is fairly easy to plug into a Jekyll template.

But, since my goal is to reduce the amount of maintenance time needed, and to avoid moderating comments, I’m quite happy to have no comment form. I do accept comments via email, for times where someone has something genuinely worth saying. If that thing-worth-saying adds value to the discussion, I’ll consider posting it to the site.

The actual process of migrating all my blog posts from WordPress to Jekyll was interesting, too. I write more about that below.

Wiki and Forums

Toward the same goal of reducing site maintenance time, I have migrated the wiki to Github, so that I (hopefully) won’t have to deal with the endless spam that was being posted to the old wiki. It might also encourage more people to edit the wiki, since you can use your Github login instead of creating a new one for this site. But if that happens, it would just be a nice side effect.

I’m still pondering what to do with the forums, since they are the biggest time-waster for me. In a typical month, the forums receive hundreds of spam posts, but only one or two legitimate posts. It’s not really worth keeping the forums up and running, but there are some threads worth archiving, such as the RubyWeekend contests. I might convert the worthwhile stuff to static HTML, and sacrifice the ability for anyone to make new posts.

Granted, it would be a shame to lose the only still-active (albeit barely) dedicated way for people to ask for help and communicate with other users. I might create a Rubygame mailing list on Google Groups, but then I’d still have to worry about moderation and spam. Given how inactive the “Rubygame community” has been, I’m not sure it’s worthwhile.

(Technically, there are already two dusty old mailing lists from Rubygame’s SourceForge days, but they are even less active than the forums. I’ll definitely be archiving and shutting them down soon.)

A New Look

The migration also gave me an opportunity to improve the site’s look. I hand-crafted the template myself, using HTML5 for semantic document structuring, and CSS3 for styling. There’s actually not a lot of fancy CSS3 going on, aside from some gradients, rounded corners, and shadows. Even so, I’m quite pleased with the result, both for its clean look and for its clean separation of structure from presentation.

Since it’s HTML5 and CSS3, the site might not render correctly on ancient browsers like IE6. It should still be legible, just not as pretty. But if you’re still stuck on IE6, you’re probably used to websites not rendering correctly anyway.

Working with Jekyll

For the uninitiated, Jekyll is a nifty little static website generator. It could benefit from a bit of code cleanup, but it works well for the most common purposes, and is pretty easy to use. You provide it with page templates and your post content (which can even be written in Markdown or Textile), and it churns out a website made of static HTML pages, ready to be uploaded to any web server.

Working with Jekyll has been a lot of fun. The templating system is totally customizable, since it’s just HTML with embedded Liquid markup. (Liquid has its shortcomings, but it gets the job done.) Even better, you can download or write your own Jekyll plugins in Ruby, to change or extend Jekyll’s behavior. For this site, I’m using plugins to generate the archive and category pages, to convert SCSS to CSS, to tweak the older/newer post pagination behavior, and to define a few custom Liquid filters that I use in my templates.

Converting the WordPress posts to Jekyll was another interesting experience. Jekyll comes with a very basic WordPress migrator script, which exports the post content and some basic metadata (e.g. title and date). But, I wanted the whole enchilada!

So, I majorly revamped the migrator to also export comments (including author info and date), categories and tags, drafts and private posts (while marking them as unpublished so Jekyll will ignore them), and more. It even exports post excerpts, or fills in an empty excerpt automatically if the post uses a  tag. I also made it clean up HTML entities in the post and comment bodies, and add rel="nofollow" to links in comments. Phew! Naturally, I’ll be contributing my improved migrator back to the Jekyll project soon.

Once the post data was migrated, it still took some work to get it all to render nicely, and to be mostly backwards compatible with WordPress so that there would be as few broken links as possible. I think I did pretty well on that front, although I did sacrifice the comment feeds and per-category feeds. It’s possible to reimplement them in Jekyll, but I’m not sure it’s worth it.

Final Thoughts

All in all, it was pretty fun working on the website. It gave me an opportunity to create something fresh, and to learn a cool new tool. And, in the long run, it should eliminate most of the maintenance required for this site, so that I can move on from Rubygame and focus on exciting new projects.

Thinking About Engines

2011-03-13T17:14:03-05:00

I wrote in an earlier post about the potential for Rubygame to have multiple engines in the future. (I called them “backends”, but I think “engine” is a better term.) Rubygame could have one engine that uses OpenGL and OpenAL, one engine for Android devices, etc., to make it more portable. I don’t know if this is something I’ll actually pursue, but it’s an interesting concept, so I felt like writing about it in more detail.

When I say engine, I mean the underlying software libraries that do the low-level work of creating the display window, pushing pixels, loading image and sound files, and so on. Rubygame has always used SDL 1.2 (and SDL_gfx, SDL_image, etc.) as its engine, but SDL has some shortcomings that have bothered me over the years, and I’d be happy to ditch it. One of the biggest thorns in my side with SDL has been how much of a chore it is to acquire and use it on Mac and Windows. Back when Rubygame was a compiled extension (before the transition to FFI in Rubygame 2.6), Mac and Windows users couldn’t install Rubygame at all unless we provided a pre-compiled binary, or unless they installed a C compiler and the SDL development packages. Even then, Mac users required a special version of the Ruby interpreter, called RSDL, to use Rubygame (or any other Ruby library that used SDL).

Both of those issues should be solved now, but downloading and installing the SDL libraries themselves is still a barrier to using Rubygame. It would be much nicer if Rubygame could work right out of the box, without the user needing to install any extra libraries.

Accomplishing that would require leveraging libraries that are likely to be already installed, such as libraries provided by the operating system. But because many libraries provided by one OS aren’t available on other OSes (e.g. DirectX is not available on Mac or Linux), Rubygame would need to support multiple engines, and be able to detect at runtime which engines are currently available.

(There are some libraries, like OpenGL, that are cross-platform yet often provided by the OS. But, I don’t think it’s possible to recreate the full functionality of Rubygame using only OS-provided cross-platform libraries. For example, I don’t think there are any such libraries for loading a variety of popular image and sound formats.)

Supporting multiple engines would be a lot of work, and to be honest I’m not sure it would be worth it. A more practical approach might be to find some suitable cross-platform libraries and focus on minimizing the hassle of installing them. But, a modular design supporting multiple engines is an interesting challenge, at least to daydream about.

The first hurdle in a multi-engine design would be separating out the parts of Rubygame that are specific to the current engine, SDL. Off the top of my head, that would be the Screen, various events, Surface, Sound, Music, and TTF classes; in terms of functionality, it’s the display window; input and window events; image loading, manipulation, and display; audio loading and playback; and vector font loading and rendering. The rest of Rubygame is Ruby code built on top of those features, and could be shared across engines.

The biggest pitfall to avoid would be limiting Rubygame to merely the basic functionality that all the engines provide. For example, if one of the engines doesn’t support fullscreen mode, it would be misguided to cripple other engines that do support fullscreen mode, in an attempt to provide a consistent API. That strategy would make Rubygame the “lowest common denominator”, inheriting every weakness of each engine, but none of their strengths. It would be less useful than the current wrapper around SDL, yet it would take more effort to create and support. Obviously, that’d be no good.

Yet, there is a need to provide a consistent API. A game developer doesn’t want to have to worry about differences between implementations. If you have to do that, there’s not much benefit in using a single library (Rubygame), rather than working with each separate engine directly. Ideally, a developer should not have to know which engine is being used; if they use the API properly, as documented, their game should just work.

So, Rubygame would need to provide a consistent API that works across all engines, yet it would also need to accomodate differences in implementation and functionality in each engine. How can these two conflicting requirements be reconciled?

Well, this is a problem web developers/designers grapple with every day. It is the source of much complaining about Internet Explorer 6, rendering differences between browsers, and so forth. Two common strategies for dealing with this problem are progressive enhancement and graceful degradation. Both strategies address how to create content that works across all “engines” (browser implementations), yet can still take advantage of features when they are available.

Progressive enhancement prescribes starting with the baseline content that all engines support, then allowing the experience to be enhanced depending on what additional features are available in each engine. Graceful degradation prescribes starting with all the bells and whistles, then allowing for the experience to degrade towards a baseline depending on what features are missing from each engine.

It’s worthwhile to note that both strategies recognize that there is a baseline set of required features that all engines must provide, and beyond that are optional extra features that any given engine may or may not provide. What’s more, the engine must provide a way to detect whether an optional feature is implemented, and/or automatically ignore instructions for optional features which are not supported.

These concepts are applicable to Rubygame as well. Actually, Rubygame already does it already, to a limited extent. SDL is a required library, which Rubygame cannot function at all without; that sets the baseline. The other libraries (SDL_gfx, SDL_image, SDL_mixer, and SDL_ttf) are optional, and Rubygame can still function without them, albeit with fewer features. And, a game developer can test for the presence or absence of these features by checking whether the related classes or methods are defined. For example, the various Surface#draw_* methods only exist if SDL_gfx was loaded; even more specifically, the Surface#draw_curve method only exists if the loaded version of SDL_gfx implements that feature.

In theory, that would be sufficient to enable a game developer to use either the progressive enhancement or graceful degradation strategies to adjust the program’s behavior depending on what features are available. At least, it’s enough to gracefully inform the player that some feature that the program depends on is not currently available. But, Rubygame would need a much smarter system if it were to support multiple engines in a practical way.

For one thing, checking for the existence of individual classes or methods is just not going to cut it. Consider the class method Surface.load, which loads an image file of any supported type. Surface.load only exists if the SDL_image library was loaded, so a program can assume that if that method exists, it can load at least some images. But how can a program check that it supports a specific file type, say PNG? The docs say that it supports PNG on some systems, but there’s no way to check that this system supports PNG, except to try to load a PNG file and check whether it succeeded or failed. That’s no good at all.

It would be much better if there were a central list indicating which features are available: which image types can be loaded, which shapes can be drawn, whether fullscreen is available, and so forth. This simplify the process of checking whether a feature is available, as well as laying the foundation for a multi-engine design.

In a multi-engine design, each engine would provide a list of features that it provides. Or, possibly, two lists: an “ideal” list which can be inspected without actually loading the entire engine, listing all the features it could provide on an ideal system; and a “reality” list, available after the engine is loaded, listing all the features it actually does provide on the current system.

In theory, a program could indicate which features it depends on, and which features it can optionally use, and Rubygame could intelligently choose the best available engine (or combination of engines) to satisfy those criteria. A program could indicate whether it has a preference for a certain engines (to act as a tie breaker if multiple engines can provide the same features), or even that it utterly depends on certain engines (and should raise an error if the engines are not available).

And, if Rubygame is automatically and dynamically inspecting and loading the engines, there’s no reason why it would have to be limited to engines that ship with Rubygame. People could create and distribute custom engines as gems or packaged with their game, tell Rubygame where to look (via a PATH-like environment variable), and Rubygame would detect and consider the custom engines just as it does the official engines.

Actually implementing support for multiple engines could be an interesting metaprogramming exercise. A naïve way to do it would be for each engine to directly modify the main Rubygame modules and classes. But, that would leave a mess if there was a problem loading one of the engines, and it wouldn’t let Rubygame load an engine and check its “reality” features list before applying it.

A better approach would be for each engine to define a mixin module for each Rubygame class it wanted to modify. To activate the engine, the Rubygame classes would simply be extended with those mixin modules. That would allow the engine to be loaded and checked before activating it, which is good.

One potential shortcoming of both those methods is that there’s no clean or simple way to deactivate an engine or switch engines once one has been activated. It’s too bad Ruby doesn’t provide a way to un-extend/un-include a mixin module, or the second method would be pretty much perfect. A more complex method could involve dynamically rebinding methods to transplant them from the engine’s modules/classes to the Rubygame classes, then unbinding them to deactivate the engine. But this would be complicated to achieve, and I’m not sure deactivating/switching engines would be that important, so it may not be worth the trouble.

Anyway, as I said, I’m not sure this is something I would pursue. It’s an interesting idea, but it would be a lot of work, and there are probably more fruitful ideas to pursue. I may just leave it as a thought experiment.

Ruby-SDL-FFI 0.4 released

2011-03-06T15:58:37-06:00

Ruby-SDL-FFI 0.4 is now available. This is a small bugfix release to address a Mac issue and two missing methods. Thanks to Bart Leusink for doing all the work! :)

Release notes:

Fixed the display window not gaining focus on Mac OS X 10.6. Thanks to Bart Leusink for fixing this.
Added SDL::SaveBMP and SDL::LoadBMP methods. These were convenience macros defined in the SDL headers. They have been reimplemented as Ruby methods by Bart Leusink.

The easiest way to install Ruby-SDL-FFI is with gem install ruby-sdl-ffi. (If you want to use Ruby-SDL-FFI or Rubygame on JRuby, you may need to install the ffi stub gem first.) Gem and source tarballs are also available, and you can get the source from Github too:

Enjoy!

Rubygame Needs Help

2011-01-20T02:09:11-06:00

Rubygame is in a sad state.

It has been months since I’ve even looked at the code. Rubygame 2.7 has been sitting in the repository for months, 90% complete, but no one with the drive to finish it. It is still difficult to install on Mac and Windows. There are few or no high-quality introductory guides or tutorials to get people started. The IRC channel is silent, questions in the forums are going unanswered, and users are leaving.

A few months ago, I was ready to pull the plug on Rubygame and move on to other things. I wrote up the announcement, and even started on a post-mortem to analyze why Rubygame failed, and try to learn from it. But abandoning Rubygame after 6 years is tough, and there has been a trickle of activity lately. Not much, but enough to make me hesitate, to give me a modicum of hope that Rubygame can recover.

Rubygame has potential. It currently uses SDL 1.2 as its backend, but there’s no reason it couldn’t offer other backends. It could use OpenGL and OpenAL to provide hardware-accelerated graphics and audio. It could run on Mac and Windows using native frameworks like Quartz or DirectX, so there’s less to install. It could run on Android devices using Ruboto/JRuby, allowing people to write Android games in pure Ruby.

But, I can’t do any of that alone. I don’t have the motivation to even maintain Rubygame by myself. I need more people to help. Not just contributors submitting patches and bug fixes, but enthusiastic and capable people actively pushing Rubygame forward. I’m not looking for anyone to volunteer out of pity; I want people who are genuinely interested in working on Rubygame.

Unless more people get involved, I’m going to have to put Rubygame down. That’s not a threat or demand, just the fact of the matter. Without more people, Rubygame will continue to wither and die, which would be painful for me to watch. I’d rather end it quickly than let it drag on towards the inevitable. But, watching Rubygame grow and flourish would be even better.

At a bare minimum, Rubygame needs one person to take over as owner/visionary, plus at least one other developer (besides myself and the new owner) working on Rubygame in general. Beyond that, it would be great to have additional developers focused on specific platforms and back-ends (e.g. Mac expert, Windows expert, Android expert). Finally, it would be nice to have someone whose main job is to write docs and tutorials, and help out users in the forums.

If you are interested (genuinely interested) in working on Rubygame in any of these roles, or another role you have in mind, please contact me at jacius@gmail.com.

Ruby-SDL-FFI 0.3 released

2010-08-08T00:32:33-05:00

Ruby-SDL-FFI 0.3 is now available. The biggest change is that Ruby-SDL-FFI apps (and Rubygame apps) can now run on Mac OS X with no special interpreter. In the past, Mac users had to run apps a special Ruby interpreter called RSDL. Now, this is no longer necessary — Mac users can now use the standard Ruby interpreter, even JRuby. (Eternal thanks to erisdiscord and jlnr for their advice and tips!)

This solution has only been tested on Mac OS X 10.5 (Leopard) on an Intel Mac. If you try it on a different setup, please leave a comment to let me know whether it works or not.

Release notes:

Ruby-SDL-FFI can now work on Mac OS X without the need for a special interpreter (i.e. rsdl). If this causes issues for you, you can disable it by setting the RUBYSDLFFI_NOCOCOA environment variable to "true".
Added the SDL::set_app_name() method. This sets the application name in a platform-appropriate way, or does nothing if the platform is not supported. On Mac OS X, it changes the text in the menu bar. Support for other platforms may be added in the future.
Ruby-SDL-FFI now reads the RUBYSDLFFI_PATH environment variable for additional library load paths. It should be a colon-separated (Linux/Mac) or semicolon-separated (Windows) list of directories to search for libraries
The SDL::Palette class is now Enumerable. You can iterate over it with #each, #collect, etc. You can also read a specific index using #at (but not #[], which is reserved for struct access)
SDL.GL_GetAttribute() now returns an integer, like it should. Before, it would return an FFI::Buffer.
SDL.GetKeyRepeat() is now easier to use. It returns an Array of two integers: [delay, interval]. Before, you had to pass two output buffers, then extract the integers afterwards.
Fixed a NoMethodError in SDL.WaitEvent().
Ruby-SDL-FFI now uses FFI::Buffer instead of FFI::MemoryPointer in many places. This should give a slight performance boost on JRuby, and potentially other platforms.

The easiest way to install Ruby-SDL-FFI is with gem install ruby-sdl-ffi. (If you want to use Ruby-SDL-FFI or Rubygame on JRuby, you should install the ffi stub gem first.) Gem and source tarballs are also available, and you can get the source from Github too:

Enjoy!

Rubygame 2.6.4 released

2010-04-16T01:24:22-05:00

Rubygame 2.6.4 is now available. This is a maintenance release which fixes a bug in the gem spec:

Fixed: Rubygame's "require_path" setting in the gem spec was interfering with ruby-opengl (and potentially other libraries). [#43]

If you have problems loading ruby-opengl when Rubygame 2.6.* is installed via RubyGems, you should uninstall older versions of the Rubygame gem, then reinstall version 2.6.4 (or later).

Thanks to brandon for reporting this issue, and tyler for reminding me about it.

Rubygame 2.6.3 released

2010-03-31T23:34:34-05:00

Rubygame 2.6.3 is now available. This is a maintenance release which fixes several bugs, mostly related to how events are converted from SDL into Ruby. It also adds a way to prevent Rubygame from automatically initializing SDL when Rubygame is first required. Also, Nice-FFI 0.4 has been released, which should fix issues that Rubygame some users have had with the SDL libraries not being found, even when they were installed correctly.

Changes in 2.6.3:

Fixed: MouseMoved events always reported that all buttons were being pressed, even when they were not. [#38]
Fixed: MousePressed and MouseReleased events would raise an error for mouse buttons larger than 5. [#40]
Fixed: KeyPressed and KeyReleased events always reported that all modifier keys were being pressed, even when they were not. [#41]
Fixed: Rubygame would generate spurious WindowUnminimized, InputFocusGained, and MouseFocusGained events (or the opposite) whenever any one of those events actually occurred.
Fixed: Surface#convert would raise NameError if no Screen was open, due to a typo. [#42]
Rubygame will now skip auto-initialization if the RUBYGAME_NOINIT environment variable (ENV["RUBYGAME_NOINIT"]) is set to "1", "true", or "yes" (case insensitive). You must set the environment variable before doing require "rubygame". This is intended for special cases where auto-initialization is not wanted.

Thanks to Dan Morgenegg, moinkers, and tape0 for their bug reports!

You can update a gem-based install with gem update rubygame, or download Rubygame from Rubyforge.

Rubygame blog migrated to WordPress

2010-02-24T23:33:01-06:00

I’ve finally migrated the Rubygame blog from Mephisto to WordPress, like I did for my personal blog back in November. Apologies if the switchover has caused some spam in your feed reader.