Gaming Development Setup - Introducing XML (Page 3 of 8 )
To build, package, and deploy your games, you need to understand the basics of Extensible Markup Language (XML). XML is also useful for storing game data and user preferences on the hard drive and passing multi-player messages over the network. This section introduces XML briefly.
XML allows you to describe data using human-readable text. In the following example, note how each data value is encapsulated in an opening and closing element tag pair that names the data field.
<book>
<title>Advanced Java Game Programming</title>
<author>David Wallace Croft</author>
<publisher>Apress</publisher>
<pubdate>2004</pubdate>
</book>
Those familiar with HTML will recognize the similarities. It looks like HTML except that I have created my own element names such as book and title. HTML already defines the element title, but here I have given it a new semantic, or meaning, that differs within the context of my book definition. Indeed, this ability to define new elements is why XML is considered “extensible.”
Despite the flexibility in being able to define new element names, there are enough constraints in the XML format that parsers do not need to be customized uniquely for each definition. Such restrictions include a strict hierarchical nesting of elements. For example, the following XML syntax with overlapping tag boundaries would generate a parsing error.
<b><i>Illegal XML</b></i>
Although the preceding code might be valid in HTML, the proper way to nest the elements in Extensible Hypertext Markup Language (XHTML)—a definition of XML that replaces HTML—would be as follows.
<i><b>Legal XML</b></i>
Hundreds, perhaps thousands, of XML definitions now cover everything from genealogy to electronic commerce. Wherever data needs to be exchanged in a transparent manner using standard parsers that are readily available in all the major programming languages, XML provides a solution.
Further information on the subject of XML is easily accessible from a large number of sources as XML has rapidly become a widely adopted technology. As a quickly digestible introduction and handy reference book, I recommend the XML Pocket Reference, 2nd edition by Robert Eckstein (O’Reilly & Associates, 2001).
Compiling with Ant Ant is the Open Source tool that you will use for compiling the example game source code. Ant is more powerful than older tools such as make as it is extensible and cross-platform. Although some warn against it, you might want to consider using Ant as a universal scripting language to replace your platform-specific batch or script files. If it lacks a function you need, Ant happily allows you to integrate any Java code you want to write to increase its capabilities.
Ant is distributed from the Apache Jakarta Project web site and has gained rapid and almost universal acceptance by the Java community. If you have not already learned how to use Ant, you should consider doing so. You can start by reading the online documentation at http://ant.apache.org/.
<project name="myproject" default="compile">
<target name="compile">
[...]
</target>
<target name="archive" depends="compile">
[...]
</target>
</project>
Ant takes its instructions on how to compile the source code from an XML build file with a default name of build.xml. A build file is organized as a project with multiple targets. Each target contains zero or more tasks that are the commands executed by the Ant processor.
The tasks in a target are usually related in a set that might depend upon the successful completion of one or more previous targets. For example, I might have a target called archive that archives the latest version of my source code and moves it to a backup directory. The archive target might depend upon another target called compile that attempts to compile the entire library. If I run Ant on my project build file with the target archive specified as a command-line argument, Ant first attempts to run the compile target. If that step fails, it terminates operations without proceeding to archive.
You can compile and run most of the example game source code by running Ant on the build.xml file in the library root directory using the default target. The following is a line-by-line review of the first part of the file that you use to build the main demonstration program. This is the build code that you could adapt to compile and package your own games.
<project name="croftsoft" default="demo">
If this build file is executed without specifying a target as a command-line argument, Ant assumes the default demo target.
<property name="arc_dir" value="arc"/>
<property name="res_dir" value="res"/>
<property name="src_dir" value="src"/>
<property name="tmp_dir" value="tmp"/>
To prevent the directory names from being hard-coded in the rest of the build file, define them here using property variables. Once a property value is defined, it cannot be redefined later in the build file. You might need to adjust these directory names to match your own preference.
<target name="init">
<mkdir dir="${arc_dir}"/>
<delete dir="${tmp_dir}"/>
<mkdir dir="${tmp_dir}"/>
<tstamp>
<format property="TODAY_ISO" pattern="yyyy-MM-dd"/>
<format property="YEAR" pattern="yyyy"/>
</tstamp>
</target>
The default target demo indirectly depends on target init so I will review the init target first. It starts by creating the output and temporary working directories. If the output directory arc_dir already exists, the build file presses on without throwing an error. The temporary directory is re-created to make sure no old files are left behind from a previous build attempt.
Task tstamp sets a property called TODAY_ISO to a value representing the current date in International Standards Organization (ISO) format such as 1999-12-31. Some of the following targets use this property to append the date to archive file names.
<target name="shooter_prep" depends="init">
<copy todir="${tmp_dir}/media/shooter">
<fileset dir="${res_dir}/apps/shooter/media">
<include name="shooter_bang.png"/>
<include name="shooter_boom.png"/>
<include name="shooter_rest.png"/>
<include name="bang.wav"/>
<include name="explode.wav"/>
</fileset>
</copy>
</target>
In preparation for compiling the demo, the resource files for a game are copied from the resource directory to the temporary working directory. The preceding code demonstrates a variant of the copy command that uses a fileset. Rather than issue a separate copy command for each file, you use the fileset tag to copy all the files to the temporary working directory in a single command. You can also use wildcards and pattern matching to describe the files to include in a fileset. I like to specify the files individually by name so that I know exactly what is being packaged.
<target name="collection_prep1" depends="basics_prep,dodger_prep,fraction_prep,mars_prep"/>
<target name="collection_prep2" depends="road_prep,shooter_prep,sprite_prep,
tile_prep,zombie_prep"/>
<target name="collection_prepare" depends="collection_prep1,collection_prep2">
<copy file="${res_dir}/apps/images/croftsoft.png" todir="${tmp_dir}/images"/>
</target>
Target collection_prepare depends on collection_prep1 and collection_prep2. I break it up this way so that the depends tag value does not run too long. The purpose of collection_prepare is to copy all the resource files for the individual games that go into the CroftSoft Collection into the temporary working directory. It also copies any additional resource files, such as croftsoft.png, which you use for the frame icon.
<target name="collection_compile" depends="collection_prepare">
<javac srcdir="${src_dir}" destdir="${tmp_dir}">
<include
name="com/croftsoft/apps/collection/
CroftSoftCollection.java"/>
<include
name="com/croftsoft/ajgp/basics/BasicsExample.java"/>
[...]
<include name="com/croftsoft/apps/zombie/Zombie.java"/>
</javac>
</target>
You use the javac task to compile the source code in the src_dir directory and output the compiled class files to tmp_dir. Normally you would only need to include the main class and javac would be smart enough to compile all the other classes that are required. In this case, however, the individual game applets are linked dynamically instead of statically and you must also name them explicitly. This is described further in the next chapter.
<target name="collection_jar" depends="collection_compile">
<echo
file="manifest.txt" message=
"Main-Class: com.croftsoft.apps.collection.CroftSoftCollection" />
<jar
basedir="${tmp_dir}"
destfile="${arc_dir}/collection.jar"
manifest="manifest.txt"
update="false"/>
<delete file="manifest.txt"/>
<delete dir="${tmp_dir}"/>
</target>
<target name="demo" depends="collection_jar">
<java fork="true" jar="${arc_dir}/collection.jar"/>
</target>
If the collection_compile target compiles successfully, the collection_jar target executes. The collection_jar target packages the temporary working directory contents, which include compiled code and resource files. It overwrites the old JAR file if it exists in the output arc_dir directory. When completed, the temporary directory is deleted and the newly created executable JAR is launched in a separate Java Virtual Machine (JVM) for testing.
The rest of the build file contains additional targets that compile demonstrations and examples that require optional packages beyond what the core J2SE library includes. A quick review of the comments embedded in the build file will tell you what optional packages are required to compile and run some of the additional example games not included in the default demo target. You can safely ignore these other targets for now as I will cover them in later chapters of the book.
Ant basics
If Ant is properly installed, you should simply be able to enter the command ant in the directory containing the build.xml file and the default demo target will compile and launch. If you want to specify a different target, you simply provide it as a command-line argument as shown in the preceding code. Target basics, for example, builds and launches an example game described at the end of this chapter. If you have not already done so, go ahead and build and run the demo using Ant and the example build file.
 This article is excerpted from Advanced Java Game Programming by David Wallace Croft (Apress, 2004; ISBN 1590591232). Check it out at your favorite bookstore today. Buy this book now. |
Next: Using Open Source >>
More Java Articles
More By Apress Publishing
/ 31 
