next »

[dspencer]

I was wondering if anyone here uses ruby at all. I started using it this summer for work and it is everything I ever wanted in a language. Alongside that, I looked into rubygame, and I'm finding that game dev in ruby is likewise a lot quicker than in c++. Does anyone here use rubygame? I've seen a little talk of pygame here, recently, but still not too much. It seems like these are great tools to make smaller games, at least.

Anyone with me?

[alltom]

I've done some experimentation with game programming in Ruby, small stuff based on the gosu/chipmunk example game. Since gosu seems to be much more actively developed than rubygame, I used that. The garbage collector on 1.8 nowhere near good enough for games, but collection is not too noticeable on 1.9 if you only let it run once per frame and the game is tiny.

[slembcke]

We wrote Crayon Ball largely in Ruby. http://howlingmoonsoftware.com/crayonball.php

We didn't use any libraries really, just wrapped the parts of SDL, libpng, libvorbis, etc that we needed. I already had a Ruby binding for my physics engine and we wrote the scenegraph in C. The scenegraph hooked directly into the physics at the C level so it was quite fast. All said and done, it was a few thousand lines of C code and a few thousand of Ruby code.

We did the "hard" stuff in Ruby, gameplay code and object initialization. Ruby was great for describing the scenegraph nodes as we made a simple DSL based on Ruby blocks to describe and initialize the scenegraph structure. The C code for the scenegraph did little more than traverse the tree, so it was all pretty simple. We also had scenegraph nodes that applied transformations directly from physics bodies so we didn't have to copy all of the rendering information from the physics to the scenegraph in slow Ruby code.

Pushing the simple but performance critical parts to C like that, we avoided flooding the GC with unnecessary temp objects. Ruby only used about 1/4 of the total CPU usage, and the game ran just fine on a 1GHz G4.

[adam_smasher]

Python/pygame is pretty widely used in the community, I think. Ruby's a bit more fringe - the ecosystem around it is a bit immature, the language is a bit quirkier than Python (though more expressive), and the runtime is somewhat slower. Still, it gets the job done, and you can do some really cool stuff with all of its dynamic, metaprogramming-y capabilities  - when my team used it for TOJam a couple of years back, we hacked together some really cool things like double dispatch for collision detection and a coroutine-based scripting system using call/cc.

[OneSadCookie]

I wrote http://onesadcookie.com/~keith/Mechanical.zip (Mac, 10.5+) with Ruby.

I've had various goes at writing various cross-platform Ruby game frameworks at various times, but none has really ever come to much.  If you want to use Ruby, http://onesadcookie.com/svn/GLEWby is ruby bindings to OpenGL via GLEW, which at least when I wrote it was vastly better than the other OpenGL bindings available.  There are also OpenAL bindings in http://onesadcookie.com/svn/RubyGameCommon/Source/ .  I guess I should make gems out of those these days :/

Ruby's pretty slow, and the pause for a GC is pretty big.  I've ended up manually running the GC once each frame (and disabling it during a frame) to keep the frame-rate smooth, at a significant performance penalty.  Float is boxed, too, which means you pay for expensive allocations for all your floating-point math.  Still, it's fine for relatively simple 2D games at least, and hardware only gets faster.

[jmp]

I use Python a lot. I've written a few small (unfinished) 2D games and a bunch of tools in it. I've found it very useful for prototyping even when I'm writing a program in C or C++.

Although, I much prefer pyglet over Pygame. I find the API more "pythonic", and the fact that it has no additional dependencies makes it easier to use with tools like py2exe/py2app. I haven't touched Pygame in years, though, so chances are it has changed a lot since then.

[Taiko]

I'll throw in a plug for Python.  Very elegant syntax, and there are plenty of modules for doing whatever you want.  Pygame is great, in particular, for prototyping game concepts.  It is also fairly easy to integrate into C/C++ apps.

I will say that the main problem with Python is distribution of your applications to people who don't have an interpreter.  Py2Exe works but takes some time to figure out all of the intricacies.

[Atnas]

I prefer Ruby to Python personally. I use Gosu too! I tried Rubygame about three years ago, but I found it a little cumbersome. Gosu is a lot more open imo, and I can count on regular and meaningful updates to the library.

I don't think enough indies use Ruby, it's a really wonderful language for artists especially, I think. Writing in it is very natural and you won't find yourself stumbling over syntax as much as other languages when you get started.

Over the past year or two I've had a number of little projects written in Ruby/Gosu that haven't gotten past tech demos or engines, because of business. But really I hope once I can get one finished and out for people to play it gets more devs interested in the language.

[Musenik]

The games at the link below are made with python and pygame. Our next one will add PyOpenGL into the mix. Fun stuff!

www.mousechief.com

[Klaim]

Maybe you could try making a game with SFML, there is a Ruby AND a Python binding : http://www.sfml-dev.org/download.php

I'll try the D language exactly this way. It's good to have a simple game library available in each interesting languages!

[r.kachowski]

I highly recommend checking out the awesome Chingu library for developing with ruby + gosu. It has some really cool features built in and it's ideal for tiny mockups and prototypes 

[simono]

I've used PyGame a lot.

If you want to get a feel for what is possible with python looks at the winning entries here:

http://pyweek.org/

(all done in one week of coding)

Most of them also have the source code, so good place to learn how to structure your pygame stuff. Try my game first :D http://pyweek.org/e/thecode/

[gwar]

Well I'm not big and professional like the rest of tigs but I am another pythonista. My first 'real' game is chugging along very slowly with some borrowed art.

My only problem with the python is that it'll try to do nice things for me that hides my mistakes until quite some time down the track, like changing scope on class attributes or creating a new variable because I've mistyped something. My little tiler doesn’t perform well either, I'm sure im to blame on that score though.

[Frog]

I've been wanting to do some game development with Ruby for a while now. I've been using it for a lot of web stuff (mainly Sinatra and Rails) and I feel like I've got a pretty good idea of how everything works. Also I need to make a game for my school software class's major project, seems like a good enough excuse.

[Hima]

My first game programming language is Ruby and I'm still in love with it and hope to make something great with it someday. With that said, Ruby is very slow though. Unfortunately, there aren't many English game library/framework for ruby. However, Japanese people are pretty active with Ruby game development. Here are the libraries I've found so far

Gosu - Tried it, and love it. Very easy to use, very powerful ( for ruby ). The only thing I don't like is the Audio library. It use FMOD on Windows, so you can't make a commercial game without paying for a licesne fee to FMOD.

Ruby/SDL - It's basically a port of SDL to ruby. It's pretty good and if you want something low level, then this might be a great choice.

On the Japanese side we have..
Miyako - Very active ruby library. It can play video file and do lots of things. They even come with a Visual Novel framework. It actually wraps Ruby/SDL so that you can use them easier.
http://www.twin.ne.jp/~cyross/Miyako/

MyGame - This one even has a book in Japanese, so it's pretty good. A pseudo-3D racing doujinsoft has been made using this library. I tried it and it was ok. Like Miyako, this one also a wrapper for Ruby/SDL.
http://dgames.jp/ja/projects/mygame/

DXRuby - This one is what I really like. Unlike the other two libraries, DXRuby wraps DirectX and it's pretty fast for a ruby. It comes with collision detection system as well as extensions like sprites and animation, which all of them are written in C so it's pretty fast for Ruby.
http://dxruby.sourceforge.jp/

I tried to wrote a game engine/framework that use Ruby too, But didn't have time to finish it   http://rubix.gptouch.com/home  Maybe one day... maybe... 


Anyway, my experience with Ruby has been good so far. Like people here have said, I don't have much problem with the syntax at all. And even if I do, many of them can be solved easily. Code is easy to read too, due to the nature of the language. The only problem I have is it's hard to find good IDE. I used EasyEclipse with Ruby plugin before, but since the game I made has to use Japanese language and the IDE didn't seems to support it so I have to drop that. If you have no need to use non-English language, then EasyEclipse should be the one to go with.  Another one is Aptana IDE, but it crashes on me quite often and eats my memory everytime I run so I don't know what's up with that. I ended up using Notepad++ to code the game in the end lol.

As for packaging the game, I'm not sure about other OS but for Window you have ruby2exe, exerb  for Ruby 1.8.x and OCRA for Ruby 1.9. Oh, that reminds me. One thing you should think about is which version of Ruby you want to go with. Many libraries support only one and not both. I used Ruby 1.9 for better encoding support, since I have to use non-English language in my game.

Ughh, sorry for the long post. But it isn't often to see Ruby being discussed around here so I got a bit carried away...

[Guillaume]

Currently programming something awesome but so far undisclosed with Python + Pygame. If what you're doing is 2d and not too heavy computationally, it is an amazing combination. Especially since my projects uses some pretty convoluted algorithms, and Python makes the debugging easy with literally no compiling time, and being able to trace through the interactive interpreter.

The main drawback is bundling; py2exe and py2app exist, but they're trouble.

[Fallsburg]

I like pygame, but I really like Panda3d.  If you are thinking you want to do 3d and like python, I'd say that it is the thing for you.