Game Development Reference
t need to
change per user (like the links to various pages or media), it could
simply be a file on the server besides your SWF that the SWF loads
in on launching. If the information was dynamic (like a username
or preferences), it could point to a PHP (or other back-end service)
file that returns XML.
If the information contained within the XML file didn
< param name= " flashvars " value= " config=configuration.php " / >
The URLLoader will load in the data as plain text, regardless of file
extension, so as long as the page renders out as XML you
re good to
go. This keeps your back-end developers (or you if you
tion) from having to wrangle variables within a page of already convo-
luted HTML. Here is an example of what a config file might look like.
Remember that you could put whatever information you wanted
to in here and in whatever structure. As you can see, this much
more readable option is also easier to parse, and due to E4X, your
basic data types (such as strings and numbers) come through
intact; Flash Vars are all strings.
In this chapter we
ve explored a few uses of XML in games. There
are definitely many more. Some developers I
ve met are wary of
using XML, feeling that doing so forces them to use an elaborate,
complex setup or follow some
guide to formatting
they read in a 500-page tome on XML in an Enterprise setting.
Nothing could be further from the truth; use XML where it makes
sense, keep it simple, and try to follow a structure that lends itself
to growth. The great thing about XML is that it is a standard in and
of itself, and ActionScript 3 makes working with it a no-brainer.