IBM Worklight or Qt for a small Android/iOS multiplayer game?



  • I love Qt for:

    • I have write some small desktop app with Qt.
    • I have test a simple Android app with Necessitas.
    • I love C++ for performance.
      but:
    • Qt not officially support iOS.

    And to day I heard about IBM Worklight (I still not sure what is it but I think Worklight use HTML5 just like the way Qt use QML).
    Does anyone have any experience with the two frameworks, please let me know some pros and cons of them.
    Thanks you!


  • Moderators

    Well, iOS support is as official as android support:-)



  • But now, not both of them in "supported platforms list":http://qt.digia.com/Product/Supported-Platforms/.
    It seem Android will come to the list first (and I must wait for a while for iOS, is it right?)


  • Moderators

    Both iOS and Android support in Qt 5 were announced for 2013 at devdays in Berlin.

    The iOS port is supposedly more challenging due to restrictions Apple places on binaries that are uploaded to its app store: Basically we are using v8 which is not allowed, so there needs to be some changes there.



  • Not that I defend the restrictive politics of apple, but see where external dependencies get you. This issue wouldn't even exist if Qt wasn't all about QML, which relies on a javascript execution engine, and had a native API to use QtQuick with.


  • Moderators

    Qt Webkit uses a javascript engine as well, so does Qt Script. Both are pre-dating QML by quite a bit and could have gotten us into a similar situation.

    I quite frankly doubt that there would be much interest in having Qt on iOS at all without QML. It is the hot new thing and people are really excited about it (yes, not you, I know:). So I am happy to have it.



  • [quote author="Tobias Hunger" date="1353952240"]Qt Webkit uses a javascript engine as well, so does Qt Script. Both are pre-dating QML by quite a bit and could have gotten us into a similar situation.

    I quite frankly doubt that there would be much interest in having Qt on iOS at all without QML. It is the hot new thing and people are really excited about it (yes, not you, I know:). So I am happy to have it.
    [/quote]

    The ios sdk itself don't have anything like Qml. But ios apps are in the forefront when considering graphics, animations, UX etc. So I think improving the current widget api was what was needed instead of creating something like Qml. Frankly I don't believe a declarative language provide any advantage when creating UIs. Obviously some people think so. Forget our Apple dislike for a moment, Cocoa touch don't have any declarative language for UI and it is very easy to creating cool UI using cocoa touch.

    Sorry, but I don't understand why Qml is called hot new thing. I believe what we are trying to achieve with a declarative language can be as well achieved with a good native api as well. I see
    a few people here really like Qml. It is not that Qml is bad, but I just feel it wasn't necessary.

    I'am excited about a Qt port to ios because we get a high quality cross platform native api. Qml has nothing to do with it. I think, QWidgets on ios should match ios native controls. Having said these, I don't have a Qt implementation point of view. Does Qml provide any advantage to Qt implementors, Qt being a cross platform framework ? ios sdk don't have to worry about multiple platforms.



  • bq. Frankly I don’t believe a declarative language provide any advantage when creating UIs

    It provides a big advantage in the case of HTML, where the markup can be made to ONLY represent structure, which you can then style and re-style the same structure into fundamentally different graphic representation. This allows for great flexibility, modularity and dynamics in the context of a dynamic UI, not cliched animations.

    Unfortunately, QML doesn't really offer that degree of separation, you pretty much have to include a single fixed style along with the UI hierarchy, which leaves very little room for dynamics in the design. Note that "dynamic design" and "dynamic design elements" are completely different concepts.

    On the other hand, as a follower of the C school, I really prefer the JSON syntax of QML, it is faster to type a closing } instead of the element name. But then again, there is stuff like zen coding, which solves this little inconvenience.

    The reason QML is so appealing is the ease with which you can create rudimentary and common usage case applications. The "quantity over quality" paradigm is particularly fitting the commercialism of today, QML would inevitably result in more Qt applications compared to QtGUI, especially with the latter being left behind in an outdated form that doesn't really fit modern day UI aesthetics. I don't mean the implementation but purely the visual aspect of it.

    Overall, QML is neither hot nor new, maybe to some poorly informed individuals, but this concept has been around for quite a while. What I find most troubling is the fact QML appeared both so late and so poorly designed, in many ways inferior to much older solutions it should have learned from the mistakes of. If you are going to do it so late, at least do it right, it is a shame really. Honestly, QML would have been incomparably better if it was merely a "HTML5 done right" instead of this ill-conceived and forced upon developers concept. I honestly don't mind the client side JS, it is pretty much the best solution, way much faster than other dynamic languages like Ruby or Pyhon, even if ugly and poorly conceived itself.

    But back to the question of the OP - for a small game for mobile platforms, I'd recommend MoSync - it supports both iOS and Android, and it offers C++ as well as HTML/CSS/JS.
    Or perhaps even better, the Blackberry Gameplay, which has a neat API and supports desktop platforms as well:
    http://qt-project.org/forums/viewthread/20366/



  • For games, one of the crossplatform game development frameworks like marmalade, unity may be better than general purpose frameworks like Qt or Mosync. For general apps, I like the Mosync approach than Qt, if you want to use a declarative language, you can use html / css and the designers are already familiar with it. But I guess Qt already supports html for UI. But I haven't used it and don't know how well it work.



  • I think deploying a game with Unity on android is going to cost you quite a lot. You are right thou, and that is the reason I also recommended the Blackberry Gameplay which is game oriented, not as high level as Unity but still...



  • oops, I missed the BB gameplay part



  • Hi,
    if you already know Qt & QML, "V-Play":http://v-play.net might also be interesting for you. It is a 2D game engine based on Qt & C++ with a QML API for all kinds of 2D gaming components ( http://doc.v-play.net/beta/vplay-group.html ). It supports iOS, Android, Symbian, Meego, Windows, Mac OS X & Linux.



  • Just have a look at V-Play, I can't wait until they release!
    IMO, if QML some how like FXML in JavaFX (you can handle almost all GUI elements and its properties with FXML just like using java code, very easy to communicate between FXML and Java Controller class), I will love to use it.
    At the moment, I do not exclude it, if it provides the components that I need, I will use it.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.