I’m pleased to announce a small helper library I’ve created, Nice-FFI. It sits on top of Ruby-FFI and makes certain things easier and more convenient. Nice-FFI started out as helper classes I made for Ruby-SDL-FFI (which is coming soon), but I decided to generalize it and make it its own library so that other people might get some benefit from it.
Even though it’s still young, Nice-FFI already has some useful features:
- With NiceFFI::Library, it’s easy to find libraries on all platforms. You can use e.g.
load_library('SDL') (instead of
ffi_lib) to look in platform-specific places. E.g. on Linux, it would first look for “/usr/local/lib/libSDL.so”, while on Windows it would look for “C:\windows\sys32\SDL.dll”. Linux (and BSD), Mac, and Windows each have a good selection of default search paths already, and it’s easy to add, remove, or change them using the NiceFFI::PathSet class.
- With NiceFFI::Struct, struct classes automatically get accessor methods for their members, just by calling layout. E.g.
layout :x, :int, :y, :int gives you #x, #x=, #y, and #y= for free. You can control which members get accessors using the
hidden module methods.
- If a struct member or function return value is a pointer to a struct, you can use
NiceFFI::TypedPointer( MyStructClass ) instead of
:pointer to get auto-wrapping. So, instead of returning a Pointer, a function would return a MyStructClass instance that holds the pointer.
- New struct instances can be easily created “from scratch”, e.g.
MyStructClass.new( :x => 1, :y => 2 ). You can initialize from a Hash, Array, another instance, or a pointer as usual. Struct attributes can also be dumped to a Hash or Array. And, structs have a nice #to_s method to show you the values of its members, for debugging.
All of the features are described in detail, with examples, in the docs (see especially docs/usage.rdoc, in addition to the class and method docs).
Nice-FFI is still young, though. So while I’d love for people to play around with it and give me feedback (and patches!), it’s probably not quite ready for prime time yet. It’s still under development, so the API may change suddenly. But if you are willing to tweak your code from time to time, I think you’ll find Nice-FFI to be very helpful. (Otherwise, just wait until 1.0, when the API stabilizes.)
You can get Nice-FFI:
Please send bug reports and feature requests to the issue tracker on Github.
This is a look back at last weekend’s RubyWeekend #3 game contest and the process of developing my entry, Droplet. You can read more post-mortems from the contest in the Rubygame forums.
What went right:
- I’m really happy with how the plants grow and change and move. I think I got the rustling to be pretty convincing, almost like it’s using a physics engine, even though it’s just some sine waves.
- I think the overall polish level is high, even if the “gameplay” is a bit limited.
- I’m glad I settled on the concept I did. I love making stuff like this, and the competition was a great motivator.
What went wrong:
- It took me the whole first day (8 hours) to come up with a concept. (This is typical for me, actually.)
- I spent the next two days just making the plant system…
- I didn’t manage to work in any real gameplay. It could probably be a pretty cool puzzle game if I invested some more time.
- Nobody likes my toy. Boo hoo hoo! … Just kidding. :P
What I learned:
- I learned a bit of how to use Gamebox. But I didn’t learn it very well or thoroughly, because I was in a hurry.
- I discovered how cool Garage Band is, although I didn’t end up using it.
- After the contest, I learned how to record video and audio in Linux using the aptly-named RecordMyDesktop, so that I could record a video of Droplet in action. I need to figure out how to convert it to a format that YouTube supports, though.
- I learned how utterly irresponsible I can be, participating in a game contest on a whim when I had work deadlines coming up… but it all turned out well in the end, so that’s okay! I have yet again avoided needing to learn a life lesson about personal responsibility. \o/
What I would do differently:
- Use a different system for drawing the plants. Probably image-based sprites that are scaled and rotated, instead of using drawing primitives. Then I could have gotten more visually interesting trees with less time-consuming coding.
- Use OpenGL. I think this game could have benefited quite a bit from OpenGL (or even better, OpenVG). The graphics would have been a lot smoother, I could have had more separate branches per tree, and the code would have been simpler to write, even without an image-based sprite approach.
- Probably not use Gamebox. I’m not saying Gamebox is bad, but it felt a bit restrictive and limited, and trying to learn a new framework while I was in a hurry wasn’t the best idea. More about Gamebox below.
On working with Gamebox:
Gamebox is interesting, and much more mature than its version number (0.0.6 as of this writing) might lead you to believe. The game contest helped flush out several bugs and shortcomings, but Shawn has been super-fast to fix them. I’m sure it will polish up very nicely as he gets feedback from more people.
In general, I am wary of frameworks. Certainly, Rails puts a bad taste in my mouth these days (despite my positive initial reactions two years ago). I tend to find frameworks restrictive, and would much rather be handed a set of building blocks to assemble. For one thing, a framework makes assumptions about what shape I want the final result to have. And I find that many frameworks assume more than they should, and make it too difficult to do things the framework creator didn’t anticipate.
Gamebox suffers from this a little bit, but not nearly as much as Rails does. This is evidenced by the fact that even an unorthodox game like Droplet could be made with it. For instance, a more rigid flamework would not have been able to handle the game objects being arranged radially or having no set appearance. There were some things that I had to work around, though:
- At the time I wrote Droplet, Levels did not have access to the InputManager, so I had to attach the event hooks to an actor instead. Shawn fixed the issue a day or two after Droplet was finished, though.
- Gamebox did not support the MouseMotion event type. Shawn fixed this during the contest, though, so I was able to use it. (Thanks, Shawn!)
- There is no clean way to set the window title. I had to work around this by setting it in Level#draw.
- Gamebox’s sound support is geared towards fire-and-forget playback, whereas Droplet required the ability to play a sound in a loop and constantly adjust the volume level. Shawn will probably have this fixed within 5 minutes of reading this, though. ;)
There were a few other things that felt like work-arounds to me, but which I think I could have done better if I were more familiar with Gamebox, especially its Behaviors system.
Would I use Gamebox again? Sure! Especially for more conventional games, Gamebox is a great way to get a head start on your game. Even weird stuff like Droplet can be accomodated without a great deal of trouble. And at the rate Shawn is improving it, I’m certain Gamebox will soon be one of the most kickass game frameworks around.
… at least until Rebirth comes out. >;)