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.
3. Support and low-level functionality.
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!
