After long hiatus, work proceeds in dribs and drabs on RocketHaxe 2.0.  Most of the widgets and core algorithms in RocketHaxe 1.0 were solid, but I wanted to streamline the entities and overall screen management/game flow.  The latter turned out to be not so bad on second look, but has been cleaned up a bit.

The former I’ve been thinking about a lot.  On the one hand, I want to keep the library well scoped, and focused on small, relatively simple games.  It’s not supposed to be the foundation of a decades-long franchise production effort.  It’s also got to work in Flash on low-end machines, as well as limited Android mobile devices.  That said, I strongly prefer more declarative approaches and am a big fan of component based architectures.  So with the redesign I’ve been trying to walk a line between the two: Enough component style design to simplify the object hierarchy; not so much to be overwhelming or hurt performance.

It’s still in flux as I think about the design a bit, but the basics are in place for things to be once again moving around and such:

(the demo display is wider than this blog, so the ball goes off to the right a bit)

Code for that demo is fairly straightforward; excluding the imports declarations, this is all it takes to setup and launch the ball:

class Main
  extends com.rocketshipgames.haxe.Game
{

  private function new():Void
  {
    super();
    trace("Balls Demo");

    var game = new com.rocketshipgames.haxe.ArcadeScreen();

    //-- Create a ball!
    var ball = new Entity();

    var kinematics = new Kinematics2DComponent({ xvel: 200, yvel: 200});
    ball.addComponent(kinematics);

    var bounds = new Bounds2DComponent();
    bounds.setBounds(BOUNDS_DETECT,
                     25, 25,
                     Display.width-25, Display.height-25);
    bounds.offBoundsLeft = bounds.bounceLeft;
    bounds.offBoundsRight = bounds.bounceRight;
    bounds.offBoundsTop = bounds.bounceTop;
    bounds.offBoundsBottom = bounds.bounceBottom;
    ball.addComponent(bounds);

    ball.addComponent(new BallShape(game));
    game.world.entities.addComponent(ball);

    //-- Start the game
    flash.Lib.current.addChild(game);

    // end new
  }

  // end Main
}

The BallShape component is just a holder for some Flash DisplayList geometry:

private class BallShape
  extends flash.display.Shape
  implements com.rocketshipgames.haxe.component.Component
{

  private var position:Position2D;

  public function new(parent:flash.display.Sprite):Void
  {
    super();

    graphics.beginFill(0xFF0000);
    graphics.drawCircle(0, 0, 25);
    graphics.endFill();

    parent.addChild(this);
  }

  public function attach(containerHandle:ComponentHandle):Void
  {
    position = cast(containerHandle.findCapability("position-2d"),
                    Position2D);
    update(0);
    // and attach
  }

  public function detach():Void { }

  //------------------------------------------------------------------
  public function update(elapsed:Int):Void
  {
    x = position.x;
    y = position.y;
  }

  // end BallShape
}

One of the big things in there is that I’m trying to avoid having to send/receive signals for every little thing, like a position update. It just feels like a lot of overhead to incur for constantly occurring tasks. So components are able to fetch each other, and it’s expected they’ll hold on to pointers and interact directly to some extent, particularly the core in-library capabilities like kinematics and collisions.

However, the mechanisms are there to code that way if you wish, which could make sense for higher level game events like taking damage. Just like in RocketHaxe 1.0, the overall game world provides for signals, states (properties), and scheduled events. But that’s been repackaged and reused such that each entity actually instantiates those mechanisms internally as well if any component wishes to use them. So you can do things like have your collision response throw a damage signal that any number of other components in that entity then process.

Where this all gets tricky is with collision physics and graphics, because they’re both intertwined with other mechanisms outside of the entity itself, with some precise execution ordering requirements. So I expect this to change a bit more, but it’s not half bad the way it is now.