Creating Games in Ruby (Part 2)
Pages: 1, 2, 3, 4

The GGZ Gaming Zone Project
Founders: Brent M. Hendricks and Rich Gade
Developed and Maintained by an International Team

The GGZ Gaming Zone has recently bolstered its support for Ruby, which is both indicative of Ruby's rising profile in the gaming space, and something that has the potential to further improve Ruby's standing as a game programming language. As the official online game development platform for both KDE and Gnome, GGZ is now packaged with most Linux distros.

GGZ is a recursive acronym, like GNU. Actually, when GGZ was founded around eight years ago, it was initially called Gnu Gaming Zone, or GGZ. The founders anticipated becoming part of the GNU project, but when they later decided against that, they decided to go with the name GGZ Gaming Zone.

The GGZ Gaming Zone project includes a lot of useful resources for game developers, like protocols for deploying your game over a network and libraries that provide services ranging from sign in to reserving seats to saving high scores. The GGZ source repository also contains dozens of games and a web portal designed for gaming communities, complete with RESTful APIs for accessing information like tournament schedules and player rankings. The portal software is running on the GGZ community site, where you can find current tournament schedules. Spades is particularly popular. There are Spades tournaments on a regular basis.

You don't need to install anything or even sign up for an account to play the games installed on the GGZ community site. Just hit the "Play Now" button, and log on as a guest. If you install GGZ software on your computer and run the core launching client, you can choose the GGZ community server to play the games installed there, you can choose the GGZ server on your own local machine, the GGZ server on a friend's machine... or any number of other public GGZ servers running all over the world.

The core clients packaged with GGZ are basically chat clients that can launch games. The core client lists games that are available for launching and provides information about the status of any virtual tables (think "bridge table," not database table) where games are in progress or where people are waiting for additional players to show up. When you launch a multiplayer game, you are prompted to indicate which seats should be open to anyone, which seats should be reserved for particular players, and which should be assigned to the computer. You can join games as a player or a spectator.

Below is a sampling of games packaged with GGZ. GGZ game code is usually broken down into game server code and game client code. GGZ offers more than one client for several of the games. Three very different tic-tac-toe clients are on the bottom row. If there are multiple front ends available, the core launching client will prompt you to pick one.

Games distributed with GGZ
Figure 8. Games distributed with GGZ

This is architecture that makes it easy for GGZ to support multiple game clients and multiple game servers for the same game.

GGZ architecture
Figure 9. GGZ architecture

GGZ publishes protocols that define message types and describe the kinds of data that must accompany each message type for communication between clients and servers. For example, GAME_SPECTATOR_SEAT is a type of message a core client can send to a game client to indicate that a user wants to join the game as a spectator. The protocol specifies that the seat id (an integer) and the player name (a String) must be sent with a GAME_SPECTATOR_SEAT message.

For everything other than the communication between a game client and a game server, GGZ provides utility libraries that encapsulate both the GGZ-specific protocols and the network protocols used to send the messages. These libraries are represented by the highlighted green text in the diagram. C is the primary development language for GGZ, but there are Ruby bindings for these libraries. The Ruby bindings as well as a high-level pure Ruby wrapper for one of the Ruby C extensions are highlighted in red.

Since each individual game has a different protocol for communication between the game client and the game server, GGZ can't offer a pre-packaged library that will work for every game. What it does offer, instead, is a flexible code generation utility called ggzcomgen. You define your game protocol in an XML document and specify your network protocol as a command line argument, and the utility will generate a file that contains a method for each message type in your game protocol that uses the specified network protocol to send the appropriate data types over the network. The generated networking code is represented as net.rb and highlighted in Ruby red in the diagram, but the utility can generate Python and C source as well as s Ruby.

The code generator itself, ggzcommgen, is also highlighted in red because it is written in Ruby. It is the only part of the GGZ infrastructure that is written in Ruby.

Most of GGZ's Ruby bindings were added within the last 6 months. As a proof of concept, GGZ lead developer Josef Spillner wrote a tic-tac-toe game server called Rubytoe in Ruby and a rudimentary tic-tac-toe client using QtRuby.

QtRuby tic-tac-toe client
Figure 10. QtRuby tic-tac-toe client

Both the experimental Ruby client and the experimental Ruby server are pretty basic, but they signal the potential for a whole GGZ Ruby package. There's currently a GGZ Python package, which is tightly integrated with Pygame. GGZ developers are thinking about integration with a Ruby game programming framework, possibly one of the frameworks covered in this series!

I will conclude my survey of Ruby game development resources with that thought.

Can playing games written in Ruby be as much fun as writing them, or do they run too slowly, with too many breaks in the action at inopportune times?
Is Ruby a legitimate player in the gaming space?

As promised at the beginning of Part One, I will now address whether performance issues, including the fact that Ruby's garbage collector is of the so-called stop-the-world variety, can and should stop developers from playing with and working with Ruby game development frameworks. I will also touch on Ruby's status in the commercial video game marketplace.

None of these issues have stopped the developers of the game frameworks covered in this series.

There are several implementations of Ruby in the works that have the potential to make Ruby programs run orders of magnitude faster than they do today. While Ogre.rb author Jason Roelofs is confident that Ruby performance will improve significantly by the time either Ogre.rb or Shattered Ruby are ready for a 1.0 release, he says he has "yet to experience any serious lag from GC" under Ruby 1.8.6. He's seen a "one or two frame stutter."

Martyn and Mikkel Garcia, the authors of Shattered Ruby, force garbage collection every frame. GC has not been a show-stopper for them.

Gosu author Julian Raschke recently tried modifying Gosu to call garbage collection every 10 seconds. But he took out that code before the latest release because he didn't think it made a big difference. He has worked on improving Gosu performance for recent releases, but garbage collection was not one of the issues he identified as major.

And it also did not stop a multimedia company from starting to use the Ruby version of Gosu recently. The company is called Thinking Pictures.

So ... I can't say anyone's building a commercial video game with a Ruby game development framework, but I can say a Ruby game development framework is being used commercially -- which is a start.

Click "START" to begin playing...

Andrea O. K. Wright enjoys organizing weekly Ruby Tuesday tech lunch-and-learns for her colleagues at Chariot Solutions, a consulting firm based in Fort Washington, PA. She has given presentations about developing games with Ruby at several conferences, including RubyConf 2007.

Return to O'Reilly Network Ruby.