The URL for the book web site is http://www.croftsoft.com/library/books/ajgp/. At that site, you can test the demonstration as pre-compiled and installed online to get a feel for what is available. From time to time, I will update the demo. Check the book web site for new releases and subscribe to the mailing list for notifications of updates.
The demo contains several animated Java programs including games and simulations. You can scroll the tabs at the top of the screen to the left and right to see the entire list. Of special interest is Sprite, a sprite animation test program. As shown in Figure 1-1, you can change the options and parameters to see the different effects on animation performance.
Exploring the Game Library
You can download a snapshot of the source code, graphics, and audio files for the game library as a compressed archive file from the book web site. This snapshot of the code captures the version that is documented in this book. Post-publication archives might also be available. You can also download the most recent development version of the code by using a CVS client. Please see Appendix B for more information.
Once downloaded and decompressed, you can compile and run the example games from the source code. The following sections describe the directory structure of the source code library.Directory croftsoft
The top-level directory within the archive is croftsoft/. It contains the main build file, the readme.txt file, and the library subdirectories. The following list describes the subdirectory structure of the library in detail. Some of these subdirectories are not included in the zip archive but are created when you compile the examples.
The executable Java archive (JAR) and web application archive (WAR) files are placed in this directory when you package your code for distribution as part of the build process. Creating JAR files is described in greater detail in the next chapter.Directory bin
The bin/ subdirectory is a place for your development batch files, scripts, and utilities. My understanding is that bin is short for binaries. This is where you would place your compiled binary utility files versus your source code text files. I could be wrong about the origin of the name of the bin directory: It might simply stand for bin, a place to put things.
You want to append this directory to your path environment variable as shown in the preceding code. This directory contains the batch file javainit.bat that initializes your development environment. This is a useful batch file to run when you start working.
subst J: C:\home\croft\cvs\croftsoft
When working in Windows, I use this to substitute drive letter J: for my working directory. That way my other batch and build files are isolated from changes to the name of my working directory because they use a path such as J:\src instead of C:\home\croft\cvs\croftsoft\src. I use drive letter K: as a shortcut to the application source directory where I do most of my game development.
You can also use javainit.bat to initialize environment variables you might need during the development process. On my machine, I have a number of environment variables defined for supplying applications and utilities with directory names such as JAVA_HOME, J2EE_HOME, JBOSS_HOME, and so on. Note that you do not need to define any environment variables at this time to compile or run the examples.
javac -deprecation -d J:\lib -sourcepath J:\src -classpath J:\lib;[...] %1
The bin/ directory also contains the batch file jc.bat which executes the preceding compile command. I have omitted some of the classpath values here to keep it short. The %1 is the first argument to the command line and represents the Java source code file name to be compiled. If you want to compile everything in the current directory, you can just type in jc *.java.Directory doc
The doc/ directory contains the javadoc documentation for your source code. It is not a location for your manually created project documentation as you will want to flush this directory occasionally to get rid of javadoc documentation for deleted classes without fear that you might be getting rid of something that is hard to replace. Because the javadoc utility generates the contents of this directory automatically from the source code, you should not directly edit nor add these files to version control.Directory ext
The ext/ directory is a place for the optional package and extension library JAR files that are required for your build. Before JAR files, developers used zip files to archive classes so you occasionally see a .zip file name extension in this directory as well.
One of the reasons that I like to collect the extension JAR files in this directory instead of simply using them where they were installed originally is that it makes for a more readable classpath. I would rather use a short argument such as J:\ext\javaws.jar instead of a long one such as C:\Program Files\Java Web Start\javaws.jar. Also, sometimes space characters in a directory name such as Program Files confuse applications that use it in the classpath.
Finally, and probably most importantly, is that it consolidates all of your extension libraries for your project where it is easy to put them under version control. It seems a bit odd to put a third-party binary file under version control when you can usually just download another copy from the third-party web site whenever you need it. This is unreliable, however, as there might be dependencies in the code that require you to use an older version of a library that is no longer distributed from the vendor site. When your ext/ directory is under version control, you have a snapshot of the versions of all the different extension libraries that are known to work reliably with your project. It also makes it easier on your fellow developers, including you if you ever need to move to another development machine. You can pull the JAR files from the version control system instead of downloading them all over again from multiple vendor web sites.Directory lib
The lib/ directory is the destination directory for your compiled Java classes: The files that end with the .class file name extension. This is the -classpath argument to your javac compile command and the -cp argument to the java execution command.
The abbreviation lib stands for library. Keep in mind, however, that this directory is only for the compiled counterparts to the source code files in the src/ directory. You should keep your third-party libraries in a different directory such as ext/ as you want to be able to flush the lib/ directory to get rid of outdated versions of the compiled classes without fear that you will be deleting something hard to replace. Because all the files in the lib/ directory are derived from the src/ directory, there is no reason to place them under version control.Directory lic
The lic/ directory contains copies of the Open Source software licenses. This is described in more detail later in this chapter.Directory res
You use the res/ directory to keep the resource files you need to complete your build separate from the Java source code files. It includes JAR manifests, WAR configuration files, multimedia resources such as audio and graphics, and static data files.
Each source code file has an appropriate position within the src/ directory hierarchy based upon its package prefix. This is not true with other types of files used in the build. Rather than putting those files in the src/ root directory or somewhere below, such as a directory that corresponds to the package that contains the main class for the application, I just keep them in a separate directory altogether, the res/ directory.Directory src
The src/ directory contains the uncompiled Java source code: the files with the .java file name extension. This is also a place for your Hypertext Markup Language (HTML) javadoc descriptions. The javadoc utility looks for the file package.html in each directory in the source path and assumes it contains a description of the classes in the package that corresponds to the directory level.Directory tmp
The tmp/ directory is created during the build process to hold working files temporarily. The directory is usually destroyed when the build ends. If your build is interrupted due to a compile error, this directory might not get removed. It does not hurt to leave this directory in existence if you find it, as the next successful build first deletes it automatically, creates it anew, then deletes it again. If you do decide to delete it manually, the only restriction is that you do not do it while a build is running.
blog comments powered by Disqus