• sprite sheets
• sprite sheet bodies (sets of sprite sheets with states and actions)
• box2d

Check it out

In a nutshell, you use “using” to inject methods to an IEntity object that allow behavior to be dynamically added, with the option of chaining the methods. The statically injected methods add components to the entity where needed.

Read here to learn about Pushbutton Engine components.

Let’s dive in with an example, and explain as we go along.

Building a button

Assume you are in the setup() method of an IPBContext instance. You’ll need to import (using import) the following:

using com.pblabs.components.input.InputTools;
using com.pblabs.components.scene2D.ImageTools;
using com.pblabs.components.scene2D.SceneUtil;
using com.pblabs.components.input.InputTools;
using com.pblabs.engine.util.PBUtil;

You’ll need a SceneLayer to add the button to:

var scene = addSingletonComponent(SceneUtil.MANAGER_CLASS);
scene.sceneAlignment = SceneAlignment.TOP_LEFT;
var layer :BaseSceneLayer<Dynamic, Dynamic> = scene.addLayer();

Then create the button like so:

var button = createBaseSceneEntity()
    .addSvg(layer, Resources.list.TITLEBAR, [new SvgReplace("$T", "The Title")])
    .makeReactiveButton()
    .initializeEntity("titlebar")
    .setSceneAlignment(SceneAlignment.CENTER);

Let’s go through it. Firstly, all of the above chained methods are static methods defined in one of the using classes. Except for the first call that creates the IEntity object and the initializeEntity call, all the calls follow a similar pattern:

1. Check if the component needed for the required functionality is present.
2. If the component is missing, add it.
3. Add the functionality, data, behavior, or whatever.

A (hopefully) clear example is the makeReactiveButton call:

public static function makeReactiveButton (e :IEntity) :IEntity
{
    ensureMouseInputComponent(e);
    var mouse = e.getComponent(MouseInputComponent);
    makeReactiveButtonInternal(mouse);
    return e;
}

Given an IEntity, it ensures that a MouseInputComponent is present, then adds the signal listeners that make the component respond visually to mouse/touch clicks.

The great thing about this is that you only have to import the using class. The methods therein ensure that the appropriate components are added or set up correctly. The IEntity/Component architecture of PBE/Hydrax allows you to add (or even remove) behavior at run time, without having to resort to building complicated and unwieldily class hierarchies.

This makes it very easy to swap out components for your own, or add any kind of behavior to your game objects in a clear and readable way.

Also, now your code libraries for building objects consist of mostly static calls. This helps to prevent unnecessary dependencies and generally minimizes bugs as the methods are not tracking any state information.

I hope this post was somewhat informative and readable. Criticism and feedback welcome!

This post will be linked shortly to a concrete demo with source.

Some links:

• “using”
  • http://scwn.net/2009/05/23/injecting-methods-into-haxe-classes-with-using/
  • Official haxe docs

Two examples where you might need this:

• Flash <-> javascript communication. For example, calling asynchronous javascript functions from Flash, such as when your Flash game wants to make Facebook API calls from javascript (this is often better or faster than waiting to use the Flash Facebook API).
• When Node.js is the remoting server. Node.js is designed around asynchronous calls. Having Node.js block until it finishes a potentially time-consuming remoting call defeats the purpose of using Node.js

I’ve added some extra asynchronous remoting classes in hydrax that solves this problem. I’ll go though an example to illustrate how the classes are used. In this case, I’ll assume that the server is Node.js and the client is Flash or JS.

Firstly, we’ll define a ‘service‘ that the server is offering to the client. It’s just an interface that defines the methods the client will call:

interface RoomService
{
    function getRoomNumber (cb :Int->Void) :Void;
}

Note you are getting the result of this call from the callback function.

On the client

The client will implement RoomService via extending haxe.remoting.BiAsyncProxy:

class RoomServiceProxy extends BiAsyncProxy, implements RoomService
{
    public function new (c :haxe.remoting.AsyncConnection)
    {
        super(c.resolve("roomservice"));
    }
}

Note that you don’t need to manually add in the methods from the RoomService interface: BiAsyncProxy does it for you! Thanks to haxe macros: it examines RoomService interface, extracts all the functions, and adds them to the RoomServiceProxy class, similar to haxe.remoting.AsyncProxy. It’s not strictly a magic class, but it works the same way.

On the server

class RoomManager implements RoomService
{
    function getRoomNumber ( cb :Int->Void) :Void
    {
        //We'll assume the room number is 4.
        cb(4);
    }
}

Then, in the server initialization:

var context = new Context();

var roomService = new RoomManager();
context.addObject("roomservice", roomService);

//Add the context to the html connection handler
var serviceHandler = new NodeJSHTMLConnection(context);

That’s it!

Now you have fully typed asynchronous calls on both the client and server, and the client and server code is completely separate (useful for untrusted client code).

Asynchronous flash <-> javascript

This works much the same way, except you need to use this class in Flash:

... = haxe.remoting.ExternalAsyncConnection.jsConnect("async", context);

The Flash-js async remoting connection stores the calls in a hash, when the callback is returned from javascript, it returns the original hash id that called it.

Enjoy!

The main advantanges of svgs are:

1. Scalability: whatever scale or resolution the platform (smartphones, desktopss) they always look sharp.
2. Structure: vector graphics are composed of shapes, and these can be analysed and modified at runtime.

In Flash, one way to get svgs into your application or game is to embed the svg directly. However, this converts the the svg into a DisplayObject with no access to the underlying elements. I would like access to the svg elements to place UI elements, such as buttons, on some anchors, where the anchors are svg sub-elements. This allows you to modify, re-use, or dynamically create your user interfaces without resorting to changing large numbers of files. And I would like my UIs to look as similar as possible across multiple platforms/resolutions without having to change a ton of code.

So I’ve created an SVGComponent for Hydrax/Pushbutton. This component is a SceneComponent with the following functionality:

• Accepts svg resources as text. So you can simply embed or download svg files, either as haxe resources, or downloaded text files. No more samhaxe.
• Displays svgs in Flash using svgweb.
• Displays svgs in JS on the canvas element using canvg (thanks Gabe Lerner for being so resposive to bug fixes!).
• Displays svgs natively in JS (as an alternative to the canvas). This gives much better performance on iOs (compared to the HTML5 canvas).
• Can be placed relative to a parent SVGComponent. See below.

Examples of simple UI showing 3 buttons automatically placed at anchor locations defined by another svg image.

• Flash
• Html5 Canvas
• Html5 Css

SVGComponents (or any SceneComponent) can be placed at the location of an svg anchor. What is an ‘anchor’? It is a svg rectangle labeled (in Inkscape) with the prefix ‘anchor’:

This label tells the HierarchyManager that other SceneComponents (like DisplayObjects in Flash) can be set as children, and they will be properly positioned. SVG images can be set as sub-images in e.g. buttons, allowing the creation of buttons with icons, without having to create a whole new button.

This allows game developers to create UIs and other game graphics in open source tools like Inkscape and use the assets with no modification for all major web platforms.

The full source and example are available from the github repository under demo/svgUI.

Select an enum (or start typing to narrow choices) and hit enter on your chosen enum. A switch statement with all enum constructors is created. SuperAbbrevs is applied to the insert, so hitting tab will cycle from the argument to all the cases:

I have to admit I quite enjoy adding code completion functions to the Haxe plugin. Now that the pipeline is set up, it’s quite easy. This took about half an hour. I justified this because I’m writing a lot of game logic which means a lot of switch statements. Hopefully this will save me time in the long term.

1. Flash
2. Html5 Canvas
3. Html5 Css

There is no change in the game code in these demos. The only differences are compiler switches, and the HTML page that embeds each of them. I’m going to repeat for emphasis: there is no change in the code for device input (or anything else). The mouse pans the parallax scene identically on flash, HTML5 canvas, and CSS transformed div and image elements.

Where needed, individual game components use platform specific methods that are aware of the target platform, but these are well isolated and are kept as low level as possible.

As you can see, CSS transforms are pretty performant, and definitely better on iOs devices. Touch screen phones and ipods etc have pretty good screens, meaning the canvas element has to be pretty large to fit the entire screen, which then runs like a dog. By using CSS transforms, you can use static images or animate using mini canvas elements, and avoid having to redraw large swathes of the screen.

Other projects aimed at cross platform rendering copy the flash API for javascript (Jeash) and C++ (NME). I think this is too much work and inflexible. If you are going to make games, use a game engine, and make that platform agnostic. Reimplementing the flash API is largely unnecessary and means that you have to write a lot of code to do a little, and you’ll also end up fitting all the resource loading, device input etc etc into the flash way, with the big assumption that it’s the best way.

If another platform came along tomorrow, the only classes to write anew would be a resource loading class, raw device input, and raw rendering (and sound). The higher level stuff is all handled by haxe itself then the game engine on top of that. It means as a developer, you are not chained to a particular platform, and can move to other platforms with relative ease.

Were these examples actual playable games, they are deployable almost anywhere: desktop computers/laptops (flash, c++), android phones (flash), iOS devices (HTML5 stuff). Did I mention Haxe compiles to multiple server-side languages as well?

It seems that the paradigm of write once/run anwhere is served better by a platform agnostic language, rather than a platform needs to be developed for all platforms.

The source for the engine and these demos are available here.

If I can find a javascript frames-per-second counter, I’ll add them to the demos.

Markdown is a nice way to write blog type articles, providing a balance between readability and functionality. I flirted with dedicated blog editors, but as usual, fell back to my favourite editor, jEdit. Unfortunately, getting the markdown formatted post into the blog itself was cumbersome. So, I wrote a beanshell macro that called a markdown shell command that copied the markdown->HTML formatted post into the clipboard.

Now my workflow is:

1. Write blog in markdown.
2. Press keyboard shortcut bound to markdown macro.
3. Paste into blog.

To do this, download the markdown perl script here. Create a shell script called markdown that calls Markdown.pl with the first argument as a file and copies the results into the clipboard (Mac only sorry):

The markdown script:

#! /usr/bin/env sh

Markdown.pl --html4tags $1 | pbcopy

Add the markdown script to your $PATH, and make it executable.

Then, in jEdit, create the macro:

runCommandInConsole(view,"System","markdown " + buffer.getPath());

and save it as e.g. Markdown2Clipboard.bsh. Now you can bind a shortcut to the macro, and it will apply the markdown converter on the current buffer in jEdit. Then you can just paste the HTML into your blog.

A practical example. Say you design a 2D top down game. Later on, you decide that an isometric view is more suitable. That could involve a single line of code change, or a single modification to a level XML file. Unfortunately Pushbutton is written in actionscript (==Flash).

Step in HaXe. HaXe allows you to write in one language and compile to many others (currently, Flash, php, javascript, C++, neko). Compiling for multiple platforms is a huge plus, allowing a developer to write in one language and deploy the game on multiple platforms. Of course, deploying to multiple platforms means that certain low-level operations are unavoidably platform specific, notably loading resources, device input (mouse, touches, gestures, keyboard), and rendering. There are moves to unify the rendering (Jeash, NME) so that the flash rendering API works on the HTML5/javascript and C++ platforms identically, but this may not be optimal in all cases.

The modular, component based archituecture of PBE is a natural fit to HaXe. The platform specific parts can be written as components, allowing you to easily isolate these parts and swap them out depending on the platform.

So I’ve began porting PBE to Haxe. The git repository is here. I’m endevouring to keep as close to the original architecture as possible, however often to make a class or component more general than AS3 means a significant rewrite. At the very least, the core interfaces will be very similar if not the same.

In my next post I’ve documented some examples of compilation to different platforms (Flash, javascript+css, and javascript+HTML5 canvas).

There are many other good reasons to use the Pushbutton Engine, I would encourage you to check out the website.

Update: reason why carbonite failed was because their client doesn’t work on hackintoshes!  That the first software I’ve encountered that doesn’t work on a hackintosh due to the need for mac hardware.  That’s quite lame Carbonite.  Why are you so failingly special?