CSS transforms are neat and powerful effects engine in HTML. Besides of HTML it could be used for SVG graphics on same page.
And what has been only web page with SVG became serious gaming platform.
For JS developer it would be straight to implement most of gameplay and scene control using JS+canvas leaving some effects to CSS.
But when a kid asked me to help with building the game, functional/aspect programming appeared to be easier. It is quite simple to explain that by adding class name to character's dom node its appearance and behavior changed accordingly.
To add little attraction to this approach, CSS-driven effects are way more efficient than same with JS. Less CPU, easier development.
Not to mention more reliable code: no memory leaks, JS closures, etc.
Obviously CSS is not much designed to change the DOM, hence the gameplay could not be completely covered by this approach (see disclaimer on active CSS)
So what are the layers and what benefits to chose technology for each?
1. DOM as model
For simple arcade the visual and business object model have a 1:1 match. In this case there is no need to separate game and UI objects. Implemented as DOM subtree character or scene will be able to preserve and manipulate own data utilizing as JS as native browser capabilities.
- Having screen coordinates matching the game scene will fuse native rendering, motion and colorspace/transparency/fog/shadow effects supported by browser.
- Zoom could be applied by changing the default font size and
defining the model in em
units. To make it even more attractive, the focus subscene or
object could have dynamic font-size allowing to zoon-in or grow the
character without affecting other model parts. Achievable by class
name.
- DOM subtree as scene component/character. It is hard to enumerate what adwantages could be gained. Some of them:
- Design and develop as independent module (HTML, CSS,
transformations, behavior). From HTML space SVG for vector
graphics, GIF animation(see disclaimer), etc.
- Event-driven interaction. Native declaration and handling.
Native events( mouse, swipe,etc) support along with no model
parameters conversion( this is reference to node which is same as
in UI as in model, model coordinates == screen coordinates). Event
propagation interface and handling.
- Ow, forgot about tons of docs and help on HTML and CSS.
2. Behavior definition.
Primarily defines reaction of the system and its parts on various
kinds of events. Literally event-driven engine.
There are multiple implementations I could think of. At the moment
could not make any preference.
- JS. By picking the library with artificial + native event support
and transform/effect most of the needs are covered. Other features
are depend of project complexity and personal view. Such things as
modularity, compilation, documentation, etc. really could be
skipped.
JS itself is not oriented for the task and only libraries could give enough abstraction for event-driven behavior definition. - Event definition and transformations chaining is native part of SVG.
While the language is not perfect itself, it gives native (read most
efficient) support and prevents such mistakes as hanging event
chain(when broken in the middle of execution), memory leaks, object
and timing conflicts. Need to check cross-browser capabilities.
Many app sides like saving to database, communication with server(s) belong to "support" or "service" layer. So far I see only 1 choice: JS. Better with sufficient featureset library. DTK for example.
The game is not only about visual interaction but also about sound. Not just background music but rather interactive and event-driven. While HTML5 has support for such, it is possible to utilize multiple sound player widgets with events and sound level control.
Unlike visual the sound sources count need to be more limited to avoid unrecognizable mash-up. The proper join of sound source with associated scene component(s) and ability to switch the vocal focus requires separate implementation of sound players stack and visual game model.
Voice or/and video communication creates another dimension for gameplay. Those have own set of requirements and definitely should be dedicated in own layer. Quite often dominating for resources consumption. This part is not necessary need to be embedded into game scene. For resources distribution reasons it worth to keep it even in separate frame or even window. Multiple monitors are not exception novadays.
Disclaimer.
Active CSS assumes to associate behavioral patterns with class names. Some browsers have sufficient support for such( lovely HTC, or poor Mozilla ones), but there is no good unified native cross-browser solution.
This gap has been closed by jQuery.live approach on JS level, but in this case we have poor JS performance. Being purist on my own, I do not see the benefit for gameplay logic completely covered by CSS class names manipulation.
3D rendering and stereo. Unfortunately it is somewhere in the future for cross-browser development. But if you have in mind customized WebKit(?) environment, than many principles of this article could be applied now.
GIF animation. While it seems familiar and simple solution, it is quite inefficient in terms of control and resources. On one side it is raster graphics and needs pre-scale(saved in larger than usual use dimensions) to support acceptable quality. On another side consolidation of GIFs into single tiles file seems to be heavy for resources and should have synch animation effect. Never tried thought :) Alternatives with SVG transform- or CSS-transform driven animations given way more control and flexibility along with smaller memory and CPU footprint. Forgot to mention "skinning" of characters which is difficult to achieve in GIF and so easy by SVG. Skinning is applying for same element coloring by team, incremental details upgrade, etc. The goal should be skinning control by the node class name changing as most memory(same node and image) and CPU(native transformations) saving .
Happy coding!
No comments:
Post a Comment