Game Development Reference
In-Depth Information
Wrapping It Up
Our journey into the world of game development has come to an end. We have learned
enough to produced a playable game, yet only scratched the surface. Writing this topic was
a very enlightening experience, and hopefully reading it inspired or helped someone to get a
start.
Lessons Learned
Building this small tanks game and learning about game development with Ruby certainly
had some nasty bumps along the way, some of them made my head hit the ceiling.
Ruby Is Slow
This shouldn't be a shocker, because Ruby is a dynamic, interpreted language, but how
exactly slow it is at some points was a staggering discovery. Probably the best evidence
is that drawing map tiles off screen using native extensions was actually faster than doing
Camera#can_view?
checks that involve simple integer arithmetic and range checks.
If your game is going to deal with large number of entities, Ruby will start letting you down.
Dreaming about going pro? Go for C++, you won't make a mistake here.
Knowing this, keep in mind that Ruby is a wonderful language, that has it's own strengths.
It's great for prototyping and dynamic things. Some 5-10 lines of Ruby could translate into
50-100 lines of C++. Also, knowing multiple languages makes you a better developer.
Packaging Ruby Games Sucks
Unless you are releasing your game for tech savvy guys who can
gem install
it, get
ready to go through hell. There is no nice and easy way to create a standalone executable
application from Ruby code that involves native extensions. And you will go through hell
once for every operating system you want to publish your game for.
That's not everything. Want to use the latest Ruby version? Check if you can make a
package for it in your target OS before you start coding. Thinking of using something that
relies on ImageMagick? Too bad, you probably won't be able to package the game into a
native standalone app, at least on OSX. If you are planning on releasing the game, package
