It has been a nice run of about 7 or 8 years now that we have developed Flash browser based games for the web exclusively. Of course with the ubiquity of mobile devices, things have changed. Clients are starting to demand, almost assume, that games will work in the browser - on the desktop and on their tablets.
Putting aside the whole discussion of using an HTML5/JS solution instead, we're sticking with Flash for the next project and need to figure out the best way to get it to run on the desktop browser and on the iPad, while maximizing code re-use.
Given the current state of technologies today, what is the best path? This game will be a 2D side-scroller type game with some physics, and development will be done mainly with bitmap graphics (as opposed to vector) and spritesheets.
Here are what I understand to be my options:
Option 1: Develop the game targeting the 'standard' flash player for web (11 or higher), then port to an iOS AIR 3.2 app, doing appropriate optimizations like the ones outlined here.
Option 2: Use Starling/Stage3D for desktop, and then port to an iPad app. Just wondering if starling is ready for primetime making production quality games for mobile + desktop. Does Stage3D still work well enough in software mode on older machines?
Option 3: The new feature in CS6 that lets us publish to HTML5. Is this even close to mature enough to publish a full game? The benefit of this solution is that it could run in the browser on the iPad instead of being a separate app.
Thianks so much for any guidance.. I'm also wondering about pitfalls, and optimization techniques involved in any of these. But it seems the underlying question in all this is should we use Starling/Stage3D or not?
Definitely Option 2.
You could go with Option 1, but performance on mobile would likely suffer without Stage3D hardware rendering.
Option 3 is only a good choice if you're designing/porting ad banners with basic animation, should be avoided for game development.
More here: Adobe Gaming SDK
Related
I am considering launching a somewhat larger game project for mobile devices (mainly iOS) that uses box2d and am considering using Flash Builder. There are lots of games with great performance built on coscos2d and our staff is fluent both in coscos2d and flash builder.
What apps are out that to look at developed with flash builder?
It seems like flash builder might be kind of new to have a lot of solid games so if you are developing a game with Flash Builder how is it going?
thanks
I feel I have by far much more control with cocos2d than Flash Builder. I don't know much about Flash anyway. However, I can at least tell you that I have a rather large cocos2d game project, and so far, we never had an issue regarding features.
Cocos2d supports all Apple platforms, and there are some nice ports for Android and such too.
Anyway, I think this depends too much on your actual game project. What key features it has?
So after weeks of research I still cannot make up my mind as to which Game Engine to use, so here I am.
My question is which Game Engine will give me maximum productivity seeing that I:
Want to program in C++, Java, or a Scripting Language
Want to deploy the game first to the iPad, then other mobile devices if possible
Want to make a 2D game
Do not need physics
Don't have money [ Yes sad truth :'( ]
Want to make a game quickly and don't care much about the inner workings of the Engine
Want a Tile Based / Multiplayer / Turn Based Action Game
Don't have a Mac or XCode
Cross-Platform for Mobile Devices
I am not looking for a subjective answer I want to know which Game Engine allows me to do this or be closest to being able to do it.
Try Gideros Studio. It's free, has an IDE, runs on Windows, has tilemap support and cross-platform (iOS & Android). I've gone through your requirements and the only thing you might consider is that Gideros Studio uses Lua, a simple language which is powerful enough to be in thousands of mobile and desktop games today.
Disclaimer: I personally know the founder of Gideros Mobile.
You're overthinking this!
How do I know?
… after weeks of research ...
Want to make a game quickly ...
The only real requirements from your list are:
must be free
must run on Windows
(ideally) tilemap support
All the other points are mostly irrelevant. You want to develop an iPad game, then limit your search to the few available engines which allow development of iOS apps on Windows. Here's for hoping one of them is free, I would be surprised. Corona SDK might fit your bill besides not being free. So maybe use that (you can use it for free but not publish), then make a game quickly, and stop thinking about which engine is the best.
In other words, the time it took you to research all the engines was the time it took someone else to create and publish a game. You can always switch engines for your next project if you want to, but unless you have some experience picking an engine and knowing what's important even thinking about other engines is pretty much a waste of time.
2 questions:
Can someone tell me if unmanaged c++ code will
be supported in future versions of Phone 7 OS for all developers?
What are MS reasons for not
supporting unmanaged c++ code?
This answer is purely speculative, but I feel that most others who have answered this question miss the point by a long shot. Let's for a moment assume that this is not a vindictive decision by Microsoft, but instead actually a very well thought out engineering decision that has absolutely nothing to do with content restrictions or otherwise. Those issues are just a bonus for MS
Microsoft is entering into the mobile market, this time for real it seems. Pretty soon there will be tens of millions of Nokia phone being shipped using Windows Phone and whatever they get on top of that will just be gravy. Windows Phone though still hasn't really found its home.
In the next year or two, phones, tablets and laptops will finally start converging into a single device. People will carry their phone in their pockets, but that phone will also be the CPU unit of their PC. That means that by simply sitting near a wireless HDMI monitor and connecting a keyboard and mouse via wireless USB (or bluetooth if we're all unlucky), the user will have their entire PC with them at all times. Tablets will become just a battery powered touch screen which interfaces to the PC in your pocket.
So, all software written for Windows Phone should be able to run unmodified on a PC, a tablet and/or a phone. This is because there's a huge chance that the PC you're running will be either x86 or ARM based running Windows 8. When the PC is in your pocket, the user interface you'll see will be the Windows Phone GUI. When you're hooked up to a monitor, you'll see the ribbon interface. But the underlying OS will most likely be Windows 8, not the Windows CE that is currently used.
Based on all this, the only way Microsoft can insure that developers who invest in producing apps for the Windows Mobile market will not be screwed and that users of Windows Mobile devices won't be shorted when the newer platform comes around is to ensure there is a standard system for running apps on all these processors.
Even now, writing for Honeycomb is a nightmare since if you develop native code, you have to support both ARM and x86 and there's no real support mechanism for it. The only solution is to develop, package and ship two versions. Writing apps for iDevices are a little easier since there's no overlap. x86 on desktop, ARM on device. If you have to use native code on device, ARM is all you need. Even then, there is fat binary support on both device and desktop, so this won't be a problem except when optimizing.
In the end, the decision by Microsoft to stick strictly to .NET is probably a good one. Once they have a gazillion Nokia phones on the market and things have settled a bit, native code could be a real possibility.
These answers are for the application development perspective. OEMs can write native code today, as that's how they create drivers, but that's not open or available to most developers and therefore of no use to most.
For #1 Microsoft has made no announcements, so only Microsoft knows the answer and they're not saying.
For #2 it's all about code security and overall platfrom stability It's very tough to sandbox native code and they don't want your app being able to affect other apps or the platform itself. The general idea is that you should be using Silverlight or XNA for application development, so that's what they expose.
Windows phones will go nowhere with native support. Games and other more intensive apps are driving sales. Android was forced to blow the lid off of its NDK to support the games industry. As far as supporting multiple processors, etc., those of us doing this kind of work have been doing it for a long time, so its no problem. Already handling Intel and ARM without a problems with our systems.
EDIT, finally: for WP7 unmanaged code won't ever be supported, but in Windows Phone 8 - yes it will! They've just announced it. Native apps, C/C++, iOS/Android portability and code sharing, DirectX. You'll need Visual Studio 2012 and Windows 8 for WP8 development, though. Looks like VS2010 is not getting the requisite WinRT SDK.
The nongame UI, however, will still be XAML-based. Win32 API will not be supported. They're pushing a model with managed UI layer and a native middleware beneath it.
SDK will be available later this summer.
For the sake of posterity, here's the pre-06/20/2012 answer:
Microsoft probably can.
To ensure platform closeness, as a means for attaining stability and UI consistency. To enforce app isolation. Also, to make jailbreaking/rooting harder.
EDIT: if you want a native SDK on WP7, like I do, please go sign this petition and/or that petition. Thank you!
EDIT: see this.
EDIT: also this. Still not official, but this rumor moves the timeframe for native app support even closer - to the upcoming Tango release.
I believe MS will support native development like C/C++. Really. Seriously.
Because, for end users, one of the killer app is game. And Most of game codes are based on C/C++. JS or C# based codes are exist, but meaningless from industrial perspective. Consider big players in game field like Unreal or EA. They made huge investment on C/C++ codebase. They won't give it up. In other words, MS has no power to force them to spend money for .NET. Even Xbox360 development offers C/C++ development. Because of that.
And leading platforms like iOS/Android all supports native development. WP can't bear up the situation without any game from big players. MS really wants 3rd path games, and offering native code is the only way to get them.
Of course, this can be applied to other apps which are not game, but games are biggest one. When C#/XNA just came out, there's no library. People had to make everything themselves. Now there're a little more, but still meaningless for professional games.
If MS won't offer native environment, just don't go there. MS wants to make developers to use managed .NET code, but .NET has too many limitations can be solved with only unmanaged code.
The only question is just when will MS support native development.
Hey there,
So I've been heavily focused on design/development using web technology for the last few years (php/mysql, javascript, etc), and I'm a bit hesitant to start learning C++.. At the same time, I see it as a potentially enjoyable learning experience.
To keep things brief, right now I'm developing an online app that plots out certain locations on a map, and you can sort through these locations and do a bunch of other nifty things..sorry to be vague. The point is: I don't see any real advantages of making this an actual "app" when the entire functionality of the app itself can do quite fine through the modern mobile browser..
Not to mention that, by living in a browser, it's much less proprietary
So, my question is: Is there any way to make a simple app that's basically porting the user to my site? I guess it'd be convenient that as an app, the user has a nice little icon to click on when they do need to access it..
Android development relies heavily on Java. So you are all ready on the right track.
However if you just want to make an app that brings people to your website, running javascript I am guessing, this is easy to do with android.
Android supports the webkit browser and has a view group called WebView. Your app can be nothing more than a shortcut on a desktop that opens a webview directly pointed to your website. It could add other options to point to other parts of your website like bookmarks.
WebView webview = new WebView(this);
setContentView(webview);
weview.getSettings().setJavaScriptEnabled(true);
webview.loadUrl("yoursiteurlgoeshere);
A lot of apps on the market are actually based around a WebView. There are other classes that allow you more control over the view, like whether links are opened in the webview or in a new browser, or whether the user is allowed to use the resize options, etc.
Welcome to Android.
There is a massive article on exactly this type of idea. It discusses a number of different things and is well worth the read if you are indeed interested in making a cross-phone web-app. It talks about an html5 facility in the works for creating such a thing as you describe, but it isn't quite universal yet.
Here is an article on making an iphone app in html5.
You can also use phonegap to port your design to andorid.
also, check out a jquery plugin calld jqtouch if you are interseted in developing touch capable applications quickly.
If you are worried about speed and the issue of internet connectivity, you can use html5 local storage features which are available on both android and itouch. Ibm has a great series on these issues and part 2 covers local storage.
No. The problem with web technology on a mobile device is the delay. You are far away from the server, so a lot of the things you can easily do with a normal client creates a very bad user experience on a mobile device. The roundtrip time is simply too large. You have to move much more functionality to the client. This client is also less powerfull, and tends to have limits on caching large elements
How is this related to C++?
There is also a C++ API which is only recently available. Google calls it the NDK (Native Development Kit). Information about it can be found here: http://developer.android.com/sdk/ndk/index.html
I personally haven't developed using the NDK. The only real reason someone would really need to would be to write a high-performance application that can't stand the overhead of the Java JVM--which is getting more and more rare these days IMO.
As far as creating a simple app with a web container in it, see Phobos' response. That is exactly how I'd do it personally.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have to choose a platform for our product. I have to decide between The Qt Framework and Adobe's AIR. I am well versed with Qt as I have worked for the last two years. I looked up at the Adobe's site but all the info about flex, flash, ability to coding in HTML/ActionScript is overwhelming and confusing. I cannot understand the following about the Adobe ecosystem.
I have the following questions on Adobe AIR:
What language do I use for coding my application? (not just defining the looks of UI)
Like in Qt I use C++. Is it Actionscript?
Can we say AIR is only for making UI's for apps.
Where is the doc for the utility classes along with AIR?
e.g. http://qt-project.org/doc/ for Qt
Qt ships with a huge set of premade widgets that one can use. Does Adobe ship with any such widget set and if so where can i see it as in url?
I understand flex SDK is open source. Can I make commerical apps and ship them ? Does flex SDK ship everything (compiler, utility classes/widgets)
How much does AIR cost in terms of licensing?
Is there something in AIR that is equivalent to QGraphicsView of QT?
If you needs to access a lot of native libraries, you'll need to stay within your QT environment. Keep in mind that AIR is single-threaded and is run on the Flash Player (something that was originally designed for frame-based animations.)
However, depending on the style of application you're building, AIR might suit you just fine.
Beware that AIR can get confusing because there's a few different developer paths to creating AIR applications: 1) using html/javascript and the AIR SDK, 2) using Flash/Actionscript and 3) using Flex SDK and/or Flex builder. The last one is the most capable as far as coming from traditional desktop development background.
Small apps that are Web 2.0 for hooking into web services are good candidates for AIR applications. Things like the IM client Digsby would be great. My favorite AIR app that I've seen thus far is Basamiq Mockups. Other useful apps are TweetDeck. These are good examples of the types of things that are well-suited to solve with AIR.
You should visit the Adobe Showcase and look at some applications: http://www.adobe.com/products/air/showcase/
Also, if you're looking to just get out of the C++ game, I believe QT has some java bindings now...also I remember some python bindings, but never look at those myself.
As far as QGraphicsView, people have done similar things in Flex. I tried Googling right now but couldn't find them initially, but people have taken things like A large image, and then only displayed a current region in the window. Also, in the next version of Flex, they're acutaly building an official ViewPort component:
http://opensource.adobe.com/wiki/display/flexsdk/Gumbo+Viewport
Go spend some time with this AIR application and then ask yourself if Adobe Flex and AIR are worth investing your time in mastering (be prepared to ask yourself why something comparable doesn't exist for the likes of C++/QT):
Tour de Flex
Tour de Flex is a desktop application
for exploring Flex capabilities and
resources, including the core Flex
components, Adobe AIR and data
integration, as well as a variety of
third-party components, effects,
skins, and more.
Some of your questions:
Flex can be coded in MXML and
ActionScript3. AIR additionally
supports HTML/DOM/JavaScript
programming as webkit HTML render engine is built into
the AIR runtime.
MXML is an XML declarative DSL that
gets compiled into ActionScript3
imperative code. It is quite good,
though, for declaratively coding the
graphical forms of the UI (i.e., the
views of the MVC pattern).
ActionScript3 has a heratige that is
founded on JavaScript, but it has
been embelished to the point it more
resembles Java or C#. It has package
namespace, classes and interfaces
with inheritance, class member
access protection keywords,
constructors, static members, and
some very nice additions over Java:
properties, events, data-binding,
and closures.
Flex style programming is also a single-threaded model that relies on asynchronous I/O interactions. This is a simpler model to program than multi-threaded Java Swing or C# .NET Winform apps, yet permits achieving the same net results of program behavior. I elaborate on that here:
Flex Async I/O vs Java and C# Explicit Threading
Flex is open source, you can download the SDK for free, there are no licensing costs associated with it. (see their FAQ)
They do ship a 'flex builder', which is some custom Eclipse I think, and which costs money, but you can perfectly work without it.
The docs can be found at adobe's livedoc pages. (which to some, is enough reason in itself to dislike Adobe ;))
I do wonder, if you are well versed in QT, why are you considering something else? Which advantages do you expect AIR to give you over QT?
I have some experience with both QT and Flex, but not nearly enough to weight one versus the other. I do know QT/C++ is much, much more mature than Flex/ActionScript.
If you already know QT, I don't think the time spend learning a new framework (and programming language) will gain you enough to be honest...
I've used QT and Flex (not so much Air itself though) and have found that Flex is faster for getting apps up and running as well as modifying, while QT gives you more control -- particularly in the installer. The Air app installer is pretty awkward, or at least it was when I tried it, though it may have been improved since then.
The big advantage of Air is that much of the code for it can be run in Flash inside web pages. You can't access the local file system etc. from the web for security reasons but just about everything else is portable.
I made the opposite move. I started working on Adobe stuff and moved to QT. The main reason for doing it was about Adobe framework limitations. When you are using Adobe stuff, you are limited to the tools that they produce, it is hard to introduce external frameworks or libraries, if can not do what you want with Adobe stuff. Usually, the solution to do this is to use sockets, which transforms a supposed "stand-alone" application on a client-server architecture. In addition, if you are using many external stuff it can be hard to manage so many different clients.
Using QT you can code in C++ and add any external framework or lib you want. Even though, some times it can not be easy to code it, is doable and with no "strange" system architecture.
If your looking for some examples of "fun" UIs using Qt and SVG, take a look at the KDEGames [1][2] and KDEEdu [3][4] projects. There's lot's of nice code there that uses QGraphicsView and SVG to created scalable interfaces. Of course note that's it's GPL so be careful what you "borrow" if your app isn't.
[1] http://games.kde.org/
[2] http://websvn.kde.org/trunk/KDE/kdegames/
[3] http://edu.kde.org/
[4] http://websvn.kde.org/trunk/KDE/kdeedu/
I'll second #Pieter's comment - if you already know QT, moving to a whole new environment is going to take a LOT longer.
QT has the advantage of being cross-platform, and very mature: there are libraries for Windows, Linux, and Mac OS X. I'm not extremely familiar with AIR beyond knowing it's from Adobe, but the product site seems to indicate that it's for rich internet apps (http://www.adobe.com/products/air/). If that's true, then QT would be the far better choice if you're developing a desktop application.