Develop Reference

Is it a good idea to write mobile games in ActionScript3 rather than Java / Objective-C?

Hey,
I'm writing a simple game based on my physics engine for Android (in Java). Because I want to play with some special graphic effects performance is very important for me.
I read on the Internet that you can write an application in ActionScript3 and then just export it as an iPhone/iPad or Android application. That means, I wouldn't have to rewrite everything from Java to Objective-C if I wanted to make version also for iPhone.
Do you have any experience with writing games in ActionScript3 for both Android and iPhone/iPad? Are there any significant advantages / disadvantages?

I have made games with both AndEngine and air for android. Air for android is vastly slower. If you game needs performance, Air 2.6 - the current release - will not be able to handle it.
AIR 2.6 can handle simple games. One with a little performance to spare.
I am hopeful that AIR 2.7 (in beta now) will improve things, since it supports OpenGL. But for now I would have to say stay away from AIR for performance games.
To see an example of a simple game made with AIR, check out this one made my a friend of mine:
http://www.appbrain.com/app/kibble-katchers-free/air.com.munchiegames.KibbleCatchersFree
It plays OK, but chugs sometimes if you have a lot of things going on at once.
If your game is going to be more intensive than that, pass on AIR.

In my experience, it's always better to write applications in the native language for the device. Of course, depending on the scale of your game, the advantages may not matter. When using Flash to export to iOS, you are limited to what you can access on the phone (like UI widgets and features like accessing the camera). I've also read that Adobe is not going to include this feature in future versions of the Creative Suite. So you may lose support for your game. In my opinion, there are better tools to develop for both devices. Check out Corona or Unity.

MY impression is no, not a good idea until they get the performance up. Though this post makes it look pretty decent. Ive done an app for the playbook, and the simulator rendered it just fine, but once I saw it on the actual device it was pretty slow. I didn't realize there was a scroll box already there, and I made my own implementation with on enter frame listener and it was pretty slow.
If you're going for an iOS, then you end up with bigger file sizes. So while flash/as3 is great for prototyping and some simple applications, I would suggest using lower level language that doesn't have to be reinterpreted.

Perhaps the AndEngine could be something for you. It's a 2D Game Engine for Android and it supports physics. I played a little bit with it and it's really powerful but simple to use.

Performance is great, but think also about your game success in audience coverage - the flash is easy on web embedding. The flash is platform and its VM continuously enhanced due performance needs as well as mobile hardware. Try to write once and for all as possible)

Wine like for Android

I am pondering the idea of a Wine-ish compatibility layer on Android.
The idea is to run Symbian apps on it as both OSes share ARM hardware.
I have no knowledge of Symbian but I think that given the hardware capabilities of Android devices this could be done with less effort than Wine's windows emulation.
What would be the most significant difference to overcome in this emulator? (threading, storage, ...)

The real problem is not going to be code execution, but the API's to do things like graphics, interact with hardware, accept input, etc. If you have documentation of the original and android has the capability, API translation layers would be possible.
But android's security model outright prevents a number of things that are possible on other phone platforms, and combined with it's "java apis only" allows only inefficient means of doing things that can be done more efficiently on others.
This is of course all about application-level emulation/api translation. If you are willing to modify the android platform itself, supporting just about anything else for which you have documentation (and licensing?) within the hardware capability of the device should be possible.

Hardware capabilities of a device have nothing to do with complexity of an emulator to be hosted. It depends on Symbian's design and complexity.
And, even more, licencing. Even if one could make a Symbian emulator for Android, its legality would be questioned.
It's difficult to answer your question in detail, but since Symbian is open sourced (and Android too), if you've got the time, it shouldn't be too hard to see what sets them apart.

QT is used for the latest symbian OS, and has been ported to Android, you could write apps in QT build for each platform

the problem for writing an emulatir are variouss.
If the Symbian apps are written in in an interpreter language like Basic or similar then an emulator couldn't be too difficult to write. I did such stuff once to make the same code run on linux and windows, and I used a translation API for all calles coming from the software directed to UI, input/output.
I wound guess that the UI capabilities of Symbian are a subset of the Android functions so it would be not too difficult to write a WINE alike thing or an interpreter that runs the Symbian code on different hardware - IF it is only in high language.
But be aware there could be some machine code in the appps and that is processor specific. Most of the Android tabs nowadays run on Tegra, Tegra2 or (soon) on Tegra3, some may run on StrongArm or Arm, some may run on Intel Atom (x86 architechture), so this might get more or less impossible if the CPU isn't binary compatible like ARM / ATOM. Then you need to emulate the CPU as well and that might eat so much performance that you need a 4-5 times stronger machine to run that stuff smoothly.
It won't be too difficult to crack Android to execute Linux-alike binaries, but for sure this "mod" will affect the ability to use or download stuff from regular appstores.
With some apps you might have even more headache, e.G. my MP3 player from Korea runs on Strongarm, but it also executes Flash games from various sources. When there is no Flash player - and Google announced something like dropping support for Adobe Flash - it won't be usable.
The "most wanted" is obviously the Ovi Maps, probably that stuff could be easily converted to another app having offline navigation capability :-) People wrote "Gaia" some years ago, an open source viewer for Google Earth (and later forced to give up) so it can't bee too difficult to realize at least this.

Developing for Android in Java or Adobe AIR or Titanium or PhoneGap?

I have been developing for Android since some time now and I found Java as proper way of doing development in it. But, now there are number of options available for developing in Android such as Titanium, PhoneGap and Adobe AIR.
The question is who will come as a winner for Android development. I have read lot of comparisons between Titanium, PhoneGap and native Android development. Now, with Adobe entering into it too, what is the future of Android Developers who develop with Java as the programming language.
Since, if one can develop for Iphone and Android with Titanium and Adobe AIR then why will one want to waste time and money for separate development.

The biggest reason I can think of is that using the native language/libraries of the platform (in this case iPhone or Android) is that it will allow you to provide a user interface/experience that is more in line with what the system designers intended over what will likely be possible with something like Adobe AIR.
That doesn't necessarily mean that AIR is bad, or that you might not be able to develop a good application, but since you'd be targeting multiple platforms with the same application code, and each platform has it's own subtle (or major) differences that you can't always account for, you will inevitably be forced to take a "least common denominator" approach to building an application that will run on all of your target platforms and behave consistently across them as well. This might not sit well with some users who expect a certain level of capability as you may not give them a consistent user experience compared to other native applications.
This is a long-standing issue with cross-platform application development -- the design philosophies and behavior of each system are intentionally different (otherwise why would anyone use them?), so your bound to run into problems making an application work 100% the same across them all.
As someone that has done cross-platform development in the past, I can say that while you can do it well in some cases, and using something like Adobe AIR might be a good avenue towards getting more familiar with a particular platform, but a lot of times it's just more prudent to buckle down and build an app using a system's native libraries/languages over a cross-platform solution.

It is quite simple actually. Developing an Android application using Java (the normal APIs) will allow you to a) target possibly all Android devices as all share the same base API and b) it won't put limitations on your application (or at least no limitations with the only limitation being the API).
Now PhoneGap, Titanium and Senza are all web-based frameworks which have certain limitations. You can't access certain functions of your phone as they simply are not some kind of replacement API it's just a framework.
Now Adobe AIR is another story. I'm not sure what functional limitations Adobe AIR will have but I know that there is quite a limitation when it comes to what devices you can target. There are some minimum requirements for Adobe AIR to operate which are
Android Device Requirements for Adobe
AIR
Google Android 2.2 Operating system
ARMv7-A Processor OpenGL ES2.0 H.264 &
AAC H/W Decoders 256 MB of RAM
Which means you can target devices with earlier API versions.

Titanium compiles to native platform controls, but you must to use web languages like HTML and js to develop your application.

With special version for each platform you can design UI following system guidelines.

There seems to be an overall confusion regarding what Titanium is... It compiles to native platform controls.
The majority of the respondents have incorrectly stated that it is web based and that is not true.
However, that is true when it comes to phoneGap

Android SDK vs. Adobe AIR: Pros and cons?

Has anybody blogged about this comparison, or does anyone want to give it a shot here? Would be nice to see some reasoned thoughts on Adobe AIR on Android vs. the "native" Android SDK (in Java).
Edit: Despite few views and no answers, I'm leaving this question up here since it's a topic that needs to be covered at some point... but if it gets no attention I'll delete it in a few days.

I think it's ultimately very similar to the question of whether to use AIR or Java for a desktop application. Ultimately it comes down to three points:
Does AIR do everything you need? Obviously the android SDK gives you complete access to device capabilities, but AIR purposely doesn't, in order to stay portable. For example, AIR may not support intents, at least initially (I don't think Adobe has announced yet one way or the other). Also, AIR requires Android 2.2. If those limitations are troublesome, regular android SDK may be best.
Are you looking to make something that would be well-suited to doing in Flash? If you're planning a design-heavy app with animations, video, sound, or the like, then building it in Flash may be significantly easier than using Java. On the other hand, if your app will be pure code using only standard visual components, then it might not make a lick of difference which platform you use. Or on the gripping hand, if you'd have existing Flash animations or the like, then trying to shoehorn them into a Java app will be bothersome.
Are you targeting other platforms besides Android? If so, AIR may be a big win, as the same app content should run on windows, mac, linux, and later on, other devices that plan to support AIR, like Blackberry, some TVs, blu-ray disc players, etc. If you are only targeting Android, AIR may lose some of its appeal.
I hope that helps some. Realistically, unless you're effectively locked out of using AIR because you need something it doesn't give you, or effectively locked into using AIR because you're doing design-heavy work and you need the tooling, then I think the pros and cons of the two SDKs are largely questions of convenience. Either platform will work, so it's merely which will get you to the finish line the fastest and most reliably.

One issue to consider is compatibility with Android devices. Both fancy smart phones and cheap phones run in Android, but they don't have the same capabilities. Even if you application is simple or can be done beautifully in AIR, its relevant to mention that AIR is not compatible to all Android devices.
Some very popular devices currently sold (such as Samsung ACE and other "cheap" devices) use ArmV6 chips, and AIR or Flash are not compatible to this architectures, even when running on Android 2.2 or so.
AIR is interesting because same development works in different technologies, but consider that AIR doesn't run on "old" iPhones either, its only guarantied to work on new technology with big processors.
Check this Adobe link http://www.adobe.com/flashplatform/certified_devices/
AIR should be ruled out in your decision of technology if in your requirements you are targeting as much phones as possible, including those that are not so fancy or new.

I have experience with AIR mostly and little with Android SDK when I was building a native extension to AIR. My biggest hurdle with AIR is it's immaturity, it's bugs, and it's inconsistent behavior. Yes, you can go to the shiny page at adobe.com and see how cool is the AIR... All bright with tons of features which seems to cover all your needs. Yet, once you start building your app you'll find many ugly surprises:
Stage text in not working appropriately. link besides this bug StageText has few other bugs, like behavior in Scroller for instance.
Sound() object doesn't play the stream (it does on emulator only). link
Lack of features like AEC makes AIR useless to whole list of chat applications, as you'll will hear echo and screaming noise. link
Overloaded (and immature for mobile) Flex SDK (I hope folks at Apache will rewrite it from 0 and make it more manageable).
No H264 support on iOS devices: link (yes, I know it's Apple problem, that they want to control HD delivery on their platform, still it's Adobe problem too, as they couldn't fight right to bring their technology to forefront).
Sound object doesn't take variable bidrate (only 44.1KHz is possible). Flash "second generation" Speex codec samples at 16Khz. Now, try playing this back through Sound and you'll enjoy a funny circus. At the end you will need to write your own upsample algorithm.
I'm sure people will add more to this list. So, my answer would be native SDK is more preferable for anything serious. You won't work like a QA person with it - testing countless little examples trying to understand why an AIR feature not working, shuffling internet for answers and looking at AIR bug database... only to find that critical bugs are sitting there from release to release. That is my experience with AIR. Going native SDK makes your application not really "cross-platform", but AIR SDK can't claim this title anyway for anything more serious then couple of "Employee directory" examples. And if you will need to build for the other platform, you will just use native tools for it.
GL.

3D Engines for development on any mobile platform

I am planning to develop a game for all of the mobile platform and have pretty much zeroed down on the concepts of the game. but the only issue I'm facing as of now is that I have no idea what would be the best libraries + 3d Engine to us to achieve the best results on the hardware on some of the upcoming mobiles. I'm talking about the iPhone 3GS, the new WinMo and Android devices with the famed Snapdragon, other processors from Samsung, ARM, Qualcomm and even Intel and AMD.
as of now i plan to use the ogre libraries for now, but then what will offer portability?? This is much more of a design question rather than just coding. Any help is appreciated, others who wish to collaborate are very much welcome too. just drop me a mail.

I don't know much about Window Mobile, but (right now) there is a barrier to compatibility between Android and the iPhone: managed vs. native code. Android highly encourages you to write in Java, whereas the iPhone requires Objective-C or C++ (or C). Though Android does have a native development kit, they don't currently expose many libraries. They will add more APIs over time, but the Android devs will continue to encourage Java development, since Dalvik bytecode will run on any new device.
This is just my opinion, but I would focus on just one platform at the start. Pick your primary platform, write your core game code in portable C++ if you can, and keep the platform-specific parts separate from your core game code. Your goal is to get your game published. Once you have some money coming in, then start focusing on your second platform's port.

I would recommend you to use OpenGL ES and STL. Both Android and iOS platforms become more compatible with OpenGL and STL library, and it looks like every other mobile platform would follow this course (except, perhaps, Windows Phone 7.)