|
According to the Entertainment Software Association (ESA),
"sixty-seven percent of American heads of households play computer
and video games," with the average age of game players in the
United States set at thirty-three years old.
(http://www.theesa.com/facts/top_10_facts.php)
Moreover, total game sales in the United States reached $7.4
billion dollars in 2006.
(http://www.theesa.com/facts/sales_genre_data.php)
Can there be any doubt that video games are one of the most popular
ways that Americans entertain themselves these days? And, with all these
people playing games, it shouldn't come as a surprise to learn
that more and more people want to step out of the role of game
player and into the developer's seat.
Video game design and development is a huge
topic. In a modern, large-scale video game produced for the
major consoles (Nintendo Wii, Sony PS3, and Microsoft XBOX 360),
hundreds of people work for years burning through budgets of
millions of dollars just to produce a single title. The
roles range from programmers to graphic designers to
audio developers to countless business-related roles. With so
much to be done, it can seem a little overwhelming and intimidating
to even think about getting involved. But, the video game
market is vastly wide — with all those gamers, there
are many opportunities to produce a game that will appeal to
someone.
In this article, we're going to take a look at one
of the game development techniques that's often overlooked by
mainstream game developers. We'll see some of the drawbacks, but
we'll also talk about some of the benefits of this method. In the
end, I hope you'll have a good overview of the pros and cons of
creating video games using DHTML technologies.
Before going into too much detail, let's take a
moment to define DHTML. Dynamic Hyper Text Markup Language (DHTML)
refers to the use of a group of individual technologies to achieve
certain results on the web. Most commonly, DHTML simply means
a combination of HTML, JavaScript, and CSS with a heavy emphasis
on the Document Object Model (DOM). Instruction in any one
of these technologies goes far beyond the scope of this article.
In fact, if you're interested in making DHTML-based video games,
but you're not already proficient in working with the tools that
are needed, I'd suggest first glancing through the rest of this article
to make sure that DHTML would allow you to do what it is that
you actually want to do. Then, consider purchasing one or more of
the books to the right to start getting up-to-speed on the components
that make up DHTML. At that point, you'll be ready to start
making your first game!
Even for those who already know how to work with DHTML
but are new to game creation, the primary question people seem to
ask is, "Why use DHTML to make video games? Wouldn't X be much
better?" (where "X" is any one of a number of competing
technologies) In my opinion, there are some great reasons to try
to make a web-based game in DHTML . . . there are also some huge pitfalls
that make it absolutely not right for many types of games. The
remainder of this article will focus on comparing the benefits to the
drawbacks to help you decide for yourself whether DHTML might be
right for your project.
The Advantages
Before we get to all of the reasons that DHTML may not be a very
good choice, let's at least give it a fair shot by listing some
of its advantages. And, since there may be some seasoned game
developers out there questioning why anyone would want to make a
web-based game at all, let's just assume, for the sake of this
article, that we all at least agree that there is a place for
web-based games in the overall gaming landscape. (If you really
need convincing, consider that the ESA reports that 10% of all
U.S. gamers say that the one type of online game they play most
often are "Shockwave/Flash/Browser-Based Mini Games."
http://www.theesa.com/facts/sales_genre_data.php)
- Audience - Not only is there a
group of people out there looking for web-based games in general,
but there are some reasons that a DHTML game is particularly
audience-friendly. For one thing, a DHTML game doesn't require
your audience to install browser plugins to play your game.
Also, a game created with DHTML may be able to be played more
easily by people on slower Internet connections, because your
game's overall download size will probably be much smaller than
it would be if it were created in technologies like
Adobe Flash or a Java applet.
- Developer Learning Curve - While labeling
one set of tools or a particular programming language
"easier" or "harder" than others can be contentious, I think
that it's safe to say that, based on certain criteria, the
technologies that make up DHTML could be thought of as easier
to learn than some competing technologies. For example, most
people who are new to programming would arguably have an easier
time learning the DHTML techniques required to make a video game
than they would learning the comparable Java to write the same
game as an applet.
- Development Tools - Let's say that at a
bare minimum, your game requires graphic design and programming.
(Yes, sound would be nice too, but many web-based games do
not use audio.) Every major operating system probably comes,
by default, with tools that can be used to write perfectly
valid HTML, JavaScript, and CSS. And, if not, there are countless
free options to be downloaded online just for this purpose.
Likewise, even if you don't already have any graphic design
tools at your disposal, software like
The Gimp and
Inkscape
can be downloaded and used completely free of charge. In other
words, there is no monetary cost that's absolutely required
for you to start making your DHTML games — assuming you
already have a computer.
In short, DHTML games excel where your audience's
bandwidth and plugins are in question; you're either completely
new to programming of any sort or you're already proficient in DHTML's
components but not other technologies that you could use to make a
web-based game; or you don't already have the tools required to
make a game in a competing technology and you don't have the budget
(or simply don't want to spend the money) required to get started
with other tools.
The Disadvantages
The disadvantages to making a game in DHTML are best seen in light
of competing technologies. The competitors all have to be able
to create games of a basically similar nature to what's possible
with DHTML. That is, slow to moderately paced action, real-time
animation, and interaction. (There is a class of web-based
games that do not fit this category, mostly because there's no
real-time - or sometimes any - animation, and the general pacing
is limited to very slow action because of the technologies
involved. This includes games built on back-end technologies
like Perl, PHP, Python, and Ruby where the client must connect to
the server to update the game. And, yes, AJAX can be used to
make the connections quicker and more seamless, however, for the
purposes of this article, that would move the game into the
DHTML arena with a serverside back-end.) That said, the most
popular technologies that people turn to when making non-DHTML, web-based
games seem to be: Adobe Flash and Shockwave and Java Applets.
(On a side note, NetREXX can be used to make applets for the
Java environment which are written in an extension of REXX rather
than the Java language. For an overview,
click here.)
So, what do these other choices have that DHTML doesn't?
- Audio - Really, this is a pretty
big disadvantage to DHTML-based web games. Web browsers
rely on plugins to handle audio. In many cases, a browser
is able to handle audio without any intervention on the user's
part, but that's really only because the plugins were installed
and set up for the user. Because of this, there really isn't
a solid, cross-browser, cross-platform, dependable way to
include audio through HTML, JavaScript, and CSS alone. On the
other hand, Flash, Shockwave, and Applets can handle sound
with very little trouble.
- Speed - The programming language that
powers a DHTML game is JavaScript. (Okay, this doesn't
necessarily have to be the case, but the following is
true of any implementation of ECMAScript regardless.) As a
result, the speed at which your game can be processed (and
therefore, the number of calculations you can perform for
everything from animations to keeping track of game stats
and everything else that happens in your game), depends on the
speed at which the player's web browser can interpret and
execute your JavaScript code. Unfortunately, this can range
wildly from a snail's pace to hyperspeed depending on many
different factors. As the game developer, you just don't have
a lot of assurance that your game will run at the speed you'd
like. On the other hand, because Flash, Shockwave, and
Applets are all processed by an interpreter outside of the
browser, you have a lot more assurance that the way you see
your game running is very similar to how most of your players
will, too. (If this last sentence sounds overly qualified,
it's only because I have too much firsthand experience with the
ways that Flash, Shockwave, and Applets can also run at
different speeds in different environments.)
- General Technical Limitations - This final
drawback is tied in many ways to speed and also to the
fact that DHTML is interpreted by the web browser itself
instead of an outside plugin. Because DHTML needs the web
browser to interpret it, a myriad of problems pop up because
of the different ways various web browsers process the
exact same HTML, JavaScript, and CSS. In short, what works
in Internet Explorer, may not in Firefox, but may in Opera.
Again, because the Flash, Shockwave, and Java Applet interpreters
are created specifically to run your game roughly
the same everywhere, you have more options open to you with these
technologies than with DHTML. For example, alpha channel
transparencies in PNG files are supported natively in Firefox but
must be handled through filters in Internet Explorer. This may
seem like a minor issue, but it's discrepancies like
these that can cause your DHTML game to fail. In short,
you can consistently process more and faster with Flash, Shockwave,
and Applets than you can with DHTML.
If after reading the disadvantages to web-based
game development with DHTML, you find yourself thinking that the
advantages don't even come close to the disadvantages, I'd have to
argue that it really depends on the nature of the game. I recently
had the opportunity to work on a team creating a mostly DHTML-based
game. (The game does incorporate Flash files but for audio purposes
only.) It's a Halloween-themed, puzzle game with only minimal
animation. For our purposes, DHTML produced exactly what we
were hoping for. Could we have done more with Flash, Shockwave,
or an Applet? Sure, but our intention was to create a relatively
simple game that could be played on low bandwidths and without the
need for plugins. (You can see what we created by
clicking here.)
DHTML worked perfectly.
Is there a place for DHTML in the web games
developer's toolkit? I definitely think there is under certain
conditions, and I'll be looking forward to the chance to work
on more DHTML-based games in the future.
|
|
