Game Development Reference
In-Depth Information
professionals from Zynga, Facebook, SixToStart, and many other companies serving as judges. My team's
project, FAR7, won the Best Technology category. As the CTO, I would like to discuss the crucial and
most complicated stage of development, which is choosing the technology.
Why the choice is so hard to make
Being game developers, we must squeeze everything we can out of the possibilities offered by web
browsers and find workarounds for the limitations that still exist. The limitations of browser capabilities
warrant comparisons of browser game developers' current situation with that of game developers from the
'80s, who were fighting for every bit of data and FPS while making simple (yet not a tiny bit less exciting)
games for a budding market. Just as it was back then, we now have to worry about buffering and extra
screen refresh; optimized sprites and stored data for the best performance; packing files for fast download;
and much more.
The rapid progress of technology and a new round of the browser wars further complicate choosing the
right technology (with HTML being one notable example).A great number of new technologies have been
introduced in the span of a mere two years. Many of these have similar functionality, and it is sometimes
extremely difficult to make the right choice. For instance, it is simply impossible to choose between canvas
and SVG, or WebSockets and Server-Sent Events, without researching and studying their respective
backgrounds.
Before we start developing, we must identify our target market, clearly define the game genre, and assess
available resources. By the way, the latter is critical for indie games and start-ups, which often do not even
live to see the first prototype solely because the developers fail to choose technologies with optimum labor
intensity. As for the genre, it can pose stringent requirements to an engine part. FPS games call for short
ping times, whereas an RPG may require a large cache.
Until a standard game development stack takes shape, each developer must make his own choice,
combining what he sees as essential technologies to build his own game engine. It is this choice that will
determine how successful the engine is; which, in turn, will affect the success and popularity of the game.
No market player knows for sure the right way to make games, but it is apparent to everyone these
technologies have a great future. This is the motivation behind frequent developer conferences, the most
notable of these being hackathons held by the Facebook crew, featuring speeches by organizers and guests
from well-known companies, such as Zynga, Three Rings, and other HTML5 game development pioneers.
One of these hackathons saw the making of an application named JSGameBench (
https://github.com/
facebook/jsgamebench
), de
signed to analyze the performance of various technologies in different browsers.
JSGameBench is continuously updated, and I strongly recommend that you use the tool to study the current
state of the market. Even as you read this topic, new browser versions may well be coming out, and the
drafts of many standards may be updated.
In this chapter, I will try to describe each element of the stack (audio and video, rendering, client
databases, and connection) and to provide a couple of useful tips on architecture and styling. In each
particular case, we will look at differences in implementation in each browser and discuss fallback options
for legacy browsers that lack support for advanced technology.
