The Awesome Awe6 Haxe game framework

So as part of my adventures with Haxe I did quite a bit of research into different game frameworks to use with Haxe – I found this site very helpful in my decision
Awe6 (pronounced Awesome) ticked a lot of boxes for me, one being that it seemed very different to the other frameworks who in my opinion seemed far too opinionated about how you do things. Awe6 seems more flexible and working with it is a dream.
The documentation is great although finding other tutorials apart from the ones on Gamefromscratch and the Awe6 site there isnt very much out there about getting things up and running.

The steps to getting a basic application set up with Awe6 are very simple. Simply install Awe6 via:

  1. haxelib install awe6

Once the lib is installed you can easily scaffold a project by calling:

  1. haxelib run awe6 create project openfl <projectname> <packagename> <author>

Swapping out the projectname/packagename & author with your own texts. This creates a basic scaffolded project which works off the bat and has an intro screen, and a game screen with pause functionality etc built in with default assets. As you can see the developers of this framework have already made it work well with OpenFL. Also the framework doesn’t care about what type of game you are creating so unlike most which force you to only create 2D games or Pixel art based games Awe6 allows you to use say Away3d or Spine.hx to power the animations of your game, in fact you are free to use any other libraries you wish giving you total freedom.

Playing around with the newly scaffolded project you can see how the application framework is structured. Awe6 uses the factory pattern to create the objects (Scenes, Entities etc) that are needed to run your game and has scene management etc built in. The createScene method of the Factory class decides which scene to create:

  1. override public function createScene(p_type:EScene):IScene {
  2.         switch ( p_type )
  3.         {
  4.             case EScene.GAME :
  5.                 return new Game( _kernel, p_type );
  6.             case EScene.INTRO :
  7.                 return new Intro( _kernel, p_type );
  8.             case EScene.MENU :
  9.                 return new Menu( _kernel, p_type );
  10.             default :
  11.                 null;
  12.         }
  13.         return super.createScene(p_type);
  14.     }

If you create any new scenes this is where you would add the flow that would decide at which point it would show up. Likewise the Factory class also has a getNextSceneType and a getBackSceneType to decide which of the created scenes it should show as the user navigates back and forth through the game

  1. override public function getBackSceneType(p_type:EScene):EScene {
  2.         switch ( p_type )
  3.         {
  4.             case EScene.GAME :
  5.                 return EScene.MENU;
  6.             case EScene.MENU :
  7.                 return EScene.INTRO;
  8.             case EScene.INTRO :
  9.                 return null;
  10.             default :
  11.                 null;
  12.         }
  13.         return super.getBackSceneType(p_type);
  14.     }
  16.    override public function getNextSceneType(p_type:EScene):EScene {
  17.         switch ( p_type )
  18.         {
  19.             case EScene.GAME :
  20.                 return EScene.RESULTS;
  21.             case EScene.INTRO :
  22.                 return EScene.MENU;
  23.             case EScene.MENU :
  24.                 return EScene.GAME;
  25.             default :
  26.                 null;
  27.         }
  28.         return super.getNextSceneType(p_type);
  29.     }

This is the guts of navigating through the game and means that you don’t have to worry about manually instantiating your scenen classes your self. Adding entities are done in each of your scenes and the entity management is nicely managed too. Entities are not display objects but their own ‘controller’ classes which force you to abstract your view logic into its own class. By creating a context object for each entity you get something to add your views to. All entities extend the base class Entity and need to override the _init method for initiation and if you need things updated via the internal loop then you must override the _update method. As an example:

  1. class SpaceManEntity extends Entity {
  3.     private var context:Context;
  4.     private var _assetManager:AssetManager;
  5.     private var spaceManView:SpaceManView;
  7.     public function new(p_kernel:IKernel) {
  8.         context = new Context();
  9.         _assetManager = cast p_kernel.assets;
  10.         super(p_kernel, context);
  11.     }
  13.     override private function _init():Void {
  14.         super._init();
  15.         spaceManView = new SpaceManView();
  16.         context.addChild(spaceManView);
  17.     }
  19.     override private function _updater(p_deltaTime:Int = 0):Void {
  20.         super._updater(p_deltaTime);
  21.         spaceManView.render();
  22.     }
  24.     public function setPosition(x:Float, y:Float):Void {
  25.         spaceManView.setPosition(x, y);
  26.     }
  27. }

Ideally you would want to add the instantiation of the View to the Factory class to avoid having to have instantiation littered through your code base – this also makes it much easier if you wish to unit test your classes.

The kernal object that is injected into the constructor is an internal object that is passed around the game and holds lots of information about the current state of the application as well as other settings like isDebug or isFullScreen etc.

Next time I will run through setting up a basic game so that I can easier demonstrate how the framework flows and how it handles other things like transitions, preloading of assets etc.

Posted in Awe6, Haxe | Tagged | Leave a comment

Giving this blog some love

So I haven’t added a new post to this site for over 18 months – many reasons – being way too busy – I got promoted at my job and the incredible pace of work in the last year has left me very little time for being able to spend any time on things like adding posts to a blog site. Also my attention was taken away from producing flash & Actionscript applications to concentrating on Javascript as my work shifted their focus to getting their games available on mobile devices. I enjoy programming in Javascript – but unfortunately it is not something I am passionate about so I have not been enthused to produce any Javascript based tutorials or blog posts. Anyway I need to get back into writing posts and seeing as I am forcing myself to allow myself more time for personal work this year I have been spending some time playing with Haxe – and absolutely loving it. So needless to say you should expect to see more Haxe & OpenFL based information on this site as well as other stuff.

Posted in Background | Tagged | Leave a comment

Away3D 4.0 With AIR 3.3 Running on an iPad 3

Well I finally took some time recently to update an old demo I did when molehill and Away3D 4.0 were first released, after an update to the then beta version of Flash player 11 a lot of demos broke due to a pretty major change in the stage3D API and it has taken me this long to update it, so it should all work nicely now. Anyway while I was there I thought it would be nice to try and compile the same demo to the iPad – and how pleasantly surprised I was.  I managed to compile the same application to the iPad with one code change in the descriptor file. By adding this tag after the renderMode tag in the descriptor file for the application to run on my iPad 3:

  1. <depthAndStencil>true</depthAndStencil>

IntelliJ made the whole process of compiling a synch and once I got it onto the iPad I was amazed at the results…

Away3d 4.0 on an iPad 3 from UltraVisual on Vimeo.

And the same demo running on my Samsung Galaxy S2:

Adobe AIR 3.3 & Away3D 4.0 running on Samsung Galaxy S2 from UltraVisual on Vimeo.

Posted in Actionscript 3.0, Adobe AIR, Away 3D | Tagged | Leave a comment