Related
I don't know whether my question belongs here but I am asking it anyways. Why is there not a lot of shift in creating the game using HTML5 rather than creating a native game app, especially for mobile application? While I understand completely and assuming my understanding to be correct, for desktop games, a native game can use the graphics card in the computer taking the hefty load of graphics processing off from the CPU. What is the case for mobile browser? Does the mobile browser allowed to have the equal amount of processing resources as the native app? As far as I think, the processor is all and all in mobile phones. If this is correct then, I would think it would be more easier to create game with browser.
Is my understanding correct? Am I missing something here? What is the catch if I want to create game app using HTML and javascript?
A game as a native app would usually be written in a much more efficient language than javascript, for example Java on Android or Objective-C on iOS. Javascript is usually interpreted as it is run (as far as I know), and this affects the performance. Also, while you can obfuscate javascript to hide the implementation (if you want to protect your code), it isn't as effective as compiling a native app (I don't know how hard it is to reverse-engineer Java though).
However, WebGL is becoming more popular, and lets javascript code use hardware acceleration to accelerate graphics. When this is well supported on mobile devices, it might be feasible to make a complex game in the web browser. It certainly makes it more portable, and you could put it in a native WebView (or similar), for it to act like a native app.
Some examples here: http://www.chromeexperiments.com/webgl/
There's a couple potential drawbacks for HTML 5, one of which has already been pointed out, is a potential performance hit. This is sorta a big one, especially for devices that aren't capable of using WebGL. The other really big one for me anyways, is bandwidth use. Most phones (at least in the USA) are on fairly restrictive data plans, and thus if you're accessing the game via HTML 5, you're potentially eating into your bandwidth use every time you play, meanwhile a native app is downloaded once, and that's the last of the data usage...input lag is another biggie, particularly if your game requires specific timing. Granted, as speeds get faster on mobile devices this becomes less and less of an issue, but it will never be equal to what can be done locally on a native app. Lastly, as was pointed out, code hiding, you may or may not care about, but it's easier to do on a native app.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am an experienced AS3 programmer, and I've done Flash apps and games on the browser and on mobile (via Adobe AIR, e.g., on Android).
I am about to start developing a game (basic 2D platformer with pixelart graphics. Think about Super Mario World) targeted to both web and mobile platforms. Thus I'm searching for easy deployment to these two kinds of platforms, having basically the same source code.
I'm divided between choosing ActionScript 3.0 (Flash) or HTML5/JavaScript for developing this game.
My main question is, for those who've experienced the same situation before:
What is the safest way to go?
In other words, are there serious disadvantages with one of these frameworks that disallows me to develop multiplatform 2D games?
Or am I just dreaming and practical multiplatform (web and mobile) game development is not so possible? (does someone know how Rovio did it with Angry Birds?)
Here are some pros and cons that I already know:
Pros for AS3/Flash:
The state-of-art for web games.
I'm experienced with it.
(Almost) concealed source code.
On the web, it's browser-independent.
Can run as a "native" app on iOS and Android through Adobe AIR. It's not the best performance experience ever, but I know that you can get playable performances with it.
Cons for AS3/ Flash:
Performance on AIR for mobile is not optimal, so I might end up having to abandon a really cool but expensive feature (or even several features).
People are saying HTML5/Javascript will substitute it.
Pros for HTML5/Javascript:
It's possible to do Flash-quality games using, e.g., engines like ImpactJS or Akihabara.
Seems to be more stable and well supported on mobile in the future.
Deployment as native app is possible through PhoneGap, appMobi, etc.
Cons for HTML5/Javascript:
I have some basic knowledge of this technology.
Source code is wide open exposed.
Performance/behaviour is browser-dependent.
Lacks a solid framework or engine which is free of co$t$.
I've decided to forget about HTML5 for cross-platform game development, and specially for deployment to mobile.
The cons I've pointed out for Flash are much lighter than the cons for HTML5. Basically, for the pixelart kind of games, Flash on mobile performs really well, specially if using some nice engine like Flixel.
For example, the Flixel game Robo Run has great performance both on Android and Flash Player in a browser. I don't have an iOS example for the same game, but I believe it would perform as good as on Android.
Plus, Flash performance on mobile shouldn't be an increasing problem since the hardware on these devices just gets better and better.
After thinking about this HTML5 vs Flash issue for several months, I think there's no point adventuring in HTML5 cross-browser compatibility since Flash has proven to be a sort of Java for 2D games.
I think you have outlined the pros and cons pretty effectively. If cross platform and mobile web development is your top priority, Flash is a good choice. You will have all of the drawbacks you have identified.
If you use javascript/HTML such as the impact engine, you will have a different set of problems, and far less compatibilty on the web side.
However, if having the game be the best it can be, you will need to look elsewhere, because as of the present, there is no code once publish anywhere solution.
Unity 3D has good 3D and 2d mobile capabilities.
Appcellerator may also be your cup of tea.
http://www.appcelerator.com/
But in the final analysis, nothing will beat making different versions for different platforms. in terms of performance, and being best suited to the device. Be sure to evaluate how well your chosen solution allows you to monetize your app as well. You'll likely be building multiple versions just to accomodate differences in revenue models and ad serving capabilities.
=== Update ===
In March of 2012 Adobe updated flash for iOS and Android to include support for OpenGL graphics, 3D and 2D graphics are now possible using flash as a single code base for iOS and Android. The speed is good, and you also can deply the same game to web. Its a great tool. The one drawback is that flash relies on "extensions" to connect to native OS capabilites such as Intents on android or Game Center on iOS. If you plan on using native capabilities extensively, look out for this as an obstacle to development.
As ScanPlayGames said, html5 sound is a big issue. There are some neat WebGL ports though. Dominic at Impact has been doing some amazing stuff. He's got the best framework out there.
Rovio did a port using Google Web Toolkit for the chrome store.
I work for AppMobi. We've got a tool called DirectCanvas for iOS (Android will be coming soon) that increases the performance of games in the webview. One of our partners is developing a game that has the concept of Angry Birds (object A is propelled to destroy other objects). So Box2d support is there (the main thing holding us up from releasing). The performance is awesome, and the average joe doesn't know it's a webview game.
And trust me, you wont' be wasting your time doing development on mobile first for desktop then. We've got some stuff up our sleeves.
I'm a Flash games developer too and did some research on how to migrate to HTML5. There are a lot of obstacles if you come from the Flash/ActionScript3 world. One of those things is JavaScript itself - i know many people like JavaScript, but if you are used to AS3 it is hard. Another thing is the problem with sounds (as mentioned above). The most important thing is that i don't want to start from scratch and i want to use my skills or even migrate code from the past.
To make a long story short i ended up with Googles new programming language called Dart. This language compiles to JavaScript in therefore runs on all modern browsers. The most important thing is that Dart is very similar to ActiontScript3! Then i did an open source library which provides all the Flash API you need for games (The Display List, Bitmaps, Sounds, ...) - i tried to make the library as compatible as possible with the Flash API to simplify the process of porting the source of a game. In the end it was pretty easy because you only need to change a few things.
The game i have migrated:
An ActionScript to Dart comparison:
Some other samples and the link to the source:
I think a big disadvantage of Javascript is that it cannot detect picture's transparent regions so that it can stop reacting while mice hover or click on it.
Since HTML5 was released, any new solution has been created?
I have worked with some people who did a very graphics intensive HTML5 application and the worst thing was doing the sound I remember...every browser had to be done differently. Go look for some open source html 5 game frameworks where people have already done the grunt work of testing across browsers...there are some pretty good ones I think. You dont want to have to be the one QA-ing across environments.
I want to program my xhtml Web Applications without javascript.
What are the alternatives for creating interactive xhtml web applications?
Perhaps java applets which do the tasks of javascript?
Or is there another way?
Thanks for any help!
Javascript is hard to debug, is dynamically typed, strange OOP, could be replaced by any other language when that language will be cut to work at a browser.
I would also like some typesafety in my code what can discover many bugs before running the code.
--EDIT 2--
Have a look at http://www.scala-js.org/.
---EDIT---
So for now there is no real alternative to javascript what is as flexible, widespread and applicable.
What i think is applicable are frameworks/tools who compile one language to another like GWT or coffescript.
Thank you for the detailed answers. The reason for my question was, that web development is getting more complex every day. I prefer languages like Java for stable error outlining and type safety. JavaScript on the other hand is (in my opinion) mysterious in its ways and hard to debug (browser incompatibilities, silent errors, unintuitive operands, dynamic typing,....). I developed Websites with JS for years now and it feels horrible to me due to such debugging problems and code management. Yet the libraries are quite powerful and ease much of the work.
To have an interactive site you need something that can execute code on the client machine.
This is (at the moment) usually JavaScript. In the past this would have also included Flash or Silverlight (both of which are now on the wane).
JavaScript has a big advantage in that it can easily manipulate the HTML elements directly. While it is possible to do that with Silverlight it's not as easy as Silverlight is designed primarily to build self-contained objects.
Google Web Toolkit GWT lets you write java code which compiles to client-side xhtml+javascript. It relinquishes the page-based standard web approach for a more desktop-like interaction (if I remember correctly the API is somewhat similar to many desktop windowing toolkits).
You may (but don't have to) also develop the (java) server logic and have some client-server communication baked in for you by the compiler.
Have a look at http://code.google.com/intl/it-IT/webtoolkit/
Some JavaScript alternatives:
Flash
Silverlight
Java applets
This is not a recommendation, just a list.
If you're really that allergic to JavaScript, there are a number of frameworks that let you write server-side code which generates the JS for you, as other answers mention.
Check out Google Dart - it has reached 1.0 recently, and has started standardization process few days ago (ECMA TC52). It also compatible with currently available browser via highly optimizing dart2js translator, so you can start using it right now :). Much more sane language than JavaScript, IMO.
More can find more information on the official page here: https://www.dartlang.org/ (tools, documentation, sample code, tutorials), and there is also nice introductory video on the YouTube: http://www.youtube.com/watch?v=FqsU3TbUw_s.
As well as applets you have Adobe Flash, Microsoft Silverlight, shortly Chrome NACL. None of these interact with the HTML DOM as seamlessly as JavaScript though.
One thing you can do is simply have the server-side code do all of the processing. You limit yourself to having only CSS available for interactivity, but you can still do just about everything by loading a new page.
If you're considering java applets, then I guess it's necessary to mention Flash and Silverlight (*).
Of course, there are "interactive" web applications that don't use javascript... they use postback. But I don't think this is what you mean.
If you want to target just Internet Explorer, you can use VBScript (Microsoft's proprietary javascript) or even ActiveX. But I doubt that's what you mean, too.
So the onus is on you to answer — why not javascript?
(*) I guess.
I'd be very interested to know what your reasons are for not wanting to use Javascript? The answer to that question will make a big difference to how your question should be answered.
The Javascript language is actually quite powerful. Yes, it does have some quirks, but so do all other languages. A lot of the perceived "problems" with Javascript development in the browser are actually people having issues with the DOM rather than Javascript itself. The DOM, on the other hand is where a lot of the shortcomings and the cross browser issues crop up.
If this is where your problems lie, then you may be better off using a Javascript library such as JQuery, which abstracts away a lot of the direct access to the DOM, and resolves a lot of the cross-browser issues.
If you're using the latest browsers, a lot of the simple effects that previously required Javascript can now be done using CSS. drop-down menus, tabsets, fading, rotation and transition effects. All of this can be done with CSS. However most of them are quite new, and not available in all browsers currently in common use, so you would be better off sticking to Javascript for at least some of them for the time being. Even when they are ready for mainstream use, you'll still need some Javascript to hook them all together.
If you do really have a burning desire to develop using a language other than Javascript, then as you already pointed out, there are other options for programming on the web, such as Java applets. There's also ActiveX controls, Flash and Silverlight, and a few others. However none of them are universally available to all users in the way that Javascript is.
All of them require browser plug-ins of one sort or another, and all of them have issues with users who don't want to install them or corporate environments that don't allow them to be installed. In the case of technologies like ActiveX, they may only be available on certain browsers and operating systems, and (again like ActiveX) they often have security issues.
The only real reason that most of these other technologies existed in the first place was to fill a gap in the capabilities of the browsers at the time. All of these capability issues have now been resolved -- with HTML5 and related technologies driven by Javascript, Flash and Silverlight have been rendered obsolete; ActiveX controls were considered obsolete long ago; and when was the last time you saw a Java applet in mainstream use?
The bottom line is that the browser world is moving very rapidly away from any client-side code other than Javascript, and there are very good reasons for that.
Use pyjamas (google it), you can write normal python code and have it compiled as javascript so you get the best of both worlds, the power and expressiveness of python and the ubiquity of javascript.
Also keep an eye on the Falcon project by Adobe, it's an experimental compiler which translates actionscript 3 (a very powerful language compared to plain javascript) and the flex framework to javascript.
You can also try GWT by Google, where java is used as the client side building code (and yes, it also gets compiled to native javascript).
If it runs on the client's computer and can modify the DOM, it can work. JavaScript is the most widely supported so it'll work out-of-the-box for many people.
Basically, anything which functions like JavaScript can replace it.
Flash can perform basically everything that JavaScript can (graphically, but it can't modify the DOM), but if the user doesn't have Flash Player installed, you're out of luck.
Java can also work, but the same concept applies: if the user doesn't have JRE (or a similar machine)
Silverlight is similar to Flash, but much less supported (I can barely get it to work on my Linux box)
Just curious: why are you looking to replace JavaScript with something else?
This may seem inane, but I actually like using jQuery much better than JavaScript. It makes event handling and Ajax very simple.
I've been researching writing an app for iPhone. I really like the look of PhoneGap which basically allows you to contain a webpage in an app. My skills are primarially in HTML/Javascript so this tool allows me to make the most of my skills without having to spend many hours learning how to write an app natively for the iPhone.
I've been doing some tests on my iPhone for Javascript, and some seemingly simple examples run painfully slow. Really slow. This unfortunatly is a big problem for my task!
Any work arounds? If I want to do anything interesting am I going to have to write a 'proper' app?
An explanation on why Apple have seemingly created such a bad implementation of Javascript would be interesting as well (possibly to make more money? Less web apps = more apps in the store?)
References
http://ajaxian.com/archives/ipad-javascript-shockingly-slow
Javascript is not particularly slow, but the DOM is very slow.
I think it is the same as a desktop browser, but magnified.
I would check first all DOM manipulations, if they can't be optimized.
Another option, is to use a templating engine.The main DOM manipulations are done through innerHTML injection, which is fast even on mobiles.
We've built a mobile version of our web app, and we use PURE (an open source JS lib we created) to render the HTML from JSON data, and it is very responsive.
We went the HTML5 way(not native) but I think generating the HTML could be done the same way when wrapped in PhoneGap.
I don't think Apple has created any special implementation of Javascript for Mobile Safari. Probably it's the same as or very similar to the desktop Safari.
These devices are small and have strict power constraints, so the CPU is slow.
Apparently iOS won't do JIT compilation of JavaScript (unlike Android) due to a security feature: http://daringfireball.net/linked/2010/07/22/android-ios-js-benchmarks
Good point about DOM access being the issue though: I don't know how much these benchmarks test DOM operations.
#Rudiger: Just a thought - A lot of the improvements to desktop computer speed since "8 years ago" have been attained in part through the use of multiple processors. Javascript is single-threaded, and so presumably would not be able to take advantage of such multiple processors. Yes, I know that browsers can take advantage of it, and that putting the other stuff on the other processors can provide more CPU power to the Javascript thread, but I have an app that is mostly raw Javscript internal processing, where the main thing that is going on is search and array manipulation.
So, when comparing desktop power to mobile processor power, for my purposes, maybe the slowdown would not be so bad? I currently run at very acceptable speeds on Safari on a six-year-old notebook computer with a single processor. So I'm thinking that Safari on iPhone or iPad for me might not be that much worse. Do you think this is reasonable?
Actually, I think Apple has a vested interest in keeping javascript out of the Iphone as much as possible.. they seem to want to regulate things through their appstore by requiring applications that run natively.. I'm curious if javascript is also slow on Android phones, (I've never used one before).. if its not then I think it is a bit strange that the Iphone would be slow with javascript, at any rate, they are already losing market share and will have to address the issue at some point I am sure, I think people are catching on to Apple's games and idiocy in trying to micromanage everything now that more legitimate alternatives are coming out in the mobile device space.
I've got a HTML/JS (YUI framework) photo-organizer that needs access to the local FS. Should I move HTML/JS to AIR, or bite the bullet and "port" it to Flex AIR?
I know what the marketing says, but I want the real answer -- what an I "giving up" by going HTML/JS AIR? I'd like to get some feedback from people with deep experience building HTML-based AIR apps.
I don't think you'll see many issues in using the HTML AIR mode, AIR uses the Webkit engine under the covers iirc, which can work well enough, and has most of the same native features of the Flash/Flex built applications. You'll also see most of the HTML5 features you'd find in Safari. I would say if you need animations that Flash will generally run better than Canvas at this point... There's plenty of examples of ExtJS and other frameworks running on AIR.
As to what you are giving up, I don't think you'd lose anything from an HTML to HTML/AIR standpoint. You could gain a lot of what you gain in having an application in general based in Flash over straight HTML. In flex specifically controls and other features can be more readily tweaked than standard HTML controls. The animation tools in Flash are much nicer. ActionScript doesn't line up to JS on a one to one basis, so there may be issues with code. Dealing with remote content/data is actually a little nicer imho in AS over XHR, though only when dealing with XML.
From an administrative standpoint, going to AIR with HTML from an already written application is probably the shortest path. If you REALLY needed to, you could convert later, and a lot of the underlying logic would be worked out. Time to market would be shorter with whatever is closest to what you are already using more often than not.
Not really, since FS access is available with the HTML/JS version. However, the other route does open up some more native support for application development -- Animation for example, richer controls etc which you will have to live without otherwise. You will greatly miss the debugger and the profiler as also the design view when you move to complex applications. Also, note that if you are worried about sharing your source you probably shouldn't use the HTML/JS way.