Why I switched from Ruby back to C++

http://chrismdp.github.com/2012/01/why-i-switched-from-ruby-back-to-c-plus-plus/

by chrismdp • 15 years ago

143 94 15 years ago

chrismdp.github.com

chrismdp17• 15 years ago

I'd be interested in HNers' views on whether I made the right call.

Seems to me that no matter what the language du jour may be, games are still often written in c++. When you're not getting the performance out of the tools you're using and you've spent some time trying to work around the problems, I think it's the right call to switch tools.

chrismdp17• 15 years ago

Thanks: after three days I think it was the right call. I just found myself burning too much brain energy on things I didn't want to have to care about.

cheald4• 15 years ago

Speaking as a huge fan of Ruby, I think it's absolutely the wrong language to write games in, because games are enormously sensitive to runtime fluctuations, and as you found out, Ruby has them. In particular, a stop-the-world GC is just never going to give you satisfactory performance, unless every GC pass happens in <1ms and never happens more than once per frame.

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.

chrismdp17• 15 years ago

I'll look into LUA. Never used it back in my games dev days as it was just coming into vogue.

ntkachov• 15 years ago

Usually the way you solve GC issues is by either not allocating after some initial massive allocation, or by running the GC constantly and having it clean up bits and peices every frame. I don't know enough about ruby to know if this is possible but this is how you handle GC in Java and C#.

As for Lua, Garry's mod runs almost entirely in Lua (outside of the source engine).

petercooper• 15 years ago

I think it's absolutely the wrong language to write games in, because games are enormously sensitive to runtime fluctuations

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).

udp• 15 years ago

One advantage of using C/C++ is that (performance allowing) it's going to be relatively easy to port to Android's NDK or iOS.

anonymoushn• 15 years ago

Writing everything in C++ is not my idea of fun. It's definitely possible to write almost all of the game code in a scripting language. It would be reasonably easy to abstract all the native APIs you want, but you could also just let someone else do it: http://love2d.org/

fleitz2• 15 years ago

ruby excels where time to market and RAD are more important than performance, and where the standard and other libraries work well. Ruby saves lots of time doing things like CRUD operations where you're basically mapping on set of fields to another in a predictable way. When performance and memory are an issue and you can't trivially scale your code (eg. More processes or more machines) C++ is a big win.

tjogin• 15 years ago

Of course you did, and I say that as a self-described Ruby programmer. What I really want to know is what gave you the idea that it might be a good idea to use Ruby for a project so obviously not suitable for Ruby?

teamonkey2• 15 years ago

Just out of interest, why did you choose not to use Gosu in your C++ port?

trptcolin• 15 years ago

I hope it was because of this: http://gosu-lang.org/comparison.shtml

ww5202• 15 years ago

You might want to explore Lua as an alternative. Lots of games are written in Lua/C/C++ combo. Low level primitive routines in C/C++ and high level game stuff in Lua.

benburkert• 15 years ago

I wonder if he gave Rubinius a go before switching to C++. IANAGD, but i'm guessing some of it's features would benefit game engines: Tunable GC, profiling (http://rubini.us/doc/en/tools/profiler/), JIT/LLVM. It wouldn't solve the C extension problem (maybe FFI does?) or distribution though.

chrismdp17• 15 years ago

No, I didn't. I love the features Rubinius gives you, but Windows support still needs a lot of work, and if I'd dived in to help, I'll never ship the game.

boneheadmed2• 15 years ago

Nice write up. I wrote my own 2d game engine in C++ a while back. Switching to Ruby was great, but I never made any games. I did make a couple of JavaScript HTML 5 games. But here again speed is a limitation, and so am looking into C (and eventually Objective C) to eventually do some iPhone game making. As great as it would be to make games soley with scripting/interpreted languages, I don't think we're there yet.

chrismdp17• 15 years ago

Easy porting to iPhone in the future is another big plus I should have mentioned in the original post.

tptacek3• 15 years ago

The ObjC object model is very similar to Ruby's object model.

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++.

shaunxcode2• 15 years ago

what about lua/love/corona?

boneheadmed2• 15 years ago

I've thought of using Lua and if I recall correctly, work has been done to develop iPhone games with Lua as well? Ah, where is the time?

subwindow• 15 years ago

I wonder if switching to JRuby wouldn't have solved some of his problems? I'd imagine that distribution is much easier on JRuby. I suppose the issue is with libraries, but I'm not familiar with the libraries he mentioned.

chrismdp17• 15 years ago

Possibly, but I'm much more comfortable in C++ than Java. I also get a much easier route to iOS if I stick with C++.

prophetjohn• 15 years ago

With JRuby, you wouldn't have to be comfortable with Java. You get to use Ruby with the benefit of it running in the JVM.

hkarthik• 15 years ago

Sounds like he's wanting to use a lot of native C++ libraries, so I imagine he'd still run into performance problems even if he found a way to use JNI with JRuby.

chrismdp17• 15 years ago

UPDATE: In case anyone is interested, I've just added a screenshot to the blog post by (very) popular demand. It's not final artwork, and it's only a few days work!

http://chrismdp.github.com/2012/01/why-i-switched-from-ruby-...

levifig2• 15 years ago

This sounds very "link bait-ish"…

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…

-.-

chrismdp17• 15 years ago

I suppose it does: but it's the honest truth. I have two months of ruby code that's rusting now, and it was quite a difficult post to write.

levifig2• 15 years ago

That was not the point of my comment. It was a realization of how it came across (aka how I got here).

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! ;)

SomeCallMeTim• 15 years ago

Ruby was simply the wrong language for games. There's a reason a huge percentage of real-world games use Lua for scripting.

Floats for one aren't objects, and LuaJIT is probably 10x faster than Ruby.

zizee3• 15 years ago

A more honest title would by "Why C++ is better than Ruby for game development".

phzbOx• 15 years ago

tl&dr: switch for performance but miss Ruby

frankPants2• 15 years ago

cough ObjectiveC

frankPants2• 15 years ago

This post should be titled, "Why I fucked up by choosing Ruby to write a game." - Or "What the fuck was I thinking"

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.

chrismdp17• 15 years ago

Heh :) I'll take the bait :)

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.

eaurouge• 15 years ago

The title of your self-submitted post is misleading. The bait post you're referring to stated the obvious, albeit in highly charged language.

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.

kenjackson2• 15 years ago

While what you say may be 100% true you might be shocked by the number of Ruby and Python devs I talk to who tell me that Ruby can do anything that C++ does if you're even a half-decent Ruby or Python dev. I've literally asked people, "What about something like Gran Turismo 7?" And I've literally been in rooms where every dev there (none game devs, all web devs) basically said if they were writing it in Ruby it could be done, but they wouldn't trust Sony devs to be able to do it.

This may not be the case for all Ruby devs, but I think having these stories out there is still useful.

mileszs2• 15 years ago

For what it's worth, I help to organize a fairly active Ruby group, and I am certain that, if not zero, nearly zero of us would make this proclamation. In fact -- and I mean not to attack you, but just to illustrate how incredulous I am -- I tried to think of a reason there might be for you to fabricate or exaggerate that story. I don't really think you did, but my mind went there.

sliverstorm• 15 years ago

First, those are all pretty fantastic claims that need support.

Second, technically speaking of course it can do anything C++ can do. The question is can it do it well, or fast?

jtc3312• 15 years ago

These sound like designers turned quasi-developers rather than serious programmers. I don't know anyone that actually understands real software development that would make this claim.

tedukUsziWos• 15 years ago

It's not because it would not be wise to write a Gran Turismo 7 in an interpreted language such as ruby or python that writing any game with such language wouldn't work. Not all games have such specific requirements as Gran Turismo 7 where huge teams want to extract the most power out of some very specific piece of hardware.

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.

dasil003• 15 years ago

I'm a full-time ruby developer (have been for 6 years). I do web development exclusively and all the experience I have with C and C++ came in college. In other words, I'm pretty ignorant when it comes to game development.

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.

erikpukinskis• 15 years ago

This post is mean, and has no place on Hacker News. It's fine to say there's no reason to ever use Ruby for a game, but it seems like the main purpose of your post is just to call into question the OP's intelligence and experience.

zizee3• 15 years ago

I thought he was just calling into question the link-baity title.

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.

ww5202• 15 years ago

It is mean. That's nothing wrong with trying new thing even if most people are saying it's the wrong choice. And there's no shame in failing in the process. People will say, I told you so. But you never know until you have tried it, and you would learn a lot in the process. And sometime you might just have a break-thru.

gravitronic2• 15 years ago

I'm using SDL for writing a DJ application and have it cross-building on Linux, Windows, and the target platform (HP TouchPad).

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.

andrewflnr• 15 years ago

Just out of curiosity: why is compiling on Windows important if your target is POSIX? Is it just for development convenience?

gravitronic2• 15 years ago

Yes. For other reasons I am generally running Windows.

justinhj• 15 years ago

A good takeaway from this is make your tests performance related. Since the op is using unitests already, a test that updated the game loop for a few minutes, rendering the target number of objects and failed if a frame dropped, would have saved a lot of wasted development.

mjbellantoni2• 15 years ago

I don't why this needs to be an either/or proposition. Write your program in Ruby. Where it needs speed, write the pertinent bits in C++.

I've done this before with Ruby and C. Two great tastes that go great together!

chrismdp17• 15 years ago

I looked at this, but the stop the world GC would still kill the frame rate from time to time sadly. Also there's a large amount of inefficiency in the object translation layer between the two languages.

mjbellantoni2• 15 years ago

I can believe that, but wonder if it needs to be so.

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.

epynonymous• 15 years ago

it's simple, ruby is about scale out, not scale up. and rails helps you to build websites faster. multi-player games would probably be very fast to write compared to c++, however, the code will certainly not be optimized as well as c++, it's an interpreted language for gadsakes!

rjurney2• 15 years ago

The author seems to be more interested in obsessive technical improvements than shipping a game many people want to play. One slow frame out of sixty prompts a rewrite? Product doomed. Wait until someone complains to fix anything. Something tells me that frame should not be priority one, but it is. Why?

apenwarr• 15 years ago

You are completely right for things that don't involve real-time video (like games do).

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).

rjurney2• 15 years ago

Would you rather have:

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.

jt2190• 15 years ago

Hi Chris,

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?

chrismdp17• 15 years ago

Thanks! I may still do that, if I makes sense to do so and I can distribute it easily enough.

nevinera• 15 years ago

"Why I switched from screwdrivers back to the hammer."

Because, while pounding in a few hundred nails with my trusty flathead, I noticed that it was taking really a great deal of work.

ansgri• 15 years ago

After working 1.5 years on soft-realtime video processing systems (and game development fits this category), I feel like there's no real alternatives to C++. Because (1) when you have performance problems you can inspect the code in the disassembler and get full control of what's going on, and (2) compilers now are really smart (think msvc11 and gcc 4.6), so it just rarely make sense to sacrifice 10x speed for 3x increase in code brevity.

Of course, sometimes you have to dive even deeper, into asm or SSE intrinsics or OpenCL.

lelele• 15 years ago

What about using an higher level language for game logic, and optimizing critical section of code with C/C++?

jrockway• 15 years ago

I think the author's problem is not choice of language, but rather choice of architecture. He notes that he was passing a lot of float objects between Ruby and C, eating up valuable garbage collection time. The problem here is not the bridging of Ruby to C, but rather the wrong choice of data structure and design. Ruby should pass high level requests to the (C-based) rendering backend; instead of passing "push a vertex at (1,2,3)", the requests should be like "draw a spaceship at (1,2,3) flying forward with velocity vector (1,1,0)". The means you're going to be writing the core of your game in C, but things like AI and level design will all be handled in Ruby. (I think pretty much every commercial game works like this.)

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...)

atomicdog• 15 years ago

>(I think pretty much every commercial game works like this.)

Is it common for commercial games to write AI in Ruby now?

m_for_monkey• 15 years ago

Not necessarily in Ruby, it may be Scheme or some proprietary in-house scripting language.

AndrewDucker• 15 years ago

Lua is the most common language, I believe. But the pattern still holds.

lallysingh• 15 years ago

What I don't get is why you're writing it from scratch? There are over a dozen high-quality C++ game engines you can use.

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.

Why I switched from Ruby back to C++

Related Stories