Flixel - first impressions and what can 'Unity3d' learn from it
Disclaimer : This purpose of this article is not to criticize the author of Flixel, rather to help new developers to get an idea of Flixel, its architecture and what to expect from it. I still believe it is a great library for making certain types of games very quickly and very good for prototyping certain game ideas, if not the best.
If you have been trying to make flash games in your free time, there is no way you haven't heard of Flixel. Canabalt's release also popularized the engine quite a bit. I dabbled with Flixel a few weeks ago for a small weekly prototype marathon we had at work. Me, being the usual awesome self, decided to go with a library that I haven't worked with before for the marathon. So it began.
Good, Bad Stuff
First of all Flixel's 'features' page is pretty amazing on their website. Multiple cameras for a 2d game, built-in simple physics/collision system, particle engine, game save/load and even a feature to record and replay demos. Wow! I thought.
Soon enough I plugged in Flixel into a new AS3 Flash builder project, and I was able to get the 'hello world' to work in no time. But gradually it started to slow me down. Of course like any library, I know I can't expect everything out of the box. I will have to write code for higher level custom functionality. But the problem was with Flixel's architecture. Having worked with AS3 framework, Java, .NET, and Unity 3d architecture etc. I am definitely used to having clean package hierarchies, naming and class design. I cannot blame the author though, he has stated something relevant to this clearly in their about section in his own words.
To explain the problem with architecture better, let me give an example. Flixel supports paths. You can make your objects move in custom paths. Now there is a FlxPath class which holds an array of points which make up the path. But that's all it does apart from having some methods to add/remove/retrieve points and for debug drawing.
Now FlxObject is your usual basic abstract game object class in any engine. It has everything - position, size, physics properties etc. Then there is a FlxSprite class which extends from it, and like you might have guessed it holds sprites, sprite sheets and also has code to animate with sprite sheets.
Now the FlxObject holds a reference to a FlxPath object with some public properties like pathSpeed, pathAngle etc. along side few more protected properties related to path. This doesn't look clean to me and I have this OCD where I find this annoying too. I wish I could give more precise reasons than saying 'I doesn't feel right', but I have not yet reached that level yet in my programming career. I would say a better way to write it would be to isolate everything related to path in a different class. And that class should control the object from outside the object in a special internal post-update routine (After every FlxObject's update function gets called in the general game loop). Or just follow a component based architecture where PathFollow component could be added along side of other stuff like Physics, Controls etc. Maybe just use something similar to their existing plugin system and implement a PathFollow class just like DebugPathDisplay class.
Another thing that bothered me is the FlxG and FlxU classes. It so happened that there were a few functions which I was looking for in more obvious places, but were present in FlxG and FlxU classes. For e.g. FlxU has a static function called getDistance and it takes 2 FlxPoints. Instead it should be a method of FlxPoint class. The problem is once you have been programming for about 4-5 years you sort of get intuitive about quickly finding function in a framework without using google. It often happens with .NET, Java and AS3 thanks to their very clean design. I hated googling and to search on their 'not well' documented wiki for the simple things I needed to do. May be I was hoping for an even quicker start up than what I got with my first experience with Flixel.
But then again for someone who need to prototype simple games, maybe its handy when everything is available in a single class and doesn't have to init 2 or 3 more classes along with extra boiler plate code.
Good, really good stuff
But I found one class called FlxGroup to be extremely useful, pure awesomeness. Pooling of objects in game programming is not new, but this class makes it so easy to do that in a very generic fashion. Every FlxObject has a dead/alive state, and we can just call handy functions like getFirstAvailable, getFirstAlive and even getRandom. Also I couldn't help but notice that a function called callAll exists, it just calls a function on all objects in that FlxGroup. Moreover the FlxState (which is an equivalent of a GameScene) extends from FlxGroup. So when you reached the end of a level and you want all the enemies to explode no problem, you can do it with just one line :)
Now this is exactly the feature / class that would be awesome if it was in Unity3d. Having worked as producer for Unity based game projects, I found that programmers found it impossible to write even simple mobile games on Unity without Object Pooling for almost each and every thing. Their Object.instantiate is a terribly slow call, especially when you instantiate a Prefab directly and there used to be no warnings about it on their documentation (not sure about it now).
Though I did bi*** about the author of Flixel clubbing too many things in the same class, once you learn and get used to the library you will find it very quick for prototyping game ideas. Flixel has everything you need (Physics / Collision, Text support, Sound, Tile support, HUD/UI Buttons etc.) and in considerably less number of classes. But it is both a good and bad thing.
It is only a matter of time until the library goes through a little bit of cleaning up and thus making it even more modular, robust and still simple as it is now. So will I use it again? Definitely yes for prototypes, may be not for full games though. I am yet to check out Flash punk which I heard is a much more mature framework for experienced developers.
If you have been trying to make flash games in your free time, there is no way you haven't heard of Flixel. Canabalt's release also popularized the engine quite a bit. I dabbled with Flixel a few weeks ago for a small weekly prototype marathon we had at work. Me, being the usual awesome self, decided to go with a library that I haven't worked with before for the marathon. So it began.
Good, Bad Stuff
First of all Flixel's 'features' page is pretty amazing on their website. Multiple cameras for a 2d game, built-in simple physics/collision system, particle engine, game save/load and even a feature to record and replay demos. Wow! I thought.
Soon enough I plugged in Flixel into a new AS3 Flash builder project, and I was able to get the 'hello world' to work in no time. But gradually it started to slow me down. Of course like any library, I know I can't expect everything out of the box. I will have to write code for higher level custom functionality. But the problem was with Flixel's architecture. Having worked with AS3 framework, Java, .NET, and Unity 3d architecture etc. I am definitely used to having clean package hierarchies, naming and class design. I cannot blame the author though, he has stated something relevant to this clearly in their about section in his own words.
To explain the problem with architecture better, let me give an example. Flixel supports paths. You can make your objects move in custom paths. Now there is a FlxPath class which holds an array of points which make up the path. But that's all it does apart from having some methods to add/remove/retrieve points and for debug drawing.
Now FlxObject is your usual basic abstract game object class in any engine. It has everything - position, size, physics properties etc. Then there is a FlxSprite class which extends from it, and like you might have guessed it holds sprites, sprite sheets and also has code to animate with sprite sheets.
Now the FlxObject holds a reference to a FlxPath object with some public properties like pathSpeed, pathAngle etc. along side few more protected properties related to path. This doesn't look clean to me and I have this OCD where I find this annoying too. I wish I could give more precise reasons than saying 'I doesn't feel right', but I have not yet reached that level yet in my programming career. I would say a better way to write it would be to isolate everything related to path in a different class. And that class should control the object from outside the object in a special internal post-update routine (After every FlxObject's update function gets called in the general game loop). Or just follow a component based architecture where PathFollow component could be added along side of other stuff like Physics, Controls etc. Maybe just use something similar to their existing plugin system and implement a PathFollow class just like DebugPathDisplay class.
Another thing that bothered me is the FlxG and FlxU classes. It so happened that there were a few functions which I was looking for in more obvious places, but were present in FlxG and FlxU classes. For e.g. FlxU has a static function called getDistance and it takes 2 FlxPoints. Instead it should be a method of FlxPoint class. The problem is once you have been programming for about 4-5 years you sort of get intuitive about quickly finding function in a framework without using google. It often happens with .NET, Java and AS3 thanks to their very clean design. I hated googling and to search on their 'not well' documented wiki for the simple things I needed to do. May be I was hoping for an even quicker start up than what I got with my first experience with Flixel.
But then again for someone who need to prototype simple games, maybe its handy when everything is available in a single class and doesn't have to init 2 or 3 more classes along with extra boiler plate code.
Good, really good stuff
But I found one class called FlxGroup to be extremely useful, pure awesomeness. Pooling of objects in game programming is not new, but this class makes it so easy to do that in a very generic fashion. Every FlxObject has a dead/alive state, and we can just call handy functions like getFirstAvailable, getFirstAlive and even getRandom. Also I couldn't help but notice that a function called callAll exists, it just calls a function on all objects in that FlxGroup. Moreover the FlxState (which is an equivalent of a GameScene) extends from FlxGroup. So when you reached the end of a level and you want all the enemies to explode no problem, you can do it with just one line :)
Now this is exactly the feature / class that would be awesome if it was in Unity3d. Having worked as producer for Unity based game projects, I found that programmers found it impossible to write even simple mobile games on Unity without Object Pooling for almost each and every thing. Their Object.instantiate is a terribly slow call, especially when you instantiate a Prefab directly and there used to be no warnings about it on their documentation (not sure about it now).
Though I did bi*** about the author of Flixel clubbing too many things in the same class, once you learn and get used to the library you will find it very quick for prototyping game ideas. Flixel has everything you need (Physics / Collision, Text support, Sound, Tile support, HUD/UI Buttons etc.) and in considerably less number of classes. But it is both a good and bad thing.
It is only a matter of time until the library goes through a little bit of cleaning up and thus making it even more modular, robust and still simple as it is now. So will I use it again? Definitely yes for prototypes, may be not for full games though. I am yet to check out Flash punk which I heard is a much more mature framework for experienced developers.
Comments
Post a Comment