My nme adventure

I’ve used haxe / nme for my latest project Cosmoplan for 5 months because I wanted my game to be on every major mobile platform. The second main reason to use haxe was to see if it is suitable for my future project which is a realtime multiplayer mobile game.

I’ve successfully finished my game with haxe and during private beta I gave up using it and switched  to actionscript / starling. It was a though decision to make and I think it would be good to post the reasons behind that decision.

Here are the advantages of Haxe / Nme

  • Haxe is great and nme seems great at first glance. When you run bunny mark tests it clearly is one of the best options at the market.
  • It is free and has an active community
  • It is fast
  • It is very similar to actionscript so guys like me can make smooth transitions to haxe.
  • It is cross platform.

And here are the problems I faced

  •  It is not truly cross platform. It seems like but it is not. You have lots of times running your code working in flash target, cpp target, ios target but not on android target ( or pick one of them not working properly)
  • Mobile platforms except blackberry can’t get opengl context. So no access to shaders, which means you don’t have fast filters, nor vertex shaders nor custom drawing. I’ve waited for this for 3 versions of nme but no update so far and I think it is VERY critical on mobile development.
  • Lots of things are rendered in software which is not stated anywhere. You all learn these with experience which may be very frustrating. These are:
    • Masking
    • Gradient fill
    • Filters
    • Gradient lines
    • Bitmapdata operations
  • Setting up new platforms need some work. It may take lots of time to accomplish or it may be done in first attempt. It is very possible to make mistakes and when you make mistake you’ll face with tons of lines of hxcpp output and your only option is to wait response from creators of nme or hxcpp. (Btw they are really really great guys and trying to help as fast as they can.)
  • Audio is very problematic. You can only play one mp3 at a time. ( for cpp targets – mobiles included -)
  • There are not enough sample codes about native extension. Or samples / tutorials are outdated. ( nme moves really fast)
  • Most frustrating thing was facing not implemented methods. It is nearly impossible to see which methods are available for which platform and which are not. For better clearance check Capabilities class and you can see nearly %80 of that class is not implemented for mobile targets. They only work for flash.
  • There are also non implemented features on mobile like BitmapData.perlinNoise, you all find these with experience also…
  • Debugging on cpp target is pain in the ass and just for debugging purpose you have to keep support on flash target which leads lots of extra conditional compile code. Coding just for cpp was not an option for me because of this problem and also compiling to cpp takes damn too long. ( As I experienced your cache is being erased after you compile for another target or changed the debug mode. If you switch back and forth on ios, mac targets or debug or relase you may find your self waiting rather then developing)
  • There are lots of ide’s around there which claims they support haxe but there is not fully supported one. They are only like code completion and syntax highlighted text editors. I used IntelliJ which is the ide I’m in love with – seriously that’s the only thing I’m fan of – but the support of haxe is not official so you don’t have error highlight nor you don’t have syntax highlight inside conditional code. You can’t optimize imports nor refactor package. I’m using mac but afaik Flash develop also doesn’t have error highlight.
  • There is not a set of native extensions working properly. There is nmex around there but you have to spend a week for make that thing work. I don’t know a game developer who enjoys implementing iAd, adMob, iRate, inApp, flurry, push Notification, Facebook etc. We all want to write games and these native extension part is a hump we want to get rid of really fast. So having option to buy stable versions or having these things inside nme would be awesome.
  • Tilelayer has issues. It doesn’t change alpha when it’s container views alpha changed. This works properly on flash but not on cpp targets. ( This caused me a huge problem by the way. All my scene transitions were not working on cpp targets ) Tilelayer doesn’t perform good on flash target.
  • Stable builts may have problems also. (http://www.nme.io/community/forums/programming-with-haxe/hxcpp-30-fails-android/)
  • Building from source is a nightmare. It just truly is.

You may all say ” you are whining but haxe / nme is opensource, you can fix it”. That’s not what I’m good at nor that’s not what I want to do. All I want is developing my game on a cross platform framework without worries.  Personally I think nme tries to do much more than it should. I think nowadays it is way more important to have ios, android targets working stable and all features implemented than supporting mac, pc, html, blackberry, webos, android, ios, flash sloppy. Seriously why html support ?

I really appriciate what nme team trying to do and  I believe it will win the cross platform development race eventually.I’ll keep an eye on them. Maybe developing without a game engine was a mistake, maybe I dived into it in a wrong time ( during haxe 3 and sdl2 transition). Awe6, haxe flixel, haxe punk seems good. They may have issues on their own but they seem more stable than using tilelayer as main renderer. I chose stability over speed by getting back to actionscript, hope nme gets better till I start developing my second project.

Advertisements

10 thoughts on “My nme adventure

  1. I appreciate all of your feedback.

    You already know that NME 3.5 introduced the OpenGLView, which enables access to OpenGL for shaders and other effects. We added support for desktop and for HTML5, but did not enable support for mobile until it was tested more thoroughly.

    For example, Android has so many devices that requiring OpenGL ES 2.0 can cause unexpected consequences. For example, we have received feedback on devices that could not even run all OpenGL ES 1.1 features. The current development builds are support GLES2 (and therefore OpenGLView), so this will probably be enabled in the next major release.

    With OpenGL ES 2 (and the equivalent desktop APIs), we have support for shaders, we have used to accelerate more drawing operations, such as gradients, so that can perform on the GPU.

    Most of the C++ targets use SDL_mixer (with iOS and Android being the exception), which has two APIs playback. It supports a single streaming background music track, and multiple sound tracks. It supports MP3 on the music API only, so if you use OGG or WAV you should be fine playing multiple audio tracks at once.

    If you are using “nme” as your class names rather than “flash,” it should provide code completion for what is supported, which makes things simpler. However, there’s a big focus right now on making sure we support little APIs that may be missing.

    I’d love any feedback you have on the setup process, if there’s something that can make it easier to walk through.

    I believe a debug build may invalidate the cache for a release build of the same target, but I’m not sure. I tend to stay with the same configuration so the cache works fine here. There is a distinct separation between various platform targets, so those should definitely not affect each other. I regularly come back to old projects and find it still cached for random target I try.

    I’m interested to hear any ideas to encourage more native extensions, as I do believe that is important. The development builds have “nme create extension ” to make it easier to generate new ones, but maybe we need to do something to encourage sharing when a developer builds an extension they need, a marketplace?

    It should be much easier to build from the source now, I apologize that things got shifted around as we’ve been managing the transition for Haxe 3. I would personally recommend Haxe 3 when building from the source right now, but I expect to be “over the hump” in those regards soon.

    There are other things in the pipeline you may find interesting, perhaps offline we could talk a bit, if you interested in providing feedback for the next version?

    Thanks again for sharing, and don’t hesitate to ask if I can help you in some way.

    • Joshua thanks for your detailed answer. This attitude makes me believe that haxe is the future.

      I’m aware of the opengl problem and I don’t judge you. It’s just a problem stands in front of me and I waited like 5 months for that 🙂 Sorry if I sounded like whining.

      I also know the workarounds for audio, but it is limiting. For example in prologue of my game there is a background music (30 secs) and a voice over ( 40 secs.). Voice over can’t be embedded in background music cause bg music starts from menu and we don’t know when will prologue starts and it shouldn’t be used as wav because of asset size.

      My intention on ide was not code completion. If you ever used IntelliJ for actionscript you may understand what I ment better. Error highlighting, code generation, solid refactoring. I mailed Jetbrains if they think to support haxe, maybe we all can push Jetbrains harder to give official support to haxe.

      My humble advices about nme would be.

      – Nme should define a target developer audience and reduce its targets. Who do you want to use nme ? There are not so many guys developing for all of these platforms. Loom did a great job on defining that. They started with android, ios and that’s it. If your developer target is desktop developers you may say our targets are pc, mac, linux only.

      Developer also have to chose one player audience. Gaming experience is very dependent on controls. There are not so many games suitable for all of these targets.

      Existing targets which will not be supported can be moved to another project and we all know that nme targets are totally working without any problems. This would make nme brand stronger.

      – Making sure every sample in nme is working on every target is very important to get new developers in nme. For me samples is a summary of what framework is capable. When a sample doesn’t work on one target then all of the crossplatform magic is shattering.

      – I don’t follow nme’s nightly builds because I was using nme for final product and I had limited time. I had to follow stable builds. But my advice would be creating automated setup files (including neko, hxcpp ) for nightly builds or making this progress easier.

      – Native extensions is a complicated problem. It has to be maintained for new versions of haxe and nme, it has to be updated for platform changes, it has to be well documented and it has to be easy to implement. Maybe because of these reasons community didn’t give back the extensions they build for their games. So I think having a market is a good solution, nme team can build these extensions and charge for it with the warranty of 1 year support.

      – Nme should clarify what it’s capable of and what it is not very clearly on documentations.

      I really appreciate what you guys are doing and I know nme would get it’s place and get enough support from community. I’ll mail you some extra detailed feedback after Quo Vadis.

      • I learned yesterday that 0.3% of Android users on the Market cannot support OpenGL ES 2.0. I suppose that’s one issue down!

        I understand your point about audio, and have wanted to move to a more robust API for some time now. It’s one of the things I’ve hoped we could do for the next release as well. There are already some targets working with OpenAL, which does not have the one MP3 restriction like SDL_mixer.

        One of the misnomers I have heard before is that we have our time stretched thin because of the number of platforms we support. Actually, let me give you an example. I enabled OpenGL ES 2.0 support on mobile, and got it working on BlackBerry. For kicks, I booted an old Palm Pre and gave it a run. It worked perfectly.

        The worst platforms for our time are iOS and Android, which both require specific code to maintain (Objective-C and Java) for them to work. The other targets are built on SDL, and basically fall in line with each other — when we make an improvement for one target, it works for all others. There is a fair amount of our codebase that works on iOS and Android as well, of course, but dropping iOS or Android would be the only change that would practically change our time investment, and I don’t think anyone wants to see that happen.

        I have plans for how development builds may be easier in the future… in the meantime, thanks for your understanding!

        If you need my email address or anything else, let me know 🙂

        Have a great day

  2. This is a great article and great discussion afterward. It’s obvious you guys are better developers than me but I wanted to share the following.

    I don’t worry too much about every target running perfectly—what matters to me is that if I build something once, much of the code is completely transferable to a new project or platform.

    I like that NME targets HTML5. I’d rather have it a bit buggy than not have it at all.

    I share the desire for an awesome IDE. I currently limp along with FDT because it also supports everything Eclipse does plus AS3.

    • What editor do you think stands the best chance of being “the” IDE for Mac or Linux? Do you think it should be Sublime Text, MonoDevelop, IntelliJ, or something else?

      • Good question. I’m taking things at face value right now, not having experience with a wide variety.

        MonoDevelop and FDT have a good start because they’re free. It seems like MonoDevelop is much more user-friendly, so I would recommend that for a beginner.

        I chose FDT because of its versatility, but I have been disappointed with their support of Haxe. The other problem is, nobody has heard of it except AS3 or Haxe developers.

        I would strongly consider changing to a stock Eclipse setup, if I knew Eclihx (http://www.eclihx.org/) was a good tool. Then I would use FDT as a plugin (http://fdt.powerflasher.com/2011/11/fdt-plugin-released/).

        Promoting Eclipse would take advantage of its existing fame, and it would also appeal to FDT and FlashBuilder users. It is powerful and it’s free. I haven’t seen much momentum for Eclihx unfortunately.

        So bottom line is I think MonoDevelop has the best chance to be the default for now. IntelliJ has the best chance for power users willing to pay. Eclipse has the best potential for power users if someone would go ahead and promote it forcefully and keep Eclihx active.

      • I would suggest as of today most are using Sublime Text on Linux and Mac for NME/Haxe. Unfortunately both of these are closed source and I don’t think most devs starting out will pay for it. I hope NME / Haxe Foundation can promote an open source cross platform IDE. I would gladly go back to FD but I can’t be stuck in windows.

        Google’s Dart project has already made this decision with Eclipse http://www.dartlang.org/tools/editor/ I am not aware of many other options that would be wiser apart from continuing with MonoDevelop.

        I am also a fan of Intellij Idea for the same reason mrahozer uses it, if you try java or as3 with it for a day you might see what their haxe plugin is missing. I wouldn’t be surprised if this also influenced mrahozer to go back to as3, I know I miss the advanced refactoring, error checking and other features, unfortunately their company won’t give Haxe a priority for now.

  3. This is a great discussion. I would just like to share a few things(but I’m quite nme-biased).

    There are a lot of things in NME that are missing or not functioning the same on all targets. NME is far from finished, but what it already does is amazing. I started using it almost two years ago and the progress since then is huge.

    There is a Loom and other engines, but I feel NME is much more powerful. While some people(me included) don’t consider HTML target as needed, don’t just cross it out because of it. I can imagine it as quite a future proof target(unlike flash) and I see a lot of people are actually using it. It’s the beauty of NME. I also see a lot of people using both desktop and mobile targets. I have a game published on both iOS and Mac myself. Maybe the controls can be reworked and the game can be perfect for both desktop and mobile. It depends on a project, but the ability to do it is very nice.

    A lot of problems that are mentioned here are worked on. The extensions got a lot better recently. Implementing any ad service, game center stuff, facebook integration is all possible. I’m quite optimistic about the future.

    To avoid some problems, I am doing my own little framework where I put stuff that I know works on every platform I care about. It’s probably a good idea to use some kind of layer on top of NME as already mentioned.

    Also, C++ rebuild time is on par with Flash build on my Mac. Not sure why the cache got removed. I’m using Sublime Text 2.

    NME takes time to master it since it’s quite complex in my opinion. It can be very, very frustrating. The switch out of it was probably a good move since you will be much more productive in areas that you care about. I just wanted to say, don’t narrow NME just to iOS and Android.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s