Project documentation
Index
Development environment
Scene graph
Class diagram
JavaDoc
Building the project
Concepts
Comment
Additional documents
History
Links
Glossary
Copyright and credits
Development environment
The following development tools were used:
| Java libraries: |
JDK 1.2, Java 3D 1.1.1 |
| IDE: |
Symantec Visual Café 3.0c |
| OS: |
MS Windows NT 4.0 SP 4 / W2k b3 |
Visual Café configuration
For using JDK 1.2 and Java 3D with Visual Café it has to be configured
first:
For JDK 1.2 a new Java virtual machine must be defined under ‘Tools,
Environment Options…’ à Virtual Machines.
The Java 3D libraries must be specified in the classpath field. These
are: j3daudio.jar, j3dcore.jar, j3dutils.jar and vecmath.jar.
Scene graph
The most part of the scene graph is dynamic. Each time a player makes a
turn a new wall will be introduced in the player’s branch group.
Note that no light sources are defined (yet). Only the default ambient
light is used.
Depending on the start options the scene graph can vary: One or two
player, with or without debug window.
The debug window is an additional view connected to the local.
Scene graph with two players and the debug window:
Class diagram
JavaDoc source documentation
For the detailed source documentation see the JavaDoc
documentation.
Note:
This was my first real Java program and also the first time I've used
JavaDoc. I have to admit that I don't really like the final source code.
For me it looks too inflated mainly because each comment uses at least
three lines. This is because I've used Visual Café that simplified
the hole documentation.
Building the project
Visual Café is not needed for building the project, one can also
use the command line and a normal text editor. It's just gives you very
powerful development tools, e.g. the source and JavaDoc browser and the
auto complete function.
On the command line: javac *.java
In Visual Café: In the Project menu select Rebuild all
Concepts
The main concepts of the implementation are described below:
Collision handling
The Collision handling is an essential part of the game. Only the player
wins who doesn't drive into a wall.
Problems
The longer the game, the collision handling gets more complex. At every
forward move of a player the player wall will be modified and at every
turn a new wall will be introduced in the play field.
Requirements
Performance is everything!
The game (= frame rate) has to be smooth at every time. New walls are
introduced during the whole playtime. These results in more processing
time in the render engine, especially in non hardware accelerated systems.
So we have always lesser processing time for collision detection!
Java3D has an own collision detection mechanism built in made with
behaviors.
One could mean: great, we already have a collision detection! That's
true, but the bad news is: it's to slow because it's a general approach.
We have to build our own collision detection routines...
The good news: because we don't have any elevations, the play field
is only two-dimensional. This results in a much simpler concept - read
on...
Implementation
The play field is divided into 1x1 m squares. The size of 1 meter was chosen
because the width of a player wall is 1 meter. This gives the two dimensional
collision matrix which is mapped on the play field. Each square is represented
with the x and y position in the matrix. The matrix consists of byte elements.
The player can freely move inside the squares. Each time he enters
a new square the appropriate field in the collision matrix will be set.
Note: The movement and exact position of the players has nothing to
do with this matrix. This is implemented with vectors (because it has to
be much more precise).
The collision matrix can be seen as a parallel projection from the top
of the play field. Each 1x1 m element of a wall is a flag in the collision
matrix. This limits the length of a wall to multiples of 1 m.
Only one thing has to be adjusted in the movement logic. Each turn
has to be in the middle of the current square so that the walls are exactly
mapped to the collision matrix to avoid confusion. For example one player
moves on at the end of a collision square and his opponent is at the beginning
of the next square. In the view of the two players this would look like
a collision, but not in the collision matrix.
This approach limits the complete collision handling to setting and
reading flags from the collision matrix. It makes no different how many
walls are on the field or how large the play field is. The time to detect
a collision remains constant! (Personal note: cool!!!)
The walls
Another essential part of the game are the walls drawn behind the players.
Requirements
Performance is everything!
The actual player wall is constantly modified during the player moves
forward. The modification of the wall has to be implemented very efficiently.
Implementation
A wall is defined as a rectangular box implemented with a Shape3D Object.
The wall width is defined as one meter and the height as three meters.
The endpoints of all sides are defined in a float array and the shape
is constructed with a QuadArray.
There are two types of walls: Static and dynamic walls. Dynamic walls
are used for the current wall drawn behind the players. These walls are
replaced through a static wall after the player makes a turn.
The dynamic wall is derived from the static wall and extends it with
a function called setEndPos to set the current position of the player.
For performance reasons the bottom side is not defined. For even further
performance improvements the top side could also be left out. But for debugging
with the debug window, it would look a bit strange or one couldn't even
recognize all walls if viewed from the top.
Key navigation
Because the time for this project is very limited, the navigation was kept
as simple as possible. Only the keyboard is supported as input device.
Problems
The key handling cannot be implemented with the standard key input handling
provided by Java. The reason is, that several keys at the same time can
be pressed and released.
Implementation
The solution is to use the key behavior functionality. Every key press
and released generates an event. These events will be captured, stored
and processed depending on the key and previous state of the key or in
conjunction with other pressed keys. E.g. pressing the Shift key results
in a speed up of the forward moving.
Fortunately Sun released a free available utility class called KeyNavigator
that implements exactly this functionality. Because this class wasn't designed
for instantiating and extending, I've made a similar class called KeyNavigatorEx
with the logic taken from the original Sun class.
KeyNavigatorEx allows setting the navigation keys at run time and contains
only the needed functionality from KeyNavigator.
For each player a PlayerKeyNavigator derived from KeyNavigatorEx will
be instantiated. PlayerKeyNavigator is responsible for making the transform
changes on the player's view at each turn and the key processing.
Comment
This project made a lot of fun (excluding writing the documentation ;-).
It was my first real Java project. Coming from the Microsoft Visual C++
world I was surprised how easy, straightforward and effective Java is!
With the computer graphic background submitted in the first part of
the computer graphic course it was relatively easy to understand and work
with the Java 3D model.
At this point I have to excuse for the short documentation, the most
important things are mentioned but it could be well extended. With three
other projects running at the same time I just can't spend more time on
it.
It's a pity that I don't have more time to implement more functionality
(see enhancements in the user documentation).
Probably I'll work on on the project in the near future…
Additional documents
| Document |
Description |
| User documentation |
The user documentation. |
| JavaDoc |
The generated JavaDoc documentation from the source files. |
History
| 06.07.99 |
Initial release. |
| 07.07.99 |
Project due date.
JavaDoc updated. |
Links
Sun: Java site, Java
3D site
The
Java 3D FAQ
Tron - the
movie
Glossary
Last but not least, the definition of used terms:
| Term |
Definition |
| 3D |
Three Dimensional |
| API |
Application Programming Interface |
| IDE |
Integrated Development Environment |
| JRE |
Java Runtime Environment |
| JDK |
Java Development Kit |
| OpenGL |
Open Graphic Library |
| OS |
Operating System |
| SP |
Service Pack |
| W2k b3 |
Windows 2000 Beta 3 |
Copyright and credits
Copyright © 1998,1999 Berner Fachhochschule, Markus Zehnder.
The Tron 3D game is written by Markus Zehnder.
KeyNavigator and KeyNavigatorBehavior class by Sun.
This software is provided "as is" without express or implied warranty.
Use it at your own risk!
The author accepts no liability for any damage/loss of business that
this product may cause.
Last revised: July 07, 1999
Author: Markus
Zehnder
