HTML and CSS Reference
In-Depth Information
There are many hundreds of operating system and device combinations. Even with extensive quality assurance
(QA) testing it is difficult to ensure that any multiplatform game will be 100 percent. With the price point of tablets
tumbling, so are the specifications. Rather than the memory problems with mobile web-enabled devices easing over
time, they are becoming more acute, necessitating stricter controls.
In Funfair Freak-Out every effort was made to ensure that the assets would be as small as possible. All the
animation cycles were minimized. With the character animations, walk cycles were kept down to 10 or 12 cells on the
sprite sheet. This maintained enough frames in a second to feel natural without becoming clunky. The simple color
palette of the Scooby-Doo animation allowed for the use of the PNG8 format, 8 bit color with indexed transparency.
This can typically be less than a third the size of PNG24. For those images that didn't need transparency, the JPEG
format was used to great effect.
Two asset sets were made available to the game: high definition (HD) and standard definition (SD). The HD
clocked in at 6.75MB, and the SD, at 3.75MB. The appropriate set was delivered, based on screen size and resolution.
All unnecessary transitions (particularly those that added weight) were removed from the game. From screen
to screen, elements were reused in differing combinations within each zone. On very few occasions were assets only
used once.
For the audio, everything was reduced to mono and 80Kbps ( MP3 and OGG ). This still sounded great, and the total
weight for the MP3 assets was 886KB, with OGG at 777KB.
Certainly, with HTML5 I have come to the conclusion that pushing the boundaries in terms of memory or
processor usage should be avoided when trying to reach the greatest audience. There are many other areas in which
to experiment, innovate, and deliver quality.
A further issue that is more user-focused relates to data charges when not connected to Wi-Fi. No user wants
to discover a massive bill from his or her service provider. Typically, mobile web games are snackable and casual by
nature. This is good; it means that the graphical assets can be scaled back. With projects that I am involved in, we set
a 5MB budget and afford ourselves a little leeway. Anything above 10MB is regarded as the “danger zone.” and we
definitely don't want to go anywhere near there.
Interface Design
As device operating systems are upgraded, and updates are applied to browsers, the implicit rules for interface design
are changing, and we, as game developers, are continually being required to adapt (we're mainly talking smartphones
here). Simplicity and consistency of experience are key, certainly in relation to button placement, input types, and
user journeys. With all web games it is important to lead the player to game play as quickly and as obviously as
possible. I'm a great believer in the value of a big button on the landing page that says, “Play.”
With Funfair Freak-Out the character and level selection pages were designed to be “swipeable” via finger or
mouse. Supplementary buttons give a choice to those who would rather click or tap through the options. The dual
method tested very well with users.
With the browser Google Chrome potentially interfering with play in many games, it is important to design
around possible problems. Interface buttons in the bottom corners of a screen will likely interfere with the back and
full-screen buttons on iOS devices; too close to the top of the screen, and Chrome could be initiated. These are painful
problems that require large exclusion zones around the edge of the screen.
It has been noted in user testing with young children that they will place a device on a table and then lean
on the device. Frequently, this will cause the corner of the touch screen to be nudged and input to the device,
generated. Ideally, the exclusion zone will deal with the problem areas, but when we are talking about a smartphone,
the available real estate is very slight. Heed must be paid to the areas with issues, while hoping that the browser
manufacturers don't do further updates to render your expertly crafted interface a relic.
Search WWH ::

Custom Search