Rubygame 3 in February

January has been a very, very busy month for me, and so there hasn't been too much development on Rubygame lately. Fortunately, February will have more time for Rubygame — especially because I'm scheduling an hour or two of Rubygame time into my daily routine. I'm also planning to make a brief daily blog post during development, chronicalling my progress.

Here's the plan for 3.0.0. (Whoa, a plan?? It's like I'm taking this seriously, or something!)

Revamping Sprites

The first goal for the next version is to revamp the sprite system:

  1. More feature-rich and structured Sprite system
  2. New Polygon collision shape
  3. Integrate with Chipmunk physics library
  4. Leave room for later expansion (esp. with OpenGL integration)

The new system is almost certainly not going to be 100% backward compatible; and that means the version will be bumped to 3.0.0 (since Rubygame follows the so-called "rational versioning policy").

Revamping Clock

And as long as we're breaking backward compatibility, I plan to take the opportunity to break some other stuff in ways that ultimately improve them:

  1. Clock may use seconds (rather than milliseconds) as the base unit of time. That means arguments to Clock#delay et al would need to be scaled down by a factor of 1000.
  2. Clock will use Ruby's sleep command for delaying, rather than SDL's; this allows Rubygame apps to be multithreaded with Ruby's threads. (SDL's delay function would pause all threads, which mostly defeated the purpose of using multiple threads.)
  3. Clock#tick will no longer return a time in milliseconds since the last tick. Instead, it will return an instance of TickEvent, which has several data fields: time since the last tick in seconds, same but in milliseconds, timestamp for when the event was created, and the id # of the tick (starts at 0 for the first tick, increments one for every tick).
  4. Clock's framerate monitoring system is being rewritten to be more useful. The current, idiotic implementation returns the average framerate over the entire lifespan of the Clock, so it tends to level off over time, even if the framerate is fluctuating.

What It Won't Have

  1. The new hook-based event system. That will come later. Probably 3.1.0.
  2. The new camera/scene/object system. Again, that will come later. The new Sprite design will anticipate it so that it can be added without breaking compatibility. I'd expect this as 3.2.0.
  3. OpenGL integration with sprites. Also later. This will be 3.2.0 as well.

Schedule

  • Week 1: API design. Not a single line of code will be written during this period.
  • Week 2: Chipmunk development. I plan to (temporarily) fork Chipmunk to expand it's Ruby API as needed. At the end of this period, patches will be submitted to the Chipmunk project, but the forked Chipmunk will be packaged up in Rubygame 3.0.0.
  • Week 3: Sprite development. Added functionality and integration with Chipmunk.
  • Week 4: Clock development (mostly complete already), general cleanup / prep for release, and overflow time for the other development periods.

Comments

shevy/shevegen@linuxmail.org submitted a comment on #

yay, go jacius go!

Have something interesting to add to the discussion? Email your thoughtful comments to comments@rubygame.org.