This is a guest post by forum user michael, an Indie developer from Australia currently working on a word puzzle game.
With life, I’m inclined to take the road less travelled. For this reason, I also resonate with “alternative” development tools that work well, but perhaps use some other approach. So it was a nice surprise to come across V-Play.
Indeed as Christian mentioned in his opening blog piece, there are a variety of game-building tools, and I’m in complete agreement that it is worth the effort to build some simple prototypes using various tools. In this way, you’re able to ask yourself thereafter: which was the best way that suits my style, ability, application or feature expectation.
So that’s what I did and I hope my evaluation will help you in your decision a bit. I’ve used various well-known tools (Corona, Marmalade, Unity & Monkey) to get a feel for the process, features and importantly, determine my future level of commitment.
In brief, my general evaluation criteria was
- a balance of ease of use & features
- cross-platform (at least iOS & Android, bonus points for more)
- good Facebook support
- push-notification support
- good programming language or structured approach (i.e. ideal to have GUI/functional coding separation)
- TexturePacker/PhysicsEditor support
- ease of compilation/packaging
- size of compilation/output; size on device
- quality of docs & support
To varying degrees, all the tools tick most of the boxes, though some more than others and some need a fair bit of work to facilitate, e.g. Facebook integration.
Programming Language Comparison
Naturally as you’re aware, most products have pros and cons to each.
For instance, Monkey is a bit immature in feature set but remains interesting for its nice BASIC-like strongly-typed object-oriented language with cross-compiler, HTML5 and broad code emitter and platform capability.
Regarding Lua, I’ve personally never really warmed to it. There’s also the back-of-mind concerns to pay some attention to memory management with Corona, though to be fair this is also a concern with languages like C as well. Marmalade’s Quick’s feature-set is currently a bit immature compared to Corona and V-Play but to be fair, Quick was only recently released and is not Marmalade’s core offering.
About 10 years ago, I developed mobile-phone content using a proprietary XML-based authoring tool. That was a turning point for me in my preference for coding schemes with some degree of inherent “organisation” or structure. I also worked with PHP templating engines for the web, which again solidified my belief that there really is value is separation: declaring general scene or GUI-related code in one area, and functionality in another. It’s a good thing for maintainability and clarity. I believe QML makes for good separation and maintainability.
Code Size Comparison
As indicated earlier, I care a lot about the generated code size and size on device. I think users are generally sensitive to unjustifiably bulky apps, and sluggish start-up times. Corona and Marmalade are good for size. Monkey and Corona are fastest to start/launch apps, whereas Marmalade is the slowest. So far I’ve found V-Play is the middle, which is basically ok but I’m hoping for better in the future.
Here are some results from a simple HelloWorld app compiled for Android:
|Tool||Startup time (s) (from icon tap to see hello world)||Compile/download size (Mb)||Size on device (Mb)|
The file size from Unity is similar to V-Play. From research, the typical absolute minimum build size is around 8Mb, and about 20Mb on the device.
I’m guessing Corona only includes libraries that are needed to keep the resultant app size down, and I hope in time V-Play can do the same. V-Play’s web-based build system is convenient for offering QR download codes and makes it easy to test on multiple devices in a short time, so V-Play’s Build Server is a plus in that respect.
Why I chose V-Play
I think it’s worth to note about Qt Creator. At first, I thought I’d hate it, but lately I’m warming to it. I now think it’s actually quite a solid IDE, and contains useful features like profiling and designer (though I’ve not used it much). Profiling is not so common in these kinds of tools.
It may be worth to note I believe there is a degree of untapped richness in the third-party QML docs. I’ve realised there is a lot of old Nokia & current BlackBerry docs that are helpful, and the Qt project forums add some value. Though this info is scattered, it seems to be relatively easy to find, and I personally find it reassuring that QML is so broadly-used out there, and thus has applicability to V-Play. That realisation gave me a good overall impression that V-Play’s Qt/QML approach builds on a solid past, but also injects a fresh new approach for mobile/app development.
The other notable aspect to V-Play is that they have really paid a lot of attention to the needs of the new and experienced developers coming to their system by maintaining excellent documentation, code examples and useful tips to get you going. It’s really worth to review their introductory posts on QML and its interesting features such as declarative programming and property binding. Their forums are quite vibrant and support via email often produces a rapid response from the core V-Play guys themselves, which is very reassuring. In summary, I can’t help but feel V-Play has a good future because the team is very committed to making a difference.