I love Ruby, I spend a lot of time writing it. I also write kids games for iOS. I would never consider Ruby(in it's current state) a good language to write a game in. Anyone who would has clearly; never written a game before; or never used Ruby for anything serious before.
I agree with the other posters, you should investigate ObjectiveC though. You can get ObjectiveC packaged and running on Windows BTW, don't worry about that.
This may not be the case for all Ruby devs, but I think having these stories out there is still useful.
But I will say this, do you think this guy made up his post about using Ruby to try to write this game? If you don't think it fabricated, do you think he's alone?
I do think there is a fundamental problem, especially with respect to perf, that a lot of people have never looked at what code actually runs on their box. Never looked at the emitted or generated asm. Don't know the cost of calling a method, much less invoking some framework routine to do something. And then you couple this with a lot of devs think their the cats meow because they got x trans/sec and hear horror stories about the ceremony and inefficiency of C++.
And it doesn't help with the blogs and articles that constantly come out saying that Java or Ruby or Lisp is faster than C/C++ (the answer is never pleasingly straightfroward).
While I appreciate that none in your Ruby group would think this, I'd also ask why do they believe this? It's no more reassuring if they don't have a clear understanding of why C++ might be better for the job.
Lastly, I should add that the conversation was a heated discussion where I was playing devil's advocate that I thought they were going to switch off of Ruby like Twitter. I don't think they really appreciated it, although I wasn't actually being all that serious at the time.
I neither think his story is fabricated, nor do I think he's alone. (I didn't say I really thought your story was fabricated, either.)
> While I appreciate that none in your Ruby group would think this, I'd also ask why do they believe this?
I don't know that we would all choose C++, were we building a game, but the performance of Ruby is frequently a topic of discussion. We are lucky enough to have several members that have significant experience working with/around Ruby performance, and they share their knowledge. In other words, were you to choose one of us at random, we would more likely be able to tell you why Ruby is not a good idea, as opposed to why C++ is.
Show them some numbers
Nowadays it gets easier and easier to use interpreted language as the hardware gets more and more things delegated.
For some games, it may be better to do everything in C/C++, some others C/C++ with some interpreted language on top for some parts, and some others whatever language you prefer.
Given higher level language usually help you write code faster, I would definitely give up some performance (which is not really visible usually) in exchange for some efficiency. Even for some 3d game.
But then again, not everyone is writing the next Gran Turismo :)
Although I can't speak of ruby or its vm since I never used it, but have used python + OpenGL or pygame quite a few times.
In his case not only performance suffered too much from ruby but writing code in ruby didn't make him more efficient. So ruby didn't bring enough value.
What you're saying here is extremely disturbing to me. For one inexperienced developer to make a wild unsupportable claim like Ruby can do anything C++ can do performance-wise is an act of hubris. For a whole roomful of such devs to nod in agreement is a little microcosm of willful ignorance that must have been terrifying to behold. If this is typical of your experience with Ruby devs I will suggest that your moving in C-player circles and you should expand your travels. We are not all that ignorant.
Second, technically speaking of course it can do anything C++ can do. The question is can it do it well, or fast?
I've written lots of Ruby for things that are serious (large websites with lots of traffic), and I've worked as part of a team that built on commercially available games in C++ that sold lots of copies.
Ruby has come along enormously recently, especially with 1.9.3 and the other flavours that are out there now. I thought it might be worth trying it and advancing the state of the possible. Eventually I decided that actually shipping something was more important.
It's one thing to choose the wrong language for a project. But having done that, please don't submit a post that suggests expert knowledge or deep experience in Ruby.
For what it's worth, I use both Ruby and C++. I would probably have gone with Qt if I wanted to build such a game. It would never have crossed my mind to write it in Ruby, and I don't consider myself an expert in Ruby.
The title is designed to be controversial as people don't like their favourite programming language to be slandered, thus they will be obliged to read the article so that they can defend their baby.
Using link bait as a title is contrary to HN guidelines, so if anything, it is the article that does not belong on HN, not the grandparent comment.
He coded his game in one language and then SWITCHED in mid-development to another, with all the delay and hassles that that brings, in order to get links...
Another thought is to treat simulation and drawing as separate concerns. Every 1/60th of a second, interrupt the simulation and draw the current state to the screen. This means that you can do things that take more than one frame to calculate without reducing the framerate. (Does Ruby have a good coroutine library?)
Rewriting your entire game because your design is bad is silly. Switching to C++ just makes your mistakes less obvious. (And now you'll be debugging memory leaks and segfaults instead of slow frames. If only there was One Perfect Tool...)
Is it common for commercial games to write AI in Ruby now?
Because, while pounding in a few hundred nails with my trusty flathead, I noticed that it was taking really a great deal of work.
Of course, sometimes you have to dive even deeper, into asm or SSE intrinsics or OpenCL.
ObjC's way of handling mundane data structures (strings, arrays, hashes) is (once you learn to stop worrying and love long sequences of calls to very long method names) very similar to how Ruby addresses the same problems.
ObjC lets you drop into vanilla C code when you want to.
ObjC doesn't impose GC.
ObjC implements a form of duck typing.
You might be surprised at how good a fit ObjC is for a game engine you prototyped in Ruby, as opposed to C++.
You can easily write C++ code without having to bridge ObjC's object system to C++'s object-and-generics system: provide a simple C API to your C++ libraries.
But the other thing is, one reason to do ObjC at all is to avoid all the heartache that comes bundled with C++.
PS: You got modded down. Baffling. Fixed.
- a proper module system;
- reliance on the primitive #import/#include which slows down compilation
- no namespacing, relying instead on conventions to avoid clashes
For the Windows build I'm using the excellent http://www.mingw.org/ Mingw32 environment. I compiled SDL and my other needed libraries myself and there's pretty much no code differences.
The only downside to mingw32 is that my target platform has full POSIX and mingw32 doesn't, so sometimes I have to choose carefully to use stdlib functions and not a POSIX function.
Why were you trying to write a game in Ruby to start with? You didn't "switch back to C++", you simply realized you were trying to use a wrench to tight a philips screw…
Floats for one aren't objects, and LuaJIT is probably 10x faster than Ruby.
My main point, however, and this in reply to your post (that I have no doubt it was honest and on the back of some tough thinking) was that you simply started using the wrong tool for the job and then, realizing this, found a more appropriate tool. Nothing wrong with that, but your post came across as "Ruby sucks so I'm going with C++".
Having said that, I'm glad you "saw the light" and I do wish you the best of lucks in your development endeavors! :)
And remember: your next endeavor might be in Ruby, C++, whatever… Just do some thinking beforehand and choose the right tool for the job to avoid "rotting code", which we all know is incredibly frustrating! ;)
And I'm not sure Ruby will be the wrong tool forever: there just isn't a way through some of the environment and implementation issues (yet).
A quick list: http://nuverian.net/2011/01/17/the-best-game-engines-for-ind...
As for what's "good performance," ask yourself: what's the clock speed of your CPU, and how much work are you really trying to do? Say you've got a 2 GHz CPU. A 300 FPS rate, is 2,000,000,000 Hz/300 Hz = 6.6 million clock ticks per frame, on a single core. A modern CPU can be really good about using those ticks very well. You can do some dumb blitting to figure out the I/O overhead for getting to the screen.
That said, you might consider Lua as a primary scripting engine for your game. It's got a lot of your standard scripting language perks, but it's also obnoxiously fast and has an incremental garbage collector. Furthermore, there's no GIL, and it's designed to be embeddable, making it a very powerful choice for game development.
As for Lua, Garry's mod runs almost entirely in Lua (outside of the source engine).
(By way of demonstration:)
ree-1.8.7-2011.03 :002 > 123.456.object_id
ree-1.8.7-2011.03 :003 > 123.456.object_id
I think you were absolutely right to switch from Ruby, I can't see the problems that you had getting any better unless Ruby lets you manage object allocation (in which case you could allocate to a per-frame memory buffer and just nuke it at the end of every frame).
And for x86/x64 and ARM, you can try LuaJIT to get even more zing (though you probably won't need to).
No-one is nailing down the definition of "game" in this entire discussion. For a FPS or game filled with live special effects, sure. For a chess game, a puzzler, or even a graphic adventure? Ruby's GC wouldn't be a problem at all (although Ruby has other issues that could well crop up).
He said he used www.libgosu.org for Ruby but the library also works with C++, so I'm wondering why he's switched to www.libsdl.org
I've done this before with Ruby and C. Two great tastes that go great together!
For example, in my (limited) experience, you have to draw the boundary between what's in Ruby and what's in C/C++ intelligently. If you're still doing most of your computation in C on Ruby Arrays and Hashes, you're not going to get much of a performance win at all.
Very nice post! I love seeing these kind of comparisons.
I had the same thought as Havoc's comment (not here, on your site): Why not use both languages?
A 1/60 frame skip rate sounds like nothing important, but your eye will see it easily and it's instantly annoying. It's not subtle at all, and not something you can write off. Everyone will be annoyed by it and then your product will be doomed.
(Edit) I do however agree that the frame rate is not that important. 30 fps ought to be enough for anyone. However, it has to be a really really smooth 30 fps; all the frames need to come out exactly 1/30 of a second apart. Not realizing this is where a lot of people go wrong. A smooth 30 fps looks much better than 120 fps to a human eye. A game framerate that isn't an integer divisor of your monitor's refresh rate is also a disaster (since it means the display will be skipping frames).
A complete game that people love, and is growing like mad, except for that damned skip at 60fps...
A very smooth 60fps game nobody plays.
Speaking as an avid gamer, that dropped frame matters, a lot. It's incredibly annoying to the gamer, and will produce an attitude of general discontent with the product that will earn it reviews like "sluggish", "slow", "unoptimized", and "chunky", none of which are exactly going to help you sell copies.
You might have missed the part where the author was saying that he wasn't even nearly done with feature implementation; the problem was only going to get worse as he added more garbage overhead. When you're talking about relatively expensive GC passes in a stop-the-world garbage collector, that dropped frame can turn into 150 dropped frames every 30 seconds pretty quickly (ie, a 2.5-second freeze/hitch), and that's enough to turn any player batty.