XR7 SUPPORT AND SOURCE PACKAGE SUMMARY

Cost: $34.95 (includes worldwide shipping and tax).

Source: 1 compact disk with complete source code and Visual Studio workplace files.

Documentation: Arcade Game Design with C++ and DirectX, a case study of XR7: EarthStrike. This is a 2-volume technical document consisting of over 300 pages.

Support: 60-days technical support (lifetime free online access to revisions).

Please note that this package, from the learning perspective, is for those who understand that developing skills and gaining programming intuition takes time. This package provides a way to take a few more steps in one's journey towards mastering the arts and sciences behind game development. It is not a shortcut to gaming glory but instead is a building block for learning the craft. It is also a royalty-free resource that can be used for personal and commercial projects. View royalty-free license.

XR7: EarthStrike represents a supported upper-level introduction to the world of game development by combining the simplicity of the old genres of games with the new 3D methods. So, while the game represents classic 1980s style genres, the behind-the-scenes technology is all modern. The most important change over the old methods is that 3D models represent the main actors (such as ships, lasers, asteroids, etc.) and they are rotated, scaled, transformed and rendered on-the-fly rather than pre-computed and blitted to the screen as sprites. Likewise, collision detection is done based on 3D models operating in a 3D space rather than 2D sprites intersecting on a plane. Moreover, particle systems are used for special effects rather than using sprites in a cell-like animation sequence.


Some Technical Characteristics of XR7: EarthStrike

Written in Visual C++ v6 with the MS DirectX SDK (compiles with both v8 and v9). All elements that can collide such as the player's ship, weapon fire, walls, enemies, etc. are 3D models loaded from .X files. Background static images and background scrolling tilemaps are rendered as a series of sprites. There is no limit to what a weapon can do -- it can spawn new actors, initiate sounds, initiate particle systems, etc. -- as such, weapon types are only limited by one's imagination. The game is almost totally data driven but should not be considered an engine as it has only been tested with the data used in the game. The GUI can use whatever graphic images one wishes for buttons, sliders and the mouse. Thus, the look is not hardcoded in the code. The GUI images may have transparency characteristics as well. Supports MIDI and .WAV audio formats. With respect to C++ specifics, the code does not use the standard template library or exceptions but does use a class template for a list class.

Brief Summary of XR7: EarthStrike Source

The source code was written with the understanding that others would be reading it as part of a learning package. As the game was written in C++, the majority of filenames are associated with the class whose code they contain. For example, consider the following files:

xr7actor.h
xr7audio.h
xr7font.h
xr7particlesystem.h

The first contains the code for the XR7Actor class while the others contain the code for the XR7Audio, XR7Font and XR7ParticleSystem classes, respectively. The layout of the code and the file naming conventions make it easy to hunt down routines regardless of the IDE (if any). The class hierarchy is quite flat and the relationships between objects tend to be has a rather than is a. The base class, XR7Object, simply serves to count the number of objects created and destroyed and to also provide access to the error/warning logging mechanism (if turned on). Overall, clarity with efficiency was the goal of the design.

The following are some of the classes used in the game, with a brief explanation:

XR7Actor	An actor is an entity that has a model, bounding volumes and a behavior -- the player, all enemies, laser fire, asteroids, etc. are actors.
XR7Audio	Wrapper around DirectMusic; a manager class that handles playing of audio files.
XR7BoundingVolumes	A hierarchy of bounding volumes associated with a model. Contains the collision detection routines to see if two bounding volume hierarchies collide.
XR7Compiler	Takes scanned data and compiles it into structures, objects and sequence bytecodes, that are later interpreted and executed . Verifies bytecode parameters as well.
XR7D3D	Wrapper around Direct3D initialization code.
XR7Input	Wrapper class around DirectInput.
XR7Interp	Class that handles executing sequence bytecodes that were produced by an XR7Compiler object.
XR7Model	Class to handle loading and rendering, individually or in batches, 3D models derived from .X files.
XR7Object	Base class - object counting and logging methods.
XR7ParticleSystem	Wrapper class around basic particle system functionality. This particle system is quite simple but easily extendable.
XR7Scene	Class that represents the realization of a data file's context -- the main bytecode sequence that drives the game, the background color, lighting, drift, bounds, GUI, active secondary sequences, etc.
XR7Sprite	Sprites are textured quads and this class provides basic sprite functionality - loading and rendering including batch rendering. Transformed and untransformed sprites are supported.
XR7StaticList	Class template for a specialized linked list class.
XR7Video	Simple wrapper class around DirectShow video re-play capabilities.

Here is an example taken directly from the source that will give an idea of the coding style used in the game.

EXAMPLE: Code needed to update all the active secondary byte code sequences in the scene:

// UPDATE THE SCENE'S CURRENTLY ACTIVE SEQUENCES
XR7StaticList<XR7ActiveSequence> *active_sequences = m_scene->get_active_sequences();

#ifdef __XR7OBJECT_DEBUG__
    if( active_sequences == 0 )
        return log_msg("null active sequences", __XR7OBJECT_MSG_LOCATION__);
#endif

active_sequences->begin();
while( active_sequences->next() )
    if( ! m_interp->update(active_sequences->get()) )
        active_sequences->remove();


Details are provided in the technical documentation, but, in short, the code demonstrates the scene object returning a pointer to the list of sequences (compiled bytecodes) that are currently active in the scene. The list is traversed and each element in the list is sent to an interpreter object which will process the next bytecode (or bytecodes) waiting to be executed. If the sequence is done then it is removed from the list.

Note that the style is old-school with lowercase, hyphens and no type prefixes for the variables. Error checking for a null pointer is only done when the debug identifier is defined. Generally speaking, only absolutely necessary error checking is provided as a default while more in-depth checking only occurs when the debug identifier has been defined. Another style point is that all classes and most structures begin with XR7 instead of C or S. This will make it easier to copy and paste the code as there should not be a name collision with other code.

For the beginning and intermediate level programmer and for the new game developer, there is a lot of material to digest. From standard C concepts like pointers and unions to the C++ concepts like templates and then to the higher concepts of algorithms for trees and lists and from there to the technology of DirectX and then finally to gaming needs such as collision detection, parsing data files, weapon systems and finally to putting it all together into a complete game! Because of the wide range of knowledge and skill sets required for gaming, the barrier to entry is higher than in other computing fields. However, it also this high barrier that has caused the shortgage of programmers with solid game development skills.


Some Important Concepts covered in XR7

Loading and Parsing Data Files

One of the great things about XR7 is that an entirely new game with new levels can be created by only changing the data files and not changing the source. The game is data-driven and the tools needed to load and parse data files are an important aspect of the game. There are three classes that focus on data loading and parsing:

The XR7DefBlockScanner class is responsible for scanning a text file and building an array of structures that contain information about the definition blocks in the file. The XR7Tokenizer class converts a string into a series of tokens. The XR7Parser class is able to parse the data in the structures created by XR7DefBlockScanner and extract data in several formats.

The same parsing process is used for configuration files as well as the data files that describe each gaming level.

DirectX Wrappers

General purpose wrappers are provided for accessing the capabilities of the DirectMusic, DirectShow and DirectInput libraries. With the exception of Direct3D initialization, access to the Direct3D and D3DX library routines is not wrapped in a particular library. Instead, there are individual wrappers for dealing with sprites, particle systems, models, etc. and each of these classes will directly call Direct3D methods. By understanding the wrappers one will learn how to access the features of the supported DirectX libraries.

Simple Scripting, Bytecode Compilation and Runtime Interpretation

While XR7: EarthStrike is not an engine per-se, it is data-driven. Moreover, the action in the game is driven by a simple scripting system. The system allows for the definition of structures, such as actors and models, and for commands with parameters that are compiled during the processing of the data file and executed at run-time. In addition to the main script commands that drive the game, sequences, which are like subroutines, are also allowed to make reusing commands easy. So, the source provides the basic lessons on parsing commands, compiling commands and their parameters into byte codes and then interpreting the byte codes and executing the associated code during run time. The following represents the basics of the scripting system:

A data file contains variable definitions of supported structures and simple script commands that determine what happens in the game. The data file is loaded, parsed and the variables are compiled into their associated C++ structures and objects. Script commands are compiled into bytecodes. During runtime, the bytecodes are interpreted and executed each frame and those actions drive the game.

Because the scripting capabilities of this game are extremely simple, the method described in the documentation is not difficult to understand but does provide a good introduction to the topic. Extending the scripting and parsing engine is an area for which technical support is provided.

DirectX GUI

The game comes with a simple but flexible sprite-based GUI that supports a mouse cursor, option buttons, sliding thumb, editlines, radio buttons and checkboxes. The GUI interacts well with on-screen model animation, particle systems as well as background music thus allowing for a rich and varied user interface. Because the graphics for each item, in each of their states, are defined in data files, the look of the GUI can be anything the developer wants. This GUI is also easy to extend and technical support is provided for those who need assistance in extending the GUI to handle new elements such as windows or dialog boxes.

Collision Detection

Two methods for collision detection are allowed - both are perfect methods in that they both end up with triangle-triangle intersection tests to determine collisions. The first method is the simple method of comparing, after a main sphere collision intersection test, each triangle of one model with each triangle of the other model. Naturally, this is best only when the models have few triangles. The second method is a tree based method that uses an axis-oriented bounding volume algorithm to create a hierarchy for testing. This method is best when the models have high triangle counts. The class that handles the bounding volumes and collision detection is flexible enough that adding one's own collision detection schemes would be straight forward and would not require eliminating the current methods already in the game. Normally, given the level of sophistication of third-party collision detection libraries, one would use those in commercial or high-performance applications. However, for learning purposes, the XR7 source and support provide the training needed to get one's hands dirty with building and comparing tree hierarchies.

Additionally, having a tree-based method educates users on the recursive algorithms that are typical of programming with trees. If you are not familiar or not well-versed with trees then using them for collision detection is a good place to start -- it represents the fusion of computer science with the needs of game development.

Bringing everything together to form a game...

Often, when looking at each particular piece of a game, one concludes that developing a game is easy. However, when one starts to deal with the nitty gritty, it often becomes apparent that the game development process can be tedious and the learning process more difficult than expected. With XR7: EarthStrike, a finished and documented game with support is provided for experimentation, learning and, like an old car, for taking apart and using the pieces for creating something new.


Support and XR7

What sets the XR7: EarthStrike package apart from normal documentation is that personal technical support is provided. This is assistance in understanding everything about the source code and providing some assistance in extending the game. This support is provided via electronic mail and requests are made via the Xandis.com website. Unlike making a public request on a discussion board, XR7 support is provided privately.

Support is provided for 60-days from the first request. However, the entire 60-days of support must be used with 90-days of ordering. After the guaranteed support period, technical support is provided on an as available basis.

Support includes technical support via electronic mail as well as free downloads of any revisions to the game source and/or technical documentation that may happen over time. Access to revisions is permanent and does not expire after 90-days.