The choice of technology for developing browser games
Task Description
In connection with the current situation with the support (or rather lack thereof) of Flash technology on iOS, I was asked to check the possibility of implementing games with rich graphics on “clean” browser technologies. Honestly, Flash is far from my favorite platform (since it is a closed Adobe product, not open source), which only added to my motivation to show that good results are possible without it ...
However, despite personal preferences, Flash provides not only a single execution environment (runtime), which is equally implemented on many platforms, but also a rich development environment that cannot be completely replaced today.
As a result, the review of technologies looked like a search for compromises between the ability to support the final product on a mass of platforms and the convenience of software development.
The list of browser platforms we need to support:
- Explorer 9+
- Firefox 3.6+
- Opera
- Chrome
- Safari
- iOS MobileSafari
- Android Browser on WebKit
')
Also, you need to create a convenient process of interaction with the designer.
Today, in my opinion, there are no adequate alternatives to the Flash design environment, which allows you to script animation, contain an object model (“ Scene Graph ”), as well as integrate freely with Adobe Illustrator and other design tools.
As soon as we leave the trodden path of a commercial vendor, the responsibility for determining the methods for transferring graphics from the designer to the frontend programmer falls on us.
The search begins
SVG was initially tested as a high-level graphical language. It has the following advantages:
- Relatively high level of abstraction - has its own object model, which allows you to handle events.
- Supports complex animation elements, such as movement of an object along a path , morphing forms, declarative animation
- all the advantages of vector format
- the object model of the format itself somewhat replaces the need for a scene object model — Scene Graph.
- SVG is a common format, easily exported and read by various graphical applications.
With such a list of benefits, one would think that the technology is just perfect. However, when testing the following disadvantages appeared:
- The level of implementation and support of a complex standard is very different between browsers and platforms.
- On some platforms, the implementation is very slow.
- The SVG object model (DOM) is overly complex and difficult to work with scenes in which you need to dynamically add and remove objects.
As a result, it was decided to try the approach at a lower level, using the Canvas with the Processing.JS abstraction library to facilitate the work. Benefits:
- Canvas is a simple standard, and as a result is universally supported on modern browsers.
- Processing provides an additional level of abstraction, which makes it possible, for example, to import SVG.
- Canvas gives pixel control of the canvas.
The implementation of the first test scene in Canvas / Processing showed that many of the basic functions of SVG are missing, and they had to be added by hand. For example:
- trajectory movement
- object response to mouse actions
- morphing forms, being difficult to implement algorithmically, was translated to the equivalent of sprite animation, and step-by-step animation itself was implemented in Inkscape editor.
You can certainly close your eyes to all these shortcomings, if as a result we can get a real cross-platform solution for writing browser games. To test this, it was decided to build a new demo, closer to the real game . Unfortunately, it immediately showed that the MobileSafari (iOS) Canvas simply does not pull and runs with a very low framerate.
Attempts were made to optimize the demo (the frame-by-frame background redrawing was canceled, the number of objects on the screen was reduced, the texture of objects was canceled). But the result still remained unsatisfactory.
Decision
By this time, having unsuccessfully spent a significant amount of time on achieving a very clear and definite goal, I was forced to think about a different approach. After all, the weak link in this chain is iOS, as well as all slow mobile platforms that have limited browser choices.
On these devices, fast graphics is feasible only when using native graphics acceleration. And in MobileSafari, this is just the HTML object model (DOM).
It was this thought that led to the fact that the Black Jack demo of the table was redone , this time using HTML and CSS3. The sound and some transparency effects were also added ... and it worked! Immediately after the transition, the framerate on MobileSafari improved.
After additional reading and specialized optimizations , the speed was raised even higher. It turns out that in iOS 4.x MobileSafari is only partially accelerated, and you must carefully choose the method of accessing the DOM in order to get the most out of this browser.
Personally, I was surprised at the possibility of implementing a browser game with rich graphics using only CSS transformations and HTML. Being embraced by the search for “silver bullet” in the form of advanced technology, I almost missed the “bread and salt” of web programming until I tried and set aside all other possibilities.
I don’t want to say that Canvas and SVG do not have their place. But with the aforementioned goals, SVG is no longer suitable for static complex diagrams, and Canvas does not pull on Apple devices of this generation. Only one thing remains: CSS3.
The choice of this technology, dictated by a common denominator of platforms, forced us to debug our process of processing and assembling graphics from the designer’s sources into a solid format. But more about that another time ..
Source Code References
All code examples in this text can be downloaded and viewed from the writer's GitHub account:
Source: https://habr.com/ru/post/118308/
All Articles