by Vincent Ugenti
This page best viewed in 800x600 resolution (or higher)

Project Java Webmaster: Glenn A. Richard
Center for High Pressure Research
SUNY Stony Brook

IMPORTANT NOTE: This applet is written in JDK1.2 (Also known as the Java 2 platform) and utilizes Swing as well as other, JDK1.2 exclusive, features. As a result, it will only function correctly when viewed with the Java2 plugin (included as part of the JRE or Java Runtime Environment). To obtain the JRE, see the following page: Java(TM) 2 Runtime Environment at Sun's web site.

Skip all this and  jump to the applet

Objectives of the project: Designed as an educational game, the applet also serves as proof of concept for Java based action-oriented software both locally and in a distributed environment.

Educational Goals:
    The GridBlaster Java applet is an investigation into the potential of web-based multimedia at facilitating curriculum-based learning. The applet introduces the concept of coordinate pairs, which are fundamental to a greater understanding of coordinate systems and linear algebra. GridBlaster's interface is designed to be accessible to an 8-10 year old audience. The working hypothesis is that, if presented in a fun, engaging way, content that normally isn't introduced until a child's late pre-teens (10-12 year olds) can be effectively introduced earlier in the child's education.

An important objective of the GridBlaster project is to test its educational effectiveness on 8-10 year olds in a classroom setting, the measurable outcomes of which include the ability, or increased ability, on the part of the children to identify the individual elements of a graph and to describe what the components of a linear equation are. Meant to reinforce early graphing skills and help build a good foundation for beginning algebra students. The game is played on a 10x10 coordinate grid, ranging from -5 to 5 in each axis. Children score points and avoid damage by correctly plotting points on the grid. Colorful artwork and an action-oriented playing atmosphere aim to keep children's attention. An adjustable difficulty level ensures that the game will be enjoyable and educational whether seeking to teach basic graphing concepts or simply to refine your speed and accuracy.

Technical Goals:
    Demonstrate the capabilities of the Java platform as a viable tool for developing cross-platform, action-oriented software. Java has received great criticism in the past for being "too slow" due to the interpretive nature of the Java Virtual Machine. What this means is that instead of running a Java program in its own 'native' processing language (as is tradition with most other languages, such as C or Pascal, which generate directly executable machine code) the machine must employ an additional layer of processing to make this conversion from Java to machine code as the program is actually in execution. Java has made great strides on many platforms in terms of execution speed due to the so-called "Just In Time" compilers that generate machine code immediately prior to program execution (at the cost of a longer start-up time). Also, most Java Runtime Environments also support use of multiple native operating system threads for user processes, rather than the so-called Java "green threads" which all reside within a single native thread. However, in the development of truly cross-platform software, we cannot depend on the availability of such niceties as a JIT compiler, or even native thread support. Many notable operating systems still do not have these tools available for use with the Java platform (such as  Blackdown's Linux port of the Solaris JVM).
    The primary technical goals of this project are to overcome these obstacles and create a fast, responsive atmosphere for competition utilizing traditional video game concepts. The current prototype employs fully animated sprites at an excellent display rate, with full support for transparency effects. Use of JDK1.2 features made this possible across multiple platforms (even those that lacked proper native thread support or JIT compilers). Also one of our main aims was to create a small executable that could easily be distributed in Applet form. We were able to achieve a package size of just over 100K, including compiled binaries, source code, documentation and graphics!

Function:
How to play:
    Destroy all the bugs and viruses before they eat your computer alive! Choose a starting difficulty level with the slider at the top of the screen. Bugs will burrow in your screen, damaging you as they travel towards the origin. Viruses will duplicate in number and fill your screen if you don't exterminate them! Destroy these creatures and rack up points by plotting their X and Y coordinates in the control panel at the right, then click on the FIRE button! As the creatures move about and fill the screen, your "Damaged Code Meter" will slowly fill with red. Once it's completely filled, the game is over. Be careful that they don't get too close to the origin (0,0) or they'll do much more damage! And whatever you do, don't fire on the origin! Don't worry though, every now and then some repairs will get done and you'll get some power back. As the game progresses, the creatures will become much faster, appear more often and do a little more damage. They'll also become worth more points. See below for more details on scoring and how to read the scoreboard. The quit button is deactivated while the game is not paused, so you can't quit by accident. Pressing this button while the game is paused will exit the current game and reset the playing field.

Scoring: The scoreboard shows three numbers: the current level, your current score, and the score you must achieve before reaching the next level. Monsters become worth progressively more points in later levels, however the number of points to reach the next level also increases with each new level.

Technical Profile:
    As outlined above, Gridblaster utilizes the JDK1.2 to accomplish its goals. Despite the wildly varying quality of Virtual Machines and support on various platforms, use of JDK1.2 features ensured there would be little difference, if any, between the program's performance on poorly supported operating systems. This required a shift from the "traditional" arcade paradigm of thought. For example, rather than implement every action as an individual thread (which in most cases did nothing except wait for another event to finish) - a decision which would have resulted in a considerably slower product on those VM's which lacked native thread support - we utilize the new JDK1.2 timer and event driven queuing system to perform all these actions on a single thread. This resulted in massive performance gains on all platforms (although most notably on Linux utilizing JDK1.2 Release Candidate 1 which uses the "green thread" model). This choice allowed us to create a system that at higher "levels" of play was blindingly fast with little or no delay.
    To create a program that would run in a distributed environment (i.e. web page such as the applet version shown below) requires an extremely small package size. Utilizing JDK1.2, we are able to accomplish just that. Nearly all features necessary to create a clean, solid implementation of a distributed software application are provided directly by JDK core features. By having our prototype directly extend the Java applet, we can avoid much of the overhead traditionally associated with publishing dynamic web content. What this means is that the "class files" that make up the actual implementation are extremely small - less than 45K! The small images used come close to surpassing the size of the actual program.
    Obviously, however, this prototype can not hope to accomplish all of these goals to the highest extent possible using JDK1.2 language features alone. There are many areas of the prototype which could benefit from increased optimization. For example, there are still a few events which occur separately on their own threads. Also, although we note the time required to instantiate new objects is discernible by human senses (and you can detect this time yourself in the form of minuscule pauses which occur occasionally throughout game play), this prototype does not make use of an internal "object recycler" that would reuse these objects instead of throwing them away and creating new (identical!) ones later. Additionally, transparency effects processed by the sprites are handled in an extremely inefficient manner - drawing pixel by pixel, utilizing no palette, constantly instantiating new color objects. It turned out these inefficiencies had little impact on the prototype, however re-coding this in a more efficient manner would certainly result in a more fluid experience for the user. The final release of this project would have to include all of these enhancements to stand as a truly fluid and easily distributed gaming experience, although this prototype has exceeded the design team's specifications in all parameters including speed, playability, and ease of distribution.

Credits

For additional information see Game -> About in the applet below.

The Java Source code for this program is available.

Java Source Code

MathGame.java

Control.java

GridPanel.java

Sprite.java

SpriteLabel.java