SlipstreamNotes.html
04sep10 CmdrZin
09sep10

ref1: Project Slipstream, draft v.1, November 3, 2009
ref2: Davison, Andrew, "Killer Game Programming in Java", O'Reilly Media, Inc., 2005
   

Project Slipstream Overview

In general, the concepts of Project Slipstream set up an architecture to promote modular design and ease of expansion.[1]
 
 

Use of the 3D Client

The 3D Client will have text status, display, and command boxes (as with the current Client) and an additional 3D view area.
The 3D view will show the building complex room locations as they are explored. These will be simple box frame models with openings to begin with and later detailed to look like the rooms described in the text. Players and Monsters will be indicated by colored spheres or floating dots. Zooming the camera in close can reveal the name and later a figure.
This will make the game look like those spy movies where the handler/controller can see everyone in the building and direct their movement.
 
 

Tasks in ZMUohMy

1) The Client contains a copy of the World.[2]
The reason for this should be obvious if real-time rendering is expected.
2) The rooms (areas) in the Client are flagged to be hidden (encrypted) until the Server send an unlock message (the key) for that room to be visible. Once visible, it will stay that way because Players are deploying sensors while they explore the complex (SOP). This also allows they to see where MOBs are and other Players. Of course, an evil genius could hack their system and disable some of the sensors, but that would never happen here.
3) The Client sends text movement commands as normal and receives info messages. It will also get movement messages for other Players whenever they enter any room, not just the room this Player is in. Same with MOBs.
 
 

Adding the Code Base to the Current Client

Need to expand the window frame to be taller to add the canvas for the 3D view. The text area will be reduced vertically as well.
As a quick test, I copied the base files package over to under the Source Packages of the ZMUohMyNB poject.
    ZMUohMyNB
        Source Packages
            kgp_ch15
                CheckerFloor.java
                Checkers3D.java
                ColouredTiles.java
                WrapCheckers3D.java
I then added the package to MudClient.java
// Added for Java 3D
import kgp_ch15.WrapCheckers3D;
and added the display class to the JFrame of MudClient
    public MudClient() {
        ...
        // New Stuff
        WrapCheckers3D w3d = new WrapCheckers3D();
        pane.add(w3d);
        //
        ...
    }
Did a build and ran it..wah lah..3D..
test 3D Client screenshot
too cool...

Bringing Up the Code Base for the 3D Client

Read ch 14, 15, 16 in Killer Game Programming[2].
Download files for book from http://examples.oreilly.com/9780596007300/ or http://fivedots.coe.psu.ac.th/~ad/jg/code/.
Download and install Java 3D 1.5.1 from http://www.oracle.com/technetwork/java/javase/tech/index-jsp-138252.html.
Open NetBeans (6.9.1) and create a new project.
    File -> New Project -> Java Application
Copy the Ch 14 source files into the src/<package name> directory. This is where the main.java file is by default.
RMC the project to bring up the menu and select Properties. In the Run options, change the Main Class to the Checkers3D
main by using the Browse icon.
Delete the default main.java file from the project since it is now replaced by the Checkers3D one.
Build and run. You should see the checkerboard with a blue sphere in a JFrame window. That's it.
Repeat this process for chapter 16 or just build on this code.
Read chapters 30 and 32[2] for ideas on extending this code into a 3D Client for the Server.
 
 

Division of Tasks (for real 3D games, ZMUohMy will use a simpler system for now)

1) The Client contains a copy of the World.[2]
The reason for this should be obvious if real-time rendering is expected.

2) A Collision with a static World object is handled by the Client.
It is up to the Client to enforce the laws-of-physics within the World.
static object does not have to be solid. It could be passable, as a doorway, a trigger point, an area of water, etc.
It's key characteristic is that it doesn't (normally) move.

2a) An Event may be sent to the Server when a collision occurs or an interaction is attempted.
This suggests that each object has rules-of-engaement associated with it.
Examples:
A glass window may have rules defining how much force is needed to break it.
A door (unlocked) may have rules to trigger an "open" or "close" sequence when the Player is near and presses the "activate" <spacebar> key.
A tripwire may have a rule the says "send message to the Server as to who or what has entered my space".
A wall might have a rule that tracks how many times a Player runs into it.

3) Collisions occur when one moving object intersects with another object (moving or not).
An Object can have Client side rules to follow when a collision occurs and Server side rules that can impact game play.