by David Boswell, Brian King and Robert Watt
Bleeding-edge early 80s technology: Part One
In a way, this is like connecting a DSL line to a Commodore 64 computer. We're working on rewriting an arcade game from the early 80s using Mozilla technologies. By combining two different technologies from two very different times, we hope to be able to learn something new from examining a classic example of programming in a new way.
Our intention is to show that Mozilla has the ability to be more than a web browser. Other demonstrations of alternate uses of Mozilla like the Script Editor and XMLTerm already do this, although these tend to feel more like extensions of the existing Mozilla framework. A more radical non-browser application of Mozilla would have the benefit of extending the discussion of Mozilla as a platform and might bring new people into the community who are interested in this new aspect of the project.
Why this game? Why Mozilla?
In the 20 years since the arcade game that we are emulating came out, many different versions have been created in many different ways. We'll re-create this game one more time because it's a programming tradition to take an old concept and rehash it in new ways to learn more about a language or technology.
Other web-based clones of this game exist on the Internet. Most of these versions were created in one of two ways: using the inconsistent and limited implementations of DHTML in current browsers, or using Java, which can be buggy and may result in horrendous lag time.
PAGMAN is being developed in XML because of its efficient data-handling capability. Because we're working in Mozilla, we won't worry about the problem that prevents XML from being more widely deployed on the web today: lack of browser support. (Even Internet Explorer 5's XML support is partial and not compliant with the W3C's standard.)
DHTML has also languished to some degree because of incomplete support in the browser. As Mozilla's popularity spreads, we can expect to advance the evolution of DHTML into DXML, or Dynamic XML. This is the real reason we decided to use XML in our project. We certainly could have used HTML that would work in 4.0 and higher browsers, but the goal of this project is to use new technologies to create possibilities that didn't exist before.
The XML grid
The game maze is represented as an XML grid of graphical elements. We only need a handful of these elements to create the grid: dots, power pellets, vertical walls, horizontal walls, blanks, and four different corner elements (upper right, upper left, lower right, and lower left).
Our XML file is fairly simple. It allows each of the graphics to map to a unique section of the grid structure. We haven't built the entire maze yet, but have proven the concept with a sample 6x5 grid. Our sample contains each of the different graphic elements to show how they work together.
The XML tagset contains column tags contained within row tags. In our sample grid, 30 unique points have been created that can be tracked individually. Although we are using generic graphic elements, each point on the grid is unique. This means we can control each point on the grid, allowing us to change a dot to a blank after the dot has been eaten. Here's an example of the code for one row of the sample grid:
See the full code for the sample XML grid file.
<row_04> <col_01 class="vert_wall" /> <col_02 class="powerup" /> <col_03 class="vert_wall" /> <col_04 class="blank" /> <col_05 class="blank" /> <col_06 class="vert_wall" /> </row_04>
The grid created with this file can be displayed on-screen using an associated CSS file. The style sheet maps the different graphic elements to each of the grids using the class values assigned to the tags in the XML file.
The fully working XML+CSS grid has not been completed yet, but an HTML version of this sample grid shows the different elements together. One view of the grid shows the individual pieces separated, and the other shows the same images joined to form a coherent section of the maze.
Now, it's simply a matter of expanding the XML file to map each of the different grid points to finish the maze. Once this basic foundation is in place, the other elements can be added and hooked in to the functionality that will make the game run.
This series will end with an article that details taking the working game and wrapping it inside an arcade-like XUL shell complete with movement commands and game options built into our Mozilla-based application. We hope this will demonstrate the creation of a full-featured non-browser application that runs on Windows, Linux, and Macintosh computers.
Of course, the next article might be all about how we were completely wrong about our XML grid approach to creating this game. We are developing PAGMAN at the same time we are writing about it, so we can only guess how this project will turn out. We will be keeping track of our errors along with our progress, and we will tell about both in future articles in this series.
Discuss this article in the O'Reilly Network Browsers Forum.
Return to the O'Reilly Network Hub.