Germination X: More on platform independence

More detail on yesterday’s HTML5 canvas version of Germination X. The game engine it uses (known in the source code as “truffle”) is carved up into several layers in order to allow it to make use of HaXe’s cross platform abilities. This is exactly the same concept as used with console games – you set up some standard interfaces to be used from the game code, and implement them for each target at the lower level. The main thing it to make sure you continually build and test both versions.

Here’s a diagram with rounded corners:

There are a few things in the game code I needed to go directly to flash for, one was the glow effect on the plants owned by the player – using a filter. The other was doing an image pixel colour lookup to get the emotional colours for the spirits – both of these are switched off in the canvas version, to be fixed later.

One of the things I’m most impressed by is the ability to send a HaXE closure to Javascript code, store and run it from there (for example on those pesky mouse events on sprites). Of course this works as it’s all Javascript in the end, it’s just one of those cool things that takes you by surprise.

Germination X in HTML5 canvas

I’ve spent a couple of days on an experimental not-quite-working-yet port of Germination X to HTML5. Port is probably a slightly misleading word, as it’s actually running exactly the same HaXE code, it’s just compiled to Javascript rather than swf with a load of extra Javascript filling in the stuff needed to replace Flash. The game engine that Germination X is built on is now officially cross platform! It’s great to finally have a non-proprietary browser option for the game, and HTML5 is much faster now than when I first tried it, but it’s still got a long way to go. Problems I’ve noticed so far:

It’s still slow. I’m aware of the limitations and background to browser tech, but it’s depressing that it’s somehow problematic drawing a few hundreds of sprites in 2012 while my ancient Gameboy DS can manage quite fine thankyouverymuch :)

Tinting images is quite a basic thing to do in order to efficiently use images and save bandwidth and memory. Why do I have to loop through pixels in javascript to do this? This is the main cause of slowness in the HTML5 version of the game ATM, hopefully a simple bitmap cache will fix this. There are also some neat ways to do it with offscreen bitmaps and blendmode tricks, but they seem even slower.

Having to write your own mouse event detection for sprite down/up/over/out. I guess this is one of the biggest reasons for the explosion of HTML5 game engines. It’s quite non-trivial and un-fun to set up properly. Actually getting the real mouse coordinates is also quite hard to do.

On the plus side, it’s a breath of fresh air to get back the control of immediate mode – it seems historically that this tends to be the optimal approach, give us the render loop!

Now you’ve got this far – here is some accidental art which happened this morning, and which I’m particularly proud of:

Making game characters with a webcam

Start with a drawing of a character seperated into pieces, and show it to a webcam. An application locates all the “image islands” in the picture using OpenCV and cvBlobLib:

The image is thresholded to make an alpha channel and the images are saved. A web server (written in clojure) picks them up automatically and sends them to a flash application (written in haxe) which builds a skeleton using prims algorithm for minimum spanning tree, a port from hapstar (you make a graph of all pieces connected to all others and use the MST of that).

This automagically created skeleton can then be animated to make puppet like characters directly from drawings on paper:

Here is a more complex abstract test:

Code here and here.

Plant spirits, AI and gitorious

This week has been about researching the next steps for the germination x design. Principally looking at how we can use the game to demonstrate and exploit some of the work on the Lirec project. I’ve had a speculative look at how we could use companions to fit the theme of a permaculture game, and ended up with some strange combination of bickering greek gods and plant spirits.

I’ve also been playing with the AgentMind code from our partners at Heriot Watt and got some of my own AI agents running and interacting with objects in a test world. At the other end, the client game code is now free from flash dependencies, so it should be possible to target HTML5 canvas and flash in the same code.

I’ve also switched from svn to git for everything and moved to gitorious. Germination X is here and all the rest of my mess is now located here.

On Flash, software art and freedom

With the current state of html5 not really being where I want it to be, I feel I need to air my dirty laundry on the use of Flash.

I want to make browser based applications in order to increase accessibility – with the understanding that I may need to make concessions to freedom to achieve this. With experience, I have found (for example by porting fluxus to windows) that such concessions over accessibility lead to more people using free software (and in that case, moving over to the linux version completely over time) than sticking in accepted, and eventually all too comfortable, spaces.

Obviously licensing the source as GPL helps, as does using a GPL toolchain (Haxe). Above all though, in artistic terms I find excessive purity to be counter productive.

Wilderness in html5 canvas

My exploration of web programming continues, this is a rewrite of the wilderness game world from haxe/flash into javascript and html5 canvas. There are some plans to make this into something more resembling an actual game, but at the moment it’s serving as a good test as I get to grips with these new fangled bits and pieces.

Leaving out all the hot air about small companies beginning with “A”, here are my thoughts on canvas for making games compared with haxe/flash:

Pros:

  • Javascript is much nicer for me than Haxe due to dynamic typing and it’s comparative closeness to Scheme.
  • Immediate mode for graphics allows you to draw a scene how you want with your own containers. The retained mode MovieClip object in Flash is an annoyance for me. Hopefully similar things happen in web graphics as it did in 3D with the early DirectX retained mode, which was eventually abandoned.
  • I’ve started using Chrome for development – the javascript debugger is one of the best I’ve come across, and the Firefox one is pretty good too. When using haxe/flash I ended up completely relying on print statements.
  • It’s nicer to develop in a normal webpage rather than a plugin.
  • Cons:

  • Canvas is currently much much slower than Flash. It’s quite possible I’m doing something stupid, but the canvas version uses about 40% of my processor where as the flash version is 5-10%.
  • Less built in support for text and user interface items like entry dialogs. There is probably much more missing along these lines, and much that will need to be implemented from scratch. Personally speaking I am not too fond of library frameworks implemented by architecture astronauts, so I can live with this at the moment.
  • Update: While I hope HTML5 is the future, it seems on some counts my optimism was premature, it seems it’s still to reach a point where it’s available for the majority of people – and where it is available, the stability and performance is variable. With this in mind : On flash, software art and freedom

    Wilderness

    I’m not sure if this is another groworld game prototype or something else at the moment. Use the cursor keys to move around, when you get to the edge of the visible bit of world you can step into the next (as long there is not water on the other side). It’s a pseudo infinite wilderness, very much inspired by SpinDizzy, and feeling boxed in while playing FarmVille.

    These are the tiles it’s using:

    The original svg is with the code in svn.

    I’d also add that selected ambient works is good listening while drawing sprites :)

    More on haxe development

    I thought I’d expand a little on the al jazari flash game, and how to develop flash games using free software.

    Haxe is really rather nice, and although I’d prefer something with more parentheses (and ironically, less static typing) it does make programming for flash a nicer experience than I’d been led to believe is normally the case. I only used haxe, gimp and a bit of fluxus to get sprite renders of the 3D models, along with the firefox and of course its flash plugin (I’d like to use gnash if I do a lot more of this). I’m going to describe the basics and some of the things it took me longer to figure out. I relied a lot on howtos in blog posts, so I thought it would be a good idea to join in the fun.

    Firstly you need a file called compile.hxml with something like this in it:

    -swf al-jazari.swf
    -swf-version 9
    -swf-lib resources.swf
    -main AlJazari
    -swf-header 640:480:40:ffffff

    This is something like a makefile for haxe and contains the main output file, the main class and the size of the area the plugin will take up. You compile your haxe script with the command haxe compile.hxml.

    The style of haxe (or paradigm, if you will) is very Java like (which is probably good for me after all this exposure to Scheme and C++). You need to name your file the same as the class containing the main function eg:

    class MyMainClass
    {
        static function main()
        {
            trace("this gets run");
        }
    }

    Will work if it’s called MyMainClass.hx and the compile.hxml contains:

    -main MyMainClass

    You can then test it out by writing a little html like this:

    <object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000"
        width="50"
        height="50"
        align="middle">
    <param name="movie" value="al-jazari.swf"/>
    <param name="allowScriptAccess" value="always" />
    <param name="quality" value="high" />
    <param name="scale" value="noscale" />
    <param name="salign" value="lt" />
    <param name="bgcolor" value="#ffffff"/>
    <embed src="al-jazari.swf"
        bgcolor="#000000"
        width="640"
        height="480"
        name="haxe"
        quality="high"
        align="middle"
        allowScriptAccess="always"
        type="application/x-shockwave-flash"
        pluginspage="http://www.macromedia.com/go/getflashplayer"
        />
    </object>

    And then point your browser at this to test the code.

    Using textures

    The compile.hxml file for al jazari also includes a reference to a lib – which is where you can embed resources like textures for making sprites. You build one of these with a bit of xml like this:

    <?xml version="1.0" encoding="utf-8"?>
    <movie version="9">
        <background color="#ffffff"/>
        <frame>
            <library>
                <bitmap id="BlueCubeTex" import="textures/blue-cube.png"/>
            </library>
        </frame>
    </movie>

    The id refers to a class you have to add to your haxe script – I think this is like a forward declaration or extern of some form, which allows you to refer to your texture:

    class BlueCubeTex extends BitmapData { public function new() { super(0,0); } }

    This bit of code (say in a class inherited from Sprite) will then draw the texture like this:

    graphics.clear();
    graphics.beginBitmapFill(
    BlueCubeTex);
    graphics.drawRect(0,0,64,64);
    graphics.endFill();

    The xml script is needed to build the swf library file which contains the textures, which you do by running:

    swfmill simple resources.xml resources.swf

    swfmill is free software, and installable with apt-get install swfmill on ubuntu.

    Using sound

    I couldn’t figure out a way to embed sounds using swfmill, it seems that it’s a recent feature, and I couldn’t find any examples that included the haxe code to load them. I did get this to work though:

    import flash.media.Sound;
    import flash.net.URLRequest;
    import flash.media.SoundLoaderContext;

    var sound: Sound = new Sound();
    var req:URLRequest = new URLRequest(“path/from/main/swf/to/samples/sample.mp3″);
    var context:SoundLoaderContext = new SoundLoaderContext(8000,true);
    sound.load(req,context);

    Which loads mp3s from a url, and then after some time (you can set up a callback to tell you then it’s loaded but I didn’t bother):

    sound.play(0);

    Where the parameter is the offset (in samples I think) from the start of the sound.

    Al Jazari in flash! (or haxe)

    My first flash/haxe app, which I found really fun to make. Click on the code to change the instructions, and on the cubes to activate or deactivate triggers – there is only one robot and one sample (808 handclap) working for the moment. Here’s more about the al jazari project.

    [update – added some more samples]
    [update #2 – more robots and more sounds, click on the robots to edit their code]

    The source code and textures are here.