Experimenting with Web Game Development
RSS icon Bullet (black)
  • Performance Anxiety

    The game code was heavy on maths, so I have decided to pinpoint where the difference in performance is coming from. I found an AS3 performance test on AS3 performace test and ported it to hAxe - again, not necessarily perfectly.

    You can check out the results here:

    The tests can be seen at http://www.onflex.org/perf/srcview.

    As you can see, the haXe code is slower - sometimes a lot slower - than the AS3 code. Of note:

    • Test 2 : sort. This is perhaps not surprising because the haXe version is using a custom string compare function, rather than a built-in one.
    • Many of the functions are to do with string manipulation. I suspect the probelms here are introduced though the layering of the library via “Std.” and the internal string functions.
    • Function 9, the loop code, shows a huge difference. Here I think there must be some loop optimisation that hAxe is missing out on.
    • Function 12, a subroutine call, is also very very slow. I think there may be something simple that haXe is not doing.

    So there you have it. Loops and function calls - building blocks of most programmes, are very slow.

    These differences are way bigger than the file-size differences would suggest, so I think there is still hope that haXe speed can be greatly improved.

  • Physical Test

    I am interested in many types of games, but I find physical simulations particularly cool. So I did some fishing on the internet for flash-based (flash9 = actionscript 3=AS3) physics code, and I found APE as a freeware physics engine. Since I had the source code, I though this would be a good test to compare haXe and AS3. This should be an interesting test because they both run on the same virtual machine, so it is just the code-generation differences that we are testing. I ported the demo to haXe – now I admit that this may not have been the best port, but still the results are a bit disappointing. Checkout the comparison for yourself:

    AS3 Version

    haXe Version

    I get AS3 version 7.05ms/frame calculation, and haXe 37.8ms. That’s about 5 times slower. Also of interest is the difference in file size. AS3 swf file is 10051bytes, and the haXe file is 11907. I will have to find the source of this difference if performance libraries are to be written in haXe

  • The Plan

    Well, as the URL of the site may suggest, my initial plan is to use the “haXe” programming language.  And I plan to do this by generating byte-code for flash-player 9 for the web, and linking the neko virtual machine to a suitable “engine” for the stand-alone executables.

    The possibilities I see are:

    1.  Use haXe to generate flash9 and neko code. All logic written in haXe. Plus a simple C++ engine to link the neko into.
    2. If haXe is not fast enough on flash9, write performace code in AS3, and replicate this in C++.  Then use haXe for more high-level scripting.
    3. Write all in AS3, and buy a stand-alone flash player.
    4. Write in Java for the web and link a JVM into a C++ executable.
    5. Write all in Java and simply bundle it into a stand-alone player.

    This is pretty much the order I think I will try things.  I’m hoping I can get point 1 to work – this will give the greatest ability to get a simple web version going, with the ability to download a stand-alone version that is far more complex and not performace bound.

    I prefer Flash to Java mainly because of end-user acceptance.

  • Hello world!

    Hi Everyone. This is my site chronicling my efforts in web game development.

    I have been programming since command-line was the way to programme. A simpler time when anyone could boot up his computer and start typing a game.

    But nostalgia is a thing of the past, and advances, such as C++, means that you can write bigger and better programmes than when you typed in your Apple-basic code and saved it on your floppy.

    I’ve done my fair share of writing big C++ programmes and the idea of writing some smaller, web based games has a great appeal. I think it’s the simplicity – and the immediacy of just plonking it on a website and people can play it straight away – no installs, no downloading just one click.

    I have already published a game, FreeRange , written in C++. It occurred to me it would be good to convert it to a web game – but the syntax and structure was all wrong. This got me thinking about how I could have structured it to allow for co-development of an compiled executable and a web-based application.

    So that is what this site is all about. The quest to discover the best way of developing a game, using one code base, that will work on both the web and a stand-alone application.

    I’m not exactly sure where this will go, but I do know that it will involve either Flash or Java and will use some for of virtual machine in the executable.