Testings

After compilation, open two winDressing screens. Connect both devices. The winDressing will ask for an alphanumerical name for a screen. In my tests, I always call the winDressing screen that represent the left hand side Stratego game device "Client0" and the right hand one "Client1" for simplicity and clarity. It is now time to start running the program. The first thing that would happen is that the two SBI (Bluetooth) inside TwinToothTest would set up the connection and configuration between them. After these events, two things would occur depending on whether it is the Test Hardness or the Integrated Bluetooth program that has been compiled.

In the case of the Test Hardness, no graphics would be loaded. This means that one could jump right on to use the mouse to click onto a point and drag the mouse to another point anywhere on the winDressing screen. This "drag and drop" action would create a string. This string represents the new location of where the point is released and this string would be posted out of the mouseClicksOut port into the mouseIn port of the mouse2string module. This module would convert the output of the mouse click into a string with the format "mouse_click(x,x,x)" This string also appears in a number of diagnostic boxes.

In the case of the Integrated Bluetooth, one has to be very patient. This is because the graphics of a dozen game pieces and the START icon take a long time to be loaded onto the two winDressing screens. The cause of this phenomenon is uncertain, the biggest suspect would be VCC since it has to run some large and complicate programs. What's more, the parameter Interpulse Time for the CLKN module in the PacketBaseband Layer of Bluetooth can be reset to change the speed of VCC execution by many folds. However, after some experimenting only the parameter value that is in use now (0.0003125) could allow the graphics to be loaded one by one safely and reliably. Unfortunately one has to wait between 10 to 15 minutes until the VCC timer has reached the value of 170. After the START icon had showed up at the lower left corner, the player must first click on the winDressing screen for Client0 (left) to start the lobby before one can begin to move any game piece. After that the game pieces can be positioned.

The Test Hardness was made by the joint effort between Andrew and James in order to test TwinToothTest completely on its own in a "pure" environment. The aim is that I have to make TwinToothTest works in the Test Hardness before it can be integrated into the game devices. This section is trying to show that TwinToothTest (Bluetooth) works in the Test Hardness environment.

After compilation, The strings inside the diagnostic boxes means that TwinToothTest is functioning in the Test Hardness. However, the output ports out1 and out2 of TwinToothTest (Bluetooth) are not connected to anything. This is unnecessary because the diagnostic boxes that display the traffic across these two ports are enough to show whether the string from the in1 port has come out from the out2 port or the string from the in2 port has come out from the out1 port, via TwinToothTest (Bluetooth).

This is the behavious of TwinToothTest, it shows the internals of TwinToothTest with diagnostic boxes to show the strings that have travel between the two SBIs. TwinToothTest is actually the Bluetooth that is going to be integrated into the Stratego environment when it is fully functional. The strings inside the diagnostic boxes show that TwinToothTest is now connected, configured and able to send and receive strings.

This section shows the messages passing between Client0 (the Stratego game device at your left hand side) and Client1 (your right hand side) via the TwinToothTest module (Bluetooth) when every time a game piece has been moved on the winDressing screens(the blue pictures with the name "Stratego").

The following diagrams had captured only the results of moving two game pieces on each of the game device. After Client0 had started the lobby, the player can start setting up the positions of the game pieces.

Every time a piece was moved by a mouse click on a winDressing screen, a string that describes the new location of the piece would be created and sent out via the out port of the game device. This string will appear in the diagnostic box if one is connected to this port. Each of the following diagrams have a number of diagnostic boxes connected to the main input and output ports of TwinToothTest (Bluetooth) as well as both game devices (Stratego). Diagnostic boxes are not part of the implementation of these modules, they are there to display the traffic (strings) leaving and entering ports.

1. Client0 moved its first game piece.
2. Client1 moved its first game piece.
3. Client0 moved its second game piece.
4. Client1 moved its second game piece.

After the Stratego game device on the left hand side (Client0) had set a game piece to a new location. The string "move,0,2,-1,3,1" was produced and posted via the out port into the in1 port of TwinToothTest. TwinToothTest would then send this string from the Master SBI through the "air" (Bit-PhysicalLayer) to the Slave SBI. The Slave SBI would post the same string out of the out2 port of TwinToothTest into the in port of the Stratego game device on the right hand side (Client1). All this means that the string from Client0 had reached Client1 via TwinToothTest (Bluetooth).

The graphics on the Client0 game device would be updated to reflect this change.

This diagram is the expansion of TwinToothTest (Bluetooth). It also has a number of diagnostic boxes to display the movements of a string. Here, the same string "move,0,2,-1,3,1" has entered the NET_In port of GBI_Test from Client0. GBI_Test then post this string to the Input port of Master SBI (more accurately the Input port of GBI that resides in SBI). Eventually this string would travel across the Bit-PhysicalLayer (aka."air") into Slave SBI. Slave SBI would post it via its Output port into GBI_Test. Finally GBI_Test would post this string via its NET_Out port to Client1. Note that some diagnostic boxes are still empty. That is because Client1 had not moved a game piece yet therefore no string was sent out of it.

This shows the result of the second event when Client1 had moved its first game piece. Now, apart from the first string sent from Client0 still around inside some diagnostic boxes, a new string "move,1,4,-1,7,8" from Client1 was born and posted through its out port into the in2 port of TwinToothTest. Both TwinToothTest and I are happy to see this but it is TwinToothTest who would send this string via its out1 port to the hands of Client0.

The graphics on the Client1 game device would be updated to reflect this change.

Now both game devices had each moved a game piece. The corresponding strings had also succesfully sent via TwinToothTest (Bluetooth) to each other. This diagram shows the final results. The empty diagnostic boxes aforementioned had been updated by the new string from Client1.

If a game piece can be moved, it is important to show that another can also be moved. By induction, all the other game pieces can also be moved on the game devices one by one. Most importantly, it will show that TwinToothTest (Bluetooth) is truely doing what it is supposed to.

In this third events of a sequence of four, Client0 had moved another game piece. As a result Client0 gave birth to another string "move,0,3,-2,5,0". This string had replaced the previous one in the diagnostic boxes, and the ports and paths it travelled were exactly the same as its elder sibling. In the end Client1 had received a second string.

The graphics on the Client0 game device would be updated to reflect this change.

The diagnostic boxes that display the input and output string to and fro Client0 had been updated to show the new string. Note that the other diagnostic boxes had not changed. This is because Client1 still has not relocate its second game piece.

Finally, Client1 had relocated its second game piece. The new string "move,1,1,-2,2,9" would replace the strings in those relevant diagnostic boxes.

The graphics on the Client1 game device would be updated to reflect this change.

The diagnositc boxes that display the input and output string to and fro Client1 had been updated as well to show the new string.

By now, both Client0 and Client1 game devices had relocated two game pieces each on the winDressing window screens. The sequence of changes had been captured and displayed above. After all the pieces had been positioned on the "game board", the players can double click on the "START" icon at the lower left corner of both winDressing screens to play Stratego!