@valley: as I told you before, you can build a whole game (given that everything you need to write a game is supported by ShinyCocos && cocos2d-iphone) and put it on the appstore. You have to take a few precautions:
There's a weird bug that sometimes crashes your game. I think this is due to ruby VM colliding or being called when garbage collecting. I haven't been able to specifically locate it... (there are lots of messages I sent to the ruby-core list, but with not much response)
Apple won't like you to specifically advertise that your game was written in ruby and that your game is shipping a "custom" interpreter. We got around this by doing two things: "encrypting" our code (there's info about this in the project wiki) and not putting anywhere in the appstore info that we're using ruby.
About performance, I don't think there will be a big difference: all the hard stuff is written in C/Obj-C, ShinyCocos is just a thin layer... Although GC and callbacks do cost CPU time.
Finally, what I think will come out of this experiment is: ruby is a great scripting language, and really awesome tool to write games on, but we need to keep things fast as hell when writing iPhone games, so my next approach will be to use ruby to program the logic (just like ShinyCocos is doing right now), but with the help of llvm & friends compile that code to native arm/x86.
Benefits of that approach:
- rapid prototyping/developing (currently on ShinyCocos)
- avoid common memory handling mistakes (currently on ShinyCocos)
- code will run as fast as regular c/obj-c (not currently on ShinyCocos)
- apple can't say a thing, because you're not shipping a custom interpreter (not currently on ShinyCocos, but we can't ignore this if apple also ignores it)
However, for that I need time, and next week is the deadline for IGF mobile :-)... so no time to work on that until 2010