Suppose I'm writing a 2d tile based MMORPG.
Furthermore suppose I hate flash.
Lastly, suppose I only need my code to run in the latest safari, latest firefox, and latest chrome.
What are the limits to what I can and can't do? (Are there examples of good game engines that only require a recent web browser)?
Look into HTML5 Canvas http://en.wikipedia.org/wiki/Canvas_element
The latest versions of the browsers you mention already support it.
Check out the Unity3D engine: http://www.unity3d.com
Cross-browser, cross-platform, although your users would have to download the unity browser plugin...
There's also the Raphaël javascript library...it does a very nice job of abstracting a lot of the heavy lifting you'd have to do otherwise! The memory footprint seems decently light as well (from my small-scale playing around with it anyway).
For something that works for the user, OOBE (without add-ins etc); Javascript is probably the only unified functionality that exists between all browsers.
The browser is surprisingly quite capable (at least Chrome is), this is something that Google Chrome is attempting to promote (see http://www.chromeexperiments.com/). Notice some however, that experiments are often laggy or unworkable in other web browsers.
As for a list of things that are and aren't capable; that would take a fair while to compile.
In regards specifically to a 2D tile based game, I wouldn't say it isn't possible, but it may be quite difficult to create. As mentioned before, most browsers (apart from the stand-out; Google Chrome), suffer from limited resources. Therefore resources wise, it may be difficult to implement and would defiantly require a lot of requirement fore planning.
Java applets are also possible...
You could also move to 3D. While it does require a plug-in (although is being integrated into Chrome), the results are undeniable.
"O3D is an open-source web API for creating rich, interactive 3D applications in the browser." http://code.google.com/apis/o3d/. The video is quite amazing actually -- especially the live map editing (e.g. removing sprites).
Related
I am gonna develop a lesson in two platforms(firstly in webgl and then a similar lesson in unity 3d).
the aim of this research is to see the best of these platforms in terms of performance and speed to use it in e-learning environments.
my question is this :
how can i measure the performance (processor, memory, graphic card) for these platforms?
also, I am very appreciated if any one give me ideas or a suggestions to improve this research.
WebGL and Unity are not platforms. Unity is a library that has support for multiple platforms; its performance depends on what hardware its running on. WebGL is a JavaScript API for browsers that allow them to access OpenGL ES 2.0. This also isn't a platform; it is utterly dependent on the hardware it is running on.
Sure, each incurs overhead, but they also do completely different things. Even if one is seen as faster for a particular piece of hardware, that doesn't mean that you can use it. Unity makes applications. Something you download and install. WebGL is for web pages: HTML+JavaScript. The reasons to use one are not the same reasons you would have to use the other.
Making a "WebApp" is very different from making a regular application. You generally decide first off whether you want to make a WebApp or a regular application, then use the tools that are available to the one you pick.
There are platforms that don't support WebGL. Namely, Internet Explorer. Microsoft has already stated that they aren't going to implement WebGL. So WebGL's performance on IE is effectively 0.
Also, WebGL is a low-level rendering API; Unity is a game engine. Unity provides more functionality towards making a game than WebGL, so there are productivity differences you must take into account.
Your desire to compare the performance of these simply is not the most useful criteria for deciding which one to use.
OK, your later answer clued me in to the idea that you're focusing on browser-based tools.
WebGL is not available on Internet Explorer. So again, half of your customer base is gone. However, Unity's browser plug-in is a plug-in and therefore must be downloaded by the user. Quite a few users are against that. Also, Unity's browser plug-in doesn't work on mobile systems; you would be expected to write an app for those.
So which matters more to you: reaching out to mobile users (where WebGL is available), or reaching out to Internet Explorer users? Again, this is something you need to deal with long before you answer questions of performance.
I have been following the usage of JavaScript for the past few years, and with the release of extremely fast scripting engines (V8, SquirrelFish Extrene, TraceMonkey, etc.) the possibilities of JavaScript have increased dramatically. However, the usage share of Internet Explorer coupled with it's total lack of support for recent standards makes me want to drop a bomb on Microsoft's HQ, as it creates a huge amount of problems for any website.
The game will need to be pretty dynamic client-side, with animations and other eye-candy things, but not a full-blown game like those that run directly in the OS using DirectX or OpenGL. However, this might be a little stretch for JavaScript and will certainly feel extremely slow in Internet Explorer (given that the current IE engine can be hundreds of times slower than SFX; gotta see what IE9 will bring), would it be better to just do the whole thing in Flash? I know this means requiring the plug-in AND I have no experience whatsoever with Flash (other than browsing YouTube :P). It also means I can't just output directly from PHP, I would have to use XML or some other format to pass data to it (JSON is directly integrated in JS and PHP can deal with it easily).
Another idea would be to provide an alternative interface just for IE, though I don't know how (ActiveX maybe? or with Flash, then why not just provide it to all browsers) or totally not supporting it and requiring the use of other browsers, although this is plain stupid from a business perspective.
So here am I, wondering what approach to take and thus asking for your advice. How should I build the client-side? AJAX in all browsers, Flash in all browsers or a mix (AJAX for "modern" browsers and something else for the "grandpa": IE).
I recommend a plug-in platform (Flash, Silverlight, or Java) over AJAX. Having a clean layer of abstraction between your game and the client's browser is a big advantage. In any non-trivial AJAX game look forward to endless corner-cases where browsers differ in performance or implementation.
Personally, I think Flash is easy to learn if you are coming from AJAX experience. Flash is currently the most widely installed and proven plug-in for browser games. However, Silverlight and Java are both building momentum. Also, the Unity engine has become a popular choice for commercial browser games.
I think you shouldn't leave Java out of the equation. It's a powerful, fast language, and with Java applets, you can do almost anything. If you want hardware-accelerated graphics via OpenGL, JOGL can do it, even in an applet.
On the other hand, it might not be right for you. But at this early stage, I think you should evaluate all of your options, and since you have no experience with Flash but sound like you've got a bit of programming experience, you might feel more at-home with Java.
I believe the current answer is Flash game.
Alternatives:
Java Applet: getting less and less common those days and it is not commonly installed as a plugin on many computers.
SilverLight: too new and might vary and change in time. not commonly installed on many computers and it's Microsoft (whom tends to change technology every 2 years ...)
JavaScript / AJAX: Still a new kid on the block, it's on the rise it is true with many nice features, but still lack of good cross browser for IE even IE8, can not play sounds internally, still slower than the others, and you don't know where will it evolves.
Eventually probably the best solution for now is Flash development:
Cross platform. Works fast. Long time already alive and have a lot of support.
I hope this answer will change in the next year. Happy Peasach.
Check out Jmonkey. The "plugin" loads if you have Java on your machine. Once it's cached, the next time the visitor goes to the page, it your game loads very quick. Check out their website for demos and see what I mean: http://www.jmonkeyengine.com/
Oh, I forgot to say, it's a 3D scenegraph Java engine. I just tried it again, and it loaded in linux. Looks they've put in some good work.
Don't do it with javascript in the browser. And Flash really can be a pain just because it's closed source and you don't know if you've made a mistake or found a bug - speaking from experience. I'd never want to make another Flash game again.
How about using RaphaelJs , it is a Javascript library that make dinamyc images using SVG, and for IE, it try to make those images using the IE alternative: VML. Im using it on my own WebGame, but i dont really make complex graphics in it. The most complex thing done on RapahelJs was a heath map (20 * 20 tiles ) with a dinamyc opacity slider. An it work with jquery without any problem or configuration!
When designing and building the UI for an application that uses AJAX, when do you consider graceful degradation (for users who have JavaScript disabled, or are using a screen reader)?
At the end, once the AJAX version of the site is completely finished
At every stage of development
I don't
Something else...
These days, progressive enhancement is generally preferred over graceful degradation - i.e. the exact opposite approach.
The method I'm employing so far is to write it so it works without JavaScript and then add the JavaScript on top.
It's really the reverse of graceful degradation. It's an emphasis on enhancing the page as your browser and settings allow.
Relevant article
Graceful degradation can describe two things:
It is a behaviour (normally a website or web application) that allows the site to continue functioning when certain features are disabled (e.g., JavaScript; CSS).
It is an approach that builds the application to work with bells and whistles turned on, and then afterwards fixes are bolted on to make it work without said noisemakers.
I assume you are asking whether or not to use the latter to achieve the former. I'd definitely suggest achieving 1), as anyone who browses with JavaScript off (i.e., lots of people with a computing clue; those using text-based browsers; those using disability aids) will otherwise not be able to use your site.
As for how to do it, A List Apart have a great article on progressive enhancement which is worth looking at, where you build the site to work basically first, and then you add the AJAX, etc. afterwards. I prefer this approach because it gives the app a solid foundation to work on, with decent security and functionality from the word go. Future enhancements to it can be made at the basic level and then added into the AJAX layer; without the former, it's harder to add in gracefully degrading components to the application in the future.
Anyway, enjoy the article and if you want to know more about this stuff generally, A List Apart is a great site!
Jeremy Keith sums up the argument for progressive enhancement with his Hijax article.
Typically, I use the following code to dynamically apply a class of "js" to the HTML element to target JavaScript-enabled browsers
<script type="text/javascript">if(h=document.documentElement)h.className+=" js"</script>
We provide a web application with a frontend completely developed in Adobe Flash. When we chose Flash 6 years ago, we did so for its large number of features for user interaction, like dragging stuff, opening and closing menus, tree navigation elements, popup dialogs etc.
Today it's obvious that AJAX/JS offers roughly the same possibilities and because of the number of frameworks that are readily available, it's very feasible to implement them.
Is there a technical reason one should choose either technology over the other? By "technical", I mean performance, security, portability/compatibility and the like. I don't mean aspects such as the very non-programmer way development is done in Flash or whether it makes sense to switch an app from one to the other.
As I just explained in another question, it seems to me that JS is way ahead in terms of market share and I'm wondering whether we are missing some important point if we stick to Flash.
In addition to what others have said, Flash is constrained in the "rectangle" and cannot be added to a normal html page in an un-obtrusive manner.
#Gulzar I think when more browsers will support the video tag like mozilla 3.1 does we'll see even more adoption of ajax/js over flash.
Adobe Actionscript is a statically typed language, Javascript is dynamically typed. Depending on your point of view, this may be a good thing or a bad thing.
With Javascript/HTML/CSS you're going to be heading into cross-browser compatibility hell, especially if you want to support older browsers. This can be mitigated by the libraries that are available, but it's still a big headache. With Flash, you write the code once and it just works in all browsers.
Even with the libraries available, Flash user controls are simply more advanced than anything you can find in the world of Javascript/HTML. In Javascript, you are not going to find anything that comes close to the simplicity and power of a databound user control that Flash provides.
I don't see how Javascript has more of a "market share" than Flash. Pretty much anyone with a web browser has a Flash plugin installed. I'd be curious to know how many people disable Javascript but have a Flash plugin.
Also keep in mind that you're going to be in for a huge learning curve and lots of development time if you decide to switch your technology base so you'd really better have a good business reason to do it.
This decision also has a lot to do with what your application does and who your install base is.
Edit: I see people have mentioned that the iPhone doesn't have Flash support. I would expect this to change with the install base of the iPhone - Adobe would be crazy not to support it.
Correctly designed AJAX apps are more googleable than Flash
Correctly designed AJAX apps are more easily deep linkable than Flash
AJAX doesn't require a plugin (Flash is pretty ubiquitous, so it's not really a big deal)*
AJAX isn't controlled by a single company the way Flash is
Edited to add:
* Except for the iPhone, as Abdu points out.
JS and Flash both have great presence on the web with overlapping capabilities. One area JS is still lacking is in rendering video.
Flash, used well, allows easy localization and internationalization.
Furthermore, it is much easier to use Flash in an accessible manner; you can feed screen readers the right text, instead of having them iterate over all of the possible form elements.
I think Flash should be limited to online games, videos and animation. Otherwise use html and Ajax. It's a web standard and supported by almost all devices.
AFAIK, the iPhone doesn't support Flash. That's a fast growing segment you're blocking out already. Keep it simple and efficient.
Although flash is pretty ubiquitous on desktop browsers, mobile support is very limited (flash lite? yeah, right). I get really frustrated looking up a restaurant on my phone only to find the entire site is flash based and I can't even get a phone number or address!
One benefit of Flash is that it has a few facilities to help do cross domain type operations safely, which can be helpful. Flash also has (limited) support for some hardware, which is not possible with Javascript.
Personally, I'd try to use as much Ajax as possible before turning to something like Flash. From the UI perspective, it is better in that the controls and basic authoring is a little more developed. The Sound Manager project is a good example of effectively using a small amount of Flash while keeping the remainder in Javascript.
I suspect one of the reasons javascript is becoming more popular is that it's more easy to retrofit into an existing application.
As I can't accept two answers, I'm going to merge Christ Upchurch's and 17 of 26's answers in my own post. I think, these two together pretty much sum up what I wanted to know. Thanks guys!
If you're dealing a lot with polygons, then Flash is still easier to program and debug. With AJAX there are a lot of libraries to handle polygons, but the more libraries your app uses, the slower it gets.
Jeff mentioned the concept of 'Progressive Enhancement' when talking about using JQuery to write stackoverflow.
After a quick Google, I found a couple of high-level discussions about it.
Can anyone recommend a good place to start as a programmer.
Specifically, I have been writing web apps in PHP and would like to use YUI to improve the pages I am writing, but a lot of them seem very JavaScript based, with most of the donkey work being done using JavaScript. To me, that seems a bit overkill, since viewing the site without Javascript will probably break most of it.
Anyone have some good places to start using this idea, I don't really care about the language.
Ideally, I would like to see how you start creating the static HTML first, and then adding the YUI (or whatever Ajax framework) to it so that you get the benefits of a richer client?
As you've said
To me, that seems a bit overkill, since viewing the site without Javascript will probably break most of it.
This isn't progressive enhancement. Progressive enhancement is when the site works perfectly without JavaScript or CSS, and then adding (layering) these extra technologies/code to increase the usability and functionality of the website.
The best example I can give is the tag input box on this website. With JavaScript turned off, it would still work allowing you to enter tags separated with a space. With JavaScript turned on, you get a drop down with suggestions of previous entries.
This is progressive enhancement.
See also Unobtrusive JavaScript which is the bedrock progressive enhancement is built.
Going at it from the other direction is sometimes referred to as graceful degradation. This is usually needed when the site is built first with the enhanced functionality afforded by the various technologies then modified to degrade gracefully for browsers with those technologies are not available.
It is also graceful degradation when designing to work with older browsers (ancient in the Internets terminology) such as IE 5.5, Netscape, etc...
In my opinion it is much more work to gracefully degrade the application. Progressively enhancing it tends to be much more efficient; however, sometimes the need to take an existing app and make it accessible in these lacking environments arise.
Basically, if your site still works with JavaScript turned off, then anything you add with JavaScript can be considered progressive enhancement.
Some people may think that this is unnecessary, but plenty of people browse with addons like NoScript (or, with JavaScript simply turned off in their browser settings). In addition, many Mobile web browsers may or may not support JavaScript. So, it's always a good idea to test your site completely with and without JavaScript.
Progressive Enhancement is a development technique that stresses the primacy of the semantic HTML, then testing for browser-capability and conditionally "layering" on JavaScript and/or CSS enhancements for the browsers that can utilize those enhancements.
One of the keys is understanding that we're testing for what the browser can do, as opposed to browser-sniffing. Modernizr is a very popular browser-capability test suite.
Progressive-Enhancement is inherently (section 508) accessible; it provides for meeting the letter of the law and the spirit of the rule.
The Filament Group wrote the excellent "Designing With Progressive Enhancement" book on the subject. (I am not affiliated with Filament Group, though they are so freaking smart I wish I were.)
This is such an important concept and it saddens me that so few web developers understand it.
Basically, start by building a site/framework in Plain Old HTML -- structural elements, links and forms. Then add on some style and then shiny stuff (Ajax or what have you).
It's not very difficult. Like palehorse says, graceful degradation is more work.
Websites should work in any user agent, not look the same (not even look but sound if your vision impaired), just work.
Progressive Enhancement:
The plain HTML/CSS site is awesome (fully working and user-friendly).
Adding JavaScript defines a new level of awesome.