Patience Game Example

This page discusses the patience game at greater length. The annotated code is a detailed description of how the code works, whilst the discussion the more general issues of preprocessing and properties. The last section will continually show recent modifications and variations to the program to make it more efficient or more readable.

The patience game lives the Games Room world.

Annotated Code

 #include "dive.vh"
 #define BOARD_SIZE (1.0)
 #define BOARD_DEPTH (BOARD_SIZE/10)
 #define BALL_SIZE (BOARD_SIZE/15)
 #define BALL_SPACING (BOARD_SIZE/7.5)
 #define BALL_FUDGE   (3*BALL_SPACING)
 #define ball(MAT, SIZE, X, Y)\
         name "Ball X Y"\
         translation v ((X*BALL_SPACING) - BALL_FUDGE)\
         ((Y*BALL_SPACING)-BALL_FUDGE) (-0.48 * BOARD_DEPTH)\
         nograsp on \
         realobj on\
         material MAT\
         texture "http://www.cs.ucl.ac.uk/research/vr/Dive/textures/n030.rgb"\
         view {SPHERE SIZE SIZE SIZE}\
         inline.tcl "patienceball.tcl"

 object {
     
     name "Game"
     material "GREY_M"
     view {      
         CTEXT 0.075
         "Reset" "ccp"
     }

Discussion

Preprocessing

The ball shows several stages of preprocessing. Firstly the whole file is passed through the C preprocessor to expand each of the:

       ball("YELLOW_M", BALL_SIZE,6,3)

macros. The definition of a ball thus comes out like this:

The macro subsitution allows you to do some powerful things, and it is used a lot in the standard dive objects. The next stage is to replace the

With the actual script:

This is wrapped in a pair of begin.tcl and end.tcl statements .

Next any Dive default definitions are replaced. In our case this means that things like default material:

is replaced by the actual definition which is:


If you then look at the source of the ball inside vishnu you'll see that the complete definition looks like:

Now of course if you make any changes you will see them within vishnu, but if you save your file out then you'll lose all your nice macros and be left with a long winded file that is difficult to understand.

NOTE1: The reason that the behaviour is inlined is that the cpp macro substution doesn't pay attention to line break and puts everything on one line. This is fine for the Dive definition, but tcl scripts get mangled since their structure is derived in part from their file layour.

NOTE2: You can't use any TCL comments in your .vr files since cpp doesn't like them

NOTE3: the ball's dive_register lost the nice names of the signal (INTERACTION_SIGNAL DIVE_IA_SELECT) and replaced it with their integer definitions (4 1). You can look this sort of thing up in the file dive.vh in the main Dive data directory

Property Behaviour

First thing to try is what happens if you take out the lines:

If you run a multiuser system, you'll see that each person can highlight a different ball so you have two highlighted balls. Only is really highlighted on the current system and this leads to confusion since the collaboraters could see and do different things.

What has gone wrong is that there are two tcl interpreters running, one on each machine. The interpreters access a common database, but also have local state (first_x, first_y etc..) This state isn't shared so the interpreters can be in a different state. This might not be a problem but it usually is.

What is needed is some way of specifying some higher level information that says that only one ball can be highlighted at a time. We need this information to be shared between both machines, and to be updated in a timely fashion.

This is what properties do. A property specifies a way of wrapping arbitrary data from interpreters into dive types so that they can be propogated through the dive database.Their use is quite simple, but there is a small performance penalty to pay. You have to bear in mind that latency is a problem and it is still possible to get the interpreters to diverge.

Modifications and Variations

Avoiding Properties

Astute readers (always wanted to say that) will have noticed that the use of properties in this example is actually redundant. This is because all the information to determine which object is highlighted is actually in the dive database already. Specifically we coloured it red to give feedback about when it had been selected. So instead of storing (first_x, first_y, etc) as global variables in the tcl script and then exporting them as properties, we can search all the sub objects and look for one that is red.

This makes the tcl code longer, but the main drawback is that it is quite slow to check the colour of each ball each time we click on something. There is obviously a trade-off here:

Other Suggestions

Anthony Steed, A.Steed@cs.ucl.ac.uk