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.
Related
I was recommended these two languages as a good option for multiplayer web game development, but I don't know what are restrictions of these languages in terms of game development. I personally like JavaScript, but I'm not sure about client-server communication and security.
Game is going to be 2D turn based strategy.
Shortest answer: Flash.
Short answer: Flash is your best option at the moment, but it's entirely possible to make a good quality game with javascript, there's libraries out there that make the drawing part really easy.
Long answer: For action heavy games, such as a fast paced platformer or a fighting game, Flash is your best option. Flash is also the only option if you want to be able to sell your game to various portals, since they have not yet opened up the ability to license HTML5/Javascript games.
However, Javascript is a viable game development language. Angry Birds on Google+ (and in the chrome store) uses Javascript, and only uses Flash for audio. In fact, audio is currently the biggest challenge, and there's slowly more solutions to that as well. Combine that with stuff like socket.io and the emerging WebGL, and you've achieved parity with most Flash and Unity games.
That said, there are drawbacks to Javascript. Namely, it is much harder to protect the code from being stolen or hacked, and depending on various factors, you're cutting out a subset of users who might be running IE8 and below. There are solutions to these problems, and there is one major drawback of Flash (doesn't work on iOS), but generally, these should be pointed out.
if to be short, it's too hard to draw via javascript. So if you game deals with graphics or animation, it better to use actionscript. IMHO, actionscript is the best if you want to design browser game, javascript will be needed to deal with browser only (if that'll be needed).
UPD: take a look at Haxe. It's multi-platform language. You can target both flash and JS on Haxe.
I would recommend Flash, unless you care about the iOS audience. Having a socket running in your multiplayer game is extremely valuable, and easy to accomplish. Meanwhile, unless you want to demand a specific browser from your users, the never ending headache of browser/platform incompatibility, especially in something as javascript intensive as a multiplayer game, makes Flash the obvious choice. And of course, performing animations is what flash is best at. Achieving similar results in HTML is in many cases impossible, but in all cases MUCH more work.
Oh, and welcome to Stack! :)
Go javascript. But you should look at http://socket.io/ if you go the javascript route
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 need to implement a paint type program that will run on all major browsers as well as can be packaged as an app on the iPad/iPhone. After some investigation I have learned the following facts (correct me if any are wrong):
Javascript is entirely too slow to handle an app of this type by itself
HTML5 seems like a good solution, it has a canvas tag and everything and can easily be packaged into a UIWebView for a Cocoa app. However, I need to be able to reach the majority market for web users, which unfortunately includes most IE users who aren't using the public beta for IE 9.
Flash vs. Apple
Right now I'm debating just making two completely separate apps, one in OpenGL ES for iPad/iPhone and another in something like Flash for web browsers. I was just wondering if anyone had an immediate solutions in mind to make one app instead?
I'd question the accuracy of your first point (Javascript is too slow). Since it's possible to run Quake II in pure Javascript, it's likely that your paint application is less resource-intensive and thus could also run. Of course, one could ask how much optimisation effort and/or experience is required to write performant Javascript of this standard - I can't give you an answer there.
But I'm certainly sure that it's possible to get enough performance out of Javascript to implement such a paint tool, in any modern browser. That doesn't preclude the other options, though; using JS along with HTML 5 sounds like the ideal solution here for "out of the box" cross-platform compatibility.
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.