A fast, easy to use, free, and community supported 2D game engine
MrMojo
Member
I just came across this thing called AirPlay SDK. It's supposedly cross platform iPhone/Symbian/Android game development that is free for iPhone, and 99$/year for other platforms (for indie developers, which means you make less than 50K us per year)
https://www.airplaysdk.com/index.php
https://www.airplaysdk.com/features.php
https://www.airplaysdk.com/licensing.php
Has anyone tried it out?
bradparks
Member
Hmm.... Looks interesting.... It's in C++, but I haven't tried it out... Looks like it uses lots of opensource stuff, sqllite, opengl, etc... And it looks like it lets you develop in Windows for the iPhone and even build a binary there... So a mac might not even be required....
and it appears that after you start making more than 50K per year, it's 999$ a year per platform license...
bradparks
Member
Looks like a few big games have been done with it... Capcom's using it...
Resident Evil - Degeneration by Capcom:
http://appshopper.com/games/resident-evil-degneration
https://www.airplaysdk.com/newsarticle.php?url=Resident_Evil_Airplay_Press_Release.html
Backbreaker - Tackle Alley by Natural Motion
http://appshopper.com/games/backbreaker-football
bradparks
Member
Good to know... I'm downloading the Windows SDK now... From my understanding, you can still build the .App file on Windows, so a mac isn't required... I'll admit, it'd be nice though, as I don't have a Windows development machine anywhere.... Guess I'll have to borrow my wife's laptop! And I guess I'll have to download a trial of VC++ too...
mserougi
Member
I have tried installing this, build 204137, and I suggest no one does the same, cause nevermind the fact that I couldn't get the samples to work out of the box, when uninstalled it completely messed up my Visual Studio 2008 environment, compiler kept failing cause for some reason the SDK pointed bin paths to its own bin path! Anyway, I am currently re-installing the IDE, don't know how such an SDK could have ever been used professionally.
I tried it yesterday, have a little problems installing it and having it compile an example project but nothing serious.
I don't have a formed opinion yet about it, what i can say is that testing it in its simulator, the gameplay was a little choppy, also it run a 20 -25 fps top so i don't want to imagine how it runs on device :P
for what i have done, i would choose unity3d (or shiva3d?) instead although the price difference is great ($400 vs $99).
The great pro it has is that (teorically) you can develop and distribute not only for iPhone, but also to psp and other smartphones.
Also i can't read a full c++ program that deals with 3d stuff even if you pointed a gun at me :P
Hi, this is Tim, CTO of Ideaworks Labs who are the creators of Airplay SDK.
Thanks to the guys who've downloaded Airplay SDK and are giving it a spin.
pabloruiz55, one of Airplay's advantages is its high performance, particular for rich graphical apps like games. Airplay is extremely well-proven in this area; for example there have been 3 #1 iPhone App Stores games built using Airplay in the last 6 months (Capcom's 'Resident Evil: Degeneration', NaturalMotion's 'Backbreaker' and Activision's 'Call of Duty: World at War: ZOMBIES') all of rely on heavy 3D graphics/animation at good framerates. Activision wouldn't have trusted their #1 franchise to anything other than a top-notch technology platform.
I'm unsure exactly of what you are testing in the Windows Simulator. Is this one of the Airplay SDK full game examples? Are you running an x86 or ARM build? Debug or Release? I believe these examples are capped to 25 fps anyway. If you want to see how they run on device, just fire up the Deployment Tool, select your ARM binary, select your target OS's and click "Deploy All" - it's that simple!
mserougi, I'm really sorry if you've had problems with the out-of-the-box experience. Please could you provide full details of your HW/SW set-up? The best place to do this is on the Airplay public forums ( http://www.airplaysdk.com/forum ). Out of over 2000 downloads so far, we've only had half a dozen people report such problems, but in each case we've taken up the issues promptly and resolved the problems. We're taking the initial user experience very seriously so please do let us know the exact details of your case.
Keep an eye out for announcements of the Airplay Mac SDK around February. We're putting a lot of effort into it. Write your app in pure C++ in Xcode, compile for ARM, then click once to deploy to iPhone, Android, etc...
goldplated
Member
i found it pretty quickly... its Free to evaluate.. and here is the pricing page. https://www.airplaysdk.com/pricing.php
Before you get your wallets out I just wanted to add a word of caution to the idea of cross-platform development.
A number of years ago (2003?) I ported a game to a cross-compiling platform for mobiles. The promise was the same, build once and deploy to multiple (java based) devices. So I ported it and tested it all on a simulator. Ordered, built and ran it on the main device it was targeted at and it turned out that pressing more than one button on the phone would reset the phone(!?@#). The result was that I abandoned the project and the platform in disgust.
So here we are today, Apple has given a very high quality product which works(!) and riq + co. have given us a framework for getting content into the hands of consumers as we intended. We can either spend time learning/maturing a single high quality platform (which is what consumers want) or port content to multiple average platforms.
Some key points.
1) $99 may be cheap but you're investing something much more valuable and thats your time and effort. You'll have to learn a new framework (airplays) and make sure you test on all target devices to ensure consistent user experiences. For large dev shops (gameloft, activision) it sort of makes sense but for indies it makes no sense.
2) Are the returns for porting to other devices worth the effort?
3) If you are fortunate enough to have a super successful product then worry about porting to another platform when it becomes a problem and not before.
4) Do you work to the strengths of one device or stick to an average capability across all targets and hope for the best?
5) Each target device/OS may have quirks which means you'll need to address it in different ways.
http://www.airplaysdk.com/docs.php?url=/main/userguide/overviewofairplay/airplayconcepts/deviceinteroperability.html
6) Version controlled source code management for multiple targets can become a challenge.
7) It seems Ideaworks has had significant investment from ARM, which explains the low-level binaries and performance. Intel is hungry for this market but they're still behind, but who knows which way the atom processor is headed. Would this SDK still be viable?
http://www.entrepreneur.com/tradejournals/article/194248830.html
Anyway, some food for thought.
mhussa, you've made some great points in that post. I'll try to answer some from my personal perspective and that of Airplay SDK. Firstly, I'm not surprised to hear your horror story about some other x-platform "solution". There are many bad platforms out there. Airplay SDK is very different though; Airplay apps have already been deployed on over 300 different devices across 7 major OS platforms.
In your intro you say "We can either spend time learning/maturing a single high quality platform (which is what consumers want) or port content to multiple average platforms." I assume the single platform you refer to is Apple's. Obviously the only consumers who want content on that platform are the owners of Apple devices. What about the other 400-500m smartphone owners, i.e. 10x the Apple install base? They want content for their devices, not Apple's. Not all of them will be as app-hungry as your average Apple owner, but the combined opportunity still exceeds the Apple one. Currently the Apple distribution channel is by far the best, but it's also by far the most crowded, and therefore difficult for the developer to get their app noticed.
Now in response to some of your numbered points:
1) Yes you have to learn Airplay's framework. But Airplay's core OS-abstraction APIs are very standard POSIX-like. Airplay supports use of all standard C/C++ libraries also, including STL. Airplay supports OpenKODE, the emerging Khronos standard for OS abstraction. Airplay supports use of OpenGL ES 1.x and OpenGL ES 2.0 directly (for developers who are happy to ignore devices without hardware graphics acceleration; otherwise they are encouraged to use Airplay's own stream-based drawing API, which can fall back to software rendering, e.g. on devices such as Nokia N97).
In porting from Apple to any non-Apple platform, one has to learn the non-Apple framework in question (e.g. Android). There is a strong argument that porting from Apple to Airplay is easier than porting from Apple to any non-Apple platform, given the standard C-nature of Airplay, the quality of the desktop tools, etc.
With regard to testing, I would argue that Airplay's single-ARM-binary approach, together with the structure of app stores today, means developers do not need to test on every single device they are claiming support for. Let me explain. Firstly, using Airplay, the vast majority of your code path is identical ARM instructions across all devices. Our investigations have shown that, for a reasonably complex app, about 98% of the code execution path stays within the Airplay app (and is therefore identical CPU instructions across devices) and only 2% calls through the OS abstraction layer. That means the opportunities for per-OS or per-device bugs are vastly reduced, compared to the traditional method of porting and recompiling within the OS platform SDKs.
Secondly, the app store world today is (thankfully) different from the operator stores of yesterday, in that developers are not obliged to support all-devices-of-nothing. If a developer has a budget only to test on a few “hero” devices, then they are perfectly able to submit the app and flag it as available only for those devices. If the app is successful, the developer can afford to buy in more devices, test, and extend the reach of the app over time. Furthermore, the ability for developers to update apps on the store, and for consumers to get their money back (e.g. Microsoft Marketplace) opens up the opportunity for developers to test on key devices within each OS platform, flag the app as available for ALL devices, and potentially fix any per-device problems only if they get flagged by consumers.
Thirdly, there are some remote-testing solutions out there (e.g DeviceAnywhere, Perfecto Mobile) that are a pretty good way of “smoke testing” an app on any chosen device. Over time we plan to build up relationships with some of these services such that Airplay SDK licencees can use the services at a cost that makes sense.
2) “Are the returns for porting to other devices worth the effort?” Obviously I can’t make any predictions. But the key thing about Airplay SDK is that the developer doesn’t have to place their bets on which OS platform or app store channel will bring them the money. Nobody knows how the hierarchy will pan out; all we know is that Apple will still be No. 1 in 2010 (and probably for a while longer), and that there will be a No.2 and No.3. Once your app is on Airplay SDK, you can deploy to all OS platforms / channels and wait for the market to determine what platforms / channels are successful without incurring risk. That transforms the economics for developers.
3) “If you are fortunate enough to have a super successful product then worry about porting to another platform when it becomes a problem and not before.” That makes some sense, but there is still the issue of what platforms your port to, in what order. See (TWO) above – Airplay SDK means that you don’t have to worry about this. Also, if your app isn’t successful on the iTunes Store, doesn’t mean it can’t find success elsewhere. I know developers who are making more money on Android Market than they are on the iTunes Store, because the latter is so crowded.
4) “Do you work to the strengths of one device or stick to an average capability across all targets and hope for the best?” It doesn’t have to be one extreme or the other. Cross-platform does not have to mean lowest-common-denominator. Airplay SDK allows you quickly to write your app so that it works on all devices, then it’s up to the developer how much time they want to spend writing “if/then/else” code to provide optimised user experiences for different platforms. By the way, these optimisations tend to be by form factor (screen resolution, touch/non-touch etc) not by device manufacturer.
5) “Each target device/OS may have quirks which means you'll need to address it in different ways.” The link you provide within the Airplay documentation explains that, with Airplay SDK, you do NOT need to worry about these quirks, provided you follow some very simple guidelines. I quote “There is little that the Airplay application has to do explicitly to enable correct inter-operation with a target device…it is strongly recommended that the Airplay application calls s3eDeviceYield() at least once every 10 milliseconds.” The exhaustive unit-testing of the low-level (Airplay System) APIs on every target device is one of the things that hugely differentiates Airplay SDK from other supposedly cross-platform offerings.
6) “Version controlled source code management for multiple targets can become a challenge.” Airplay SDK is designed to facilitate a single source codebase across all targets. If a developer chooses to make per-form-factor optimisations, nearly all of these can be accommodated through “if/then/else” style codeblocks (the Airplay APIs allow dynamic querying of device form factors). Some developers may choose to use #if blocks sparingly, and create separate ARM binaries for separate SKUs, but this is rarely necessary.
7) Re. targeting ARM and Intel… Airplay SDK has always supported x86. Just select an x86 build configuration, and select Windows as the deployment target.
Hope this is helpful,
Tim
@Tim, thanks for taking the time to respond, and so politely as well which is always a good thing. However I still disagree with certain notions.
"The 400-500m smartphone owners"
I REALLY wish I could reach all those users on a SINGLE non-differentiating platform where what I had written always works consistently but that together with world peace is an ideal not a reality. I am NOT an apple fanboy but if I have to help one dominant platform to try and reach this goal then so be it.
A very interesting recent case in point is the google nexus phone, some believe that google have had to take the bull by the horns because of their frustration with licensees of the platform causing the exact same problems. Namely that of varying the implementation to differentiate but causing incompatibility problems at the same time (that naughty cross-platform genie again).
I think the adoption lag is still going on where people trapped in long contracts are waiting for them to expire so they can jump onto the iphone, and compared against the other available phones I can see why.
"Not all of them will be as app-hungry as your average Apple owner".
Well this is exactly what the rest of the smartphone making community have learned to their cost. Consumers ARE app-hungry, we want lots of stuff that we can do with our cool little devices. Content really is king. Yes there are problems with the appstore, its not perfect (and its not that old either) but its a start. It can be argued that an average product on a less popular platform (android/ovi) can be more successful, but for a small indie shop I would argue it may not be worth the investment, needs to be assessed on a case-by-case basis.
1) "The great thing about standards is that there are so many to choose from" - a genius.
I think most indies don't have the level of sophistcation required to deal with multiple platforms efficiently which is why I keep harping on about specialising on one major platform. Obviously mileage will vary depending on the developer but if anyone does tread this path then be aware of it.
Android has Eclipse and the open-source mindshare of some exceptional talent from all around the world, your product is good but not that good.
2) 3) 4) 5) 6) More of a trust issue on these ones, I followed the yellow brick road and the wizard turned out to be promising nothing more than a hope. I think indies already take on a great deal of risk, the appstore is a well-trodden path but if you want to go off it then so be it.
NOTE:I do not want to write "if/then/else" code to handle multiple platform/device/formfactor/etc specifics.
7) I didn't know this, it'll be interesting to see how this pans out considering where Ideaworks investment has come from.
Please note Tim, this is not a personal gibe. Ultimately it depends on the developers choice, I just wanted to offer a different perspective.
myliew1979
Member
Hi dear all,
I am trying to use Airplay SDK as well, but my objective is not to create 3D games on iPhone. All I wish to try out is to write some menu programs using AirPlay instead of COCOA on Mac as I am using a windows system.
I am a novice but is there any kind advice on that?
Thanks in advance,
MY
myliew1979
Member
Ok I have tried the UI builder, looks excellent, got to thank the Airplay pple for that.
Still need more tutorials or examples to get it working so that at least I can try deploying it onto some test phone simulators or an iphone (if I pay up the 99)... :-P
Is there any other better suggestions that any way I can get to do some test app on iphone without the 99? Just to at least know an Airplay simple 2D app works on Iphone?
It seems that now airplaysdk has changed its brand name to Marmalade. Does everything discussed above now apply for Marmalade too? or there are big changes? Thinking of using it... does anyone has clear answer if it is good to go with Marmalade for 2d game programming?
Thanks.
You must log in to post.
