It's good to be here again. A year ago I entered a relatively new, growing a haxe community. I have learned a lot in the process, about gamedev from a different perspective and met a game jam focused community. I was particularly using HaxeFlixel, which is Haxe port of as3 flixel but many stuffs were done better than the original. Now I will share what I loved most about Haxe specially haxeflixel.
1. Easiest to jump into. Installing and configuring HaxeFlixel was a breeze. You setup once then its easy to pull latest source or changes. It automatically compiles flixel source the first time you build the project.
2. Cross platform development is a breeze. With Haxe you need to configure once, for cpp if visual studio is installed, then its already added in the path, same with mac/ios dev, for android only first time you provide path of android SDK, ndk,jdk and ant tool. After that don't bother. Also compiling for a different platform is just changing a parameter while building. For example the command from project dir,
"Haxe run windows" builds for windows and
"Haxe run android/ios/mac/linux/html5"
Builds and run for that specific platform. It also generates project files so you can use IDE too. Of course you have to provide some config info for each platform. That's it. Even faster than unity3d.
3. Starting a new project is super easy, haxeflixel has some command tools to generate a simple bare bone hello world project, like
flixel tpl -n "HelloWorld"
creates a new project, so starting a new project is as simple as that. You can also config which IDE project files you want to generate, so that's convenient too.
4. Quick development even without a drag n drop editor, I hate dnd dev for some reason. Mainly because I am a programmer, not a good one though. There are many flixel tutorial (community driven) which covers many topics which helps rapid development.
5. Support of wide variety of tile map editors and spritesheet tool or animation tool like spine/spriter. Nowadays, it is hard to find someone who does not know about texture packing or other tools like it. Also many new devs use some sort of tile editors like ogomo, dame, mappy, tiled (my fav) or at least CSV file, also auto-tiling feature I am sure you guys are familiar with. Which lays solid foundation to make platformer, roguelike, or tile based rpg games.
6. Sprite animation is very easy to create and play, as you can load animation from image, providing framesize, and index. Also you can load from texturepacker or other tools, providing anim names. I find this method easier than even unity's way of handling animations.
7. Has web target which makes easier in game jams, so that your game gets maximum exposure. Many people can try your game. Though haxeflixels flash target is solid, but html5 target is not that powerful.
Everything has it's cons, so in short I will mention things I did not like or missed in haxeflixel
1. Fully state/scene based object management. First you need to create a state, then add everything to that state, once you destroy the state or change the state everything gets destroyed. But there is no way to manage inter-state object, you want to keep same object between states, you are out of luck. You have to create every single object in every state you use.
2. No per object/sprite/camera shader support at all. I am a shader noob, but you can't even add simple filters to your objects in native target. Also no render to texture, you want to add some decal effect to your sprites, you have to go with set/get pixel method., which is damn slow.
3. Managing a parent child system, or a composite sprite is a PITA. Not very efficient. No object anchor or pivot point. Pivot or anchor point only works for rotation or scaling.
4. Very basic physics system, only rectangular collision response system, no circular, polygonal collision out of the box. For full physics you need to use nape, but that's not integrated deeply in the engine, also I am much more familiar and comfortable with box2d, that's why I did not bother using nape.
4. Performance, flixel is not well optimized, I could only run 6K bunnies (orx equivalent objects) in flixel where I got 14K orx object. Also no real particle system, or animated particles, and you can't use too many particles, because particles are also treated as individual object in flixel. Even a particle just extends Sprite, which makes things worse as flixel's Sprite is a bloated class, full unwanted functionalites and variables.
I could probably add some more pros/cons, but these are the things I felt important, if I recall something important later will add.
Now, what could be done to make orx more friendly and appealing to new users? I am going to present some proposals, that I gathered from my experience, to make orx user friendly. Few things I mentioned to iarwain in pm, will also state here to address the issues.
Here they are:
1. Orx is not object oriented friendly, as most of the people are familiar with some sort of OO language, including myself, we find C way of doing thing tedious. Like, if you have a sprite, then we assume, there must be, sprite.setPosition() or such sort of methods, not Object_setPostion(object).
Solution: Making scroll more powerful, useful and default way of dealing with orx.
2. Starting a new project is a pain. Right now the way orx handle projects and platforms is very hostile. We have binary for different platforms separately, which is a real turn off for multi-platform development.
Solution: Introducing a simple command based project building tools like flixel, even cocos2dx uses python script to generate new project which includes all platforms, also building for each platform could be done with python scripts. It’s project structure is something like this.
|-- Classes (Game source files)
|-- Resource (Game data files)
|-- Engine_Src/libs (which will contain libs for all platforms seperately)
|-- Proj_win32_VS (VS project files)
|-- Proj_win32_mingw (mingw project files)
|-- Proj_linux (linux project files)
|-- Proj_ios_mac (xcode project files)
|-- Proj_android (android project files)
I am not saying orx project structure should be like this, but my point is it should contain build files for all the platforms. And creating new project should be hassle free. Building a sample project should be easier.
3. Lack of proper documentation. Once we get a hello world orx project up and running easily, while building it for couple of platforms, then move onto learn about orx. But how you do that? Wiki or tutorial. Sadly, orx wiki is a mess, I am not talking about tutorials but how orx handles stuffs, and important aspects of the engine. For reference we could look into haxeflixel and cocos2d-x documents.
We should make wiki such that a new user could easily grasp what orx is about. I am not suggesting exact wiki format like above, but more informative, and more about what to do than how to do.
After a user has basic understanding of orx, like oh I need to define object properties in a config file, then load config from code. Then comes playing animation, or load a level files (some sort of), do some collision check, input and UI.
4. I talked with iarwain about tile map support and simpler animation loading directly from texture packer like tools, so I will be skipping this for now.
5. Another major drawback of orx is no document about UI. Or no basic UI support in orx by default like a simple button, or 9 patch sprite/button, labels, text field, slider etc. I hate doing UI, especially when there is none. Every game needs some sort of UI, and we cant ignore that. I can see there is a button tutorial in wiki but it is frightening. You have to do so much just for a button, that's a big turn off for me, and for new users. People want to create button like this, either
Button button = new Button(…) or
Button button = CreateFromConfig("MyButton")
then assign a callback method like,
6. Some higher level helper functions would be like icing on the sugar. Like camera follow, camera/screen shake, screen fade in/out, screen flashing, timer or callback function etc.
7. A web build would be much appreciated, it would be ok if it is just as a proof of concept, to show orx functionality interactively. This would also attract game compo guys. I hope, next year, we will see orx running in browser
So, these are the points I could come up with now. 6,7 are least important to me though. You can also add your own opinion of how to make orx friendlier and easier to new user. I hope this will just be the start of a reform revolution that orx badly needs, and as a result we hope to get a more users, developers and contributors
Some of the things I mentioned above could be just my personal opinions, feel free to correct me. Above proposals are open to discussion, nothing is absolute.
Thanks and cheers!