Two bits of news about Rubygame and Rebirth today.
First, I laid out some goals / guiding principles for Rebirth. I don't know if they're of interest to anyone else, but here they are:
- Ease of use. It should be natural to express game behavior, without needing to jump through hoops. Use of defaults and constraints to suggest a course of action and reduce the "burden of choice" on developers.
- Flexibility. Rebirth should be able to handle games of many types and genres; physics or non-physics, action or slow-paced.
- Object-oriented. It should focus on game objects and how they behave and interact, not on the mechanics of image blitting and event management.
- Examples. Plenty of running example games to help users get started and see how the library can / should be used.
- Documentation. Every module, every class, every method documented, plus tutorials with examples about various important concepts and features.
- Behavior-driven development. Spec first, then implement. Full spec coverage, master branch is always green.
- Small, incremental releases. Every feature should be a release, very release should add or refine a feature. Avoid build-ups.
These goals (especially 3, 4, 6, and 7) reflect what I consider to be Rubygame's shortcomings.
Second, it's becoming more clear that Rebirth could be just a layer on top of Rubygame and ruby-opengl. In fact, that's just what I did last summer, in the original Rubygame 3.0 branch. Really, the work I'm doing now is just another refinement of the ideas that I was thinking last summer. (There's probably some good code I can lift from that branch.) So, it might be that Rebirth will be an add-on to Rubygame, rather than a replacement.
There's also the possibility of incremental revisions to Rubygame to bring it closer to my goals with Rebirth. The problem there is that it's a slow process, and that carries the risk of losing interest. It would also lack the freedom to make radical changes that you get with something new.