81–90 of 100 posts
Earlier quoted context omitted.
I hope it was because of this: http://gosu-lang.org/comparison.shtml
Wrong Gosu. 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'd be interested in HNers' views on whether I made the right call.
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 That said, you might consider Lua as a primary scripting engine for your game. It's got a lot of you…
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).
Earlier quoted context omitted.
Obj-C++ is working well for me so far and the STL is much better than Obj-C's awkward and slow collection classes for anything that needs to run fast or that requires significant algorithmic complexity.
One of the nice things about going back from Ruby to a C language is, it's hard to think of anything you could do in the C language that would be as non-performant as Ruby. As slow as ObjC's collections are, they're faster than Ruby's.
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…
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…
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.
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.
Earlier quoted context omitted.
what about lua/love/corona?
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?
For some great examples of 'next generation' Lua-based engines to do cross-platform development, check out moai: http://getmoai.com and maratis3d: http://maratis3d - Both tools are excellent resources for people who want to write games in a smart, friendly, efficient (quite fast!) language..
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 vert…
Is it common for commercial games to write AI in Ruby now?
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!
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.
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.
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 vert…
>(I think pretty much every commercial game works like this.) Is it common for commercial games to write AI in Ruby now?
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 vert…
>(I think pretty much every commercial game works like this.) Is it common for commercial games to write AI in Ruby now?