My final project is related somewhat to my future thesis project, although my thesis project intended users will be adults, and with this project the focus is on much younger users. Here it goes: The main purpose is to enhance collaboration between kids, as well as to test levels of attention and comprehension of familiar stories. Kids are at around ages 5 to 8.

Metaphorically, one cannot understand darkness without knowing light; or understand high without knowing low. The same idea I am applying to my testing of the young minds. My argument is that by showing a child a familiar story (i.e. Hanzle and Gratel) at a different point of view, their comprehension, and memory of the story's details may sharpen. I am creating a collaboration game that will allow 2 kids to create, deconstruct and reconstruct a story they are familiar with.

Well, since I'm combining 3 classes within one project, it has 2 aspects: Physical and Virtual. The Physical is related to the device each kid interacts with, and the Virtual is what they effect by using the physical devices. I will divide my notes to those two elements and see how it goes.

-- Physical

Each kid will have a tray with a number of plexiglas pieces arranged in a certain visual sequence. each piece will correspond to a scene of the story that will be represented through a flash interface. The flash interface will reside on the web so that the kids can be at different locations while they play.
Through the game, each kid, on his/her turn, will put a piece on the tray anywhere they like. This way the kids are rebuilding the story by changing the location of scenes. After they place all pieces on the tray, they'll be able to play the movie they both created by replacing the scenes.

At the Flash side, I will make sure that each scene's ending and beginning can match any scene that will be adjacent according to the kids' decision. I always find it easier to understand relationships through diagrams:

As I began testing my understanding of the Cobox-Flash relationship, I realize something - no project is ever complete without a stupid mistake at one point or another. I spent half a day frustrated about a program that was quite simple just to find out that my hex-inverter was turned the opposite way.

After figuring that out, I was pleased with how smooth the flash reaction was to physical buttons. There was not delay when flash received information and not delay when it sent. Luckily, my Flash teacher, Veronique, had given us a lecture and code examples for this type of communication.

Here is the code for the Pic:

Here is the Flash code:

Problem: The above Flash program worked perfectly fine when I opened the Flash SWF from our lab's computer, but when I uploaded the SWF, embedded in an HTML, to my web site, it didn't connect to my Cobox. When I read in the Flash Help files about the XML socket class (which is needed in order to open XML socket into the SWF), I found that for the XML socket to work it needs to connect to a server which is on the same domain as the SWF. If it is not on the same domain, a "cross-domain policy file" (a special XML file) needs to be used. I'm not sure if I am indeed communicating with the Cobox from a different domain, but I will find out next.

Solution: Yup, the above was my problem. The security restrictions have changes for flash 7 players, and now in order to communicate, elements have to reside on the same exact domain. If they are not, a cross domain XML file is needed as a connecting variable. More info about this and other security related changes, can be found here.

Well, I'm back with an actual solution to the above security problem - WEB2COB is the answer!
With much appreciated help from Tom Igoe and Veronique Brossier, I found a pretty simple answer. Tom had informed me about the possibility of adding files to the Cobox, limited to 64K in size. Since the necessary XML policy file has only a couple lines of code, there is no problem loading it to the Cobox.

I contacted technical assistance at Lantronix and they emailed me a folder that included everything I needed in order to install files into my Cobox. The application that does the job is called Web2cob. A not-too-complicated process is well described, step-by-step in the documentation I received from Lantronix.

Web2cob Starter Kit (zip file)

After extracting the file, open the Word document "web2cob example", which explains it all. If you follow this path: "cobox_app" -> "web (limor's)" -> "SOURCE" you can find my XML policy file. You will notice that in the XML file code, I am allowing access to all websites (marking it with an asterisk instead of a website address). I placed the XML on WEB1 spot on the Cobox, but it can be in either of the 6 available spots.

(Note: For some reason whenever I entered the address of my server, with the required absolute path, into the XML code, it didn't work and my SWF never communicated with the Cobox. It took quite a chunk of the day with Tom and Vero to later realize that all I needed to do is put an asterisk instead of an address. Arrrg)

It works like a charm!
Now, a person in Japan can open my Flash SWF on my server and light up some LEDs here in America. I love the Cobox!!

At this stage, I needed to find the logic of my story telling which is the core of my project. I started by searching for a story. I was looking for a fairytale online. It didn't really matter which fairytale, since essentially, this project should produce the same results for any story told. I ended up selecting the Princess and the Pea by Hans Christian Andersen. Each fairy tale can usually be found in more than one style. I chose to use the style I found on this website.

The first step was to break the story into scenes. I decided to divide it to 8 scenes. Now, I knew that there will be lots of testing required for me to realize the final solution and arrangement of scenes. The application required needed to be flexible enough for me to quickly change scenes positions; just like it would be with index cards. I found the "Stickies" application (Mac) to be just right.

In Stickies, at the beginning, I created 8 notes - one for each scene. Then I started forming the game's logical arrangement for the scenes (which kept changing through the process). I needed to create somewhat of a restriction so the fairy tale will not be changed completely. Hence, Scene 1 and 8 are to remain static, so that only the remaining interim scenes can be rearranged. As I tested different scenarios, I realized that in order to always go back to the same ending of the story, I have to use a blank spot before the ending, where the sub scenes selected for that spot (I call them - special subs) will be a bit different from the other sub scenes in the game. These special sub scenes will have their ending modified rather than their beginning. I decided to merge the 7th and 8th scenes, and designate the 7th spot for these special subs.

During the game, each player can select a scene in the order they choose. It means that each of the scenes they select needs to match the adjacent scenes that comes before and after it. So the challenge I was facing was how to get each scene to match the previous and preceding one without changing the whole story. My solution was to create new notes to the possible scenes to be selected after the original scenes - we'll call them sub scenes. Each sub scene had to remain in the same family of the original scene which it is preceding. It meant that only one side of the scene can change, so that the original scene and its sub scenes will have some common denominator. As a result, I modified the beginning of each sub scene to match the ending of its original scene, and left their ending intact. So for example wherever scene 3 is placed, it'll always have the same ending.

The possibilities of creating large number of notes and modify their colors in Stickies, provided great visual assistance. The image below is the screen capture of my stickies arrangement. The static scenes are blue; the original scenes are purple; All the sub scenes behind the original are of different colors. On each of the sub scenes, the modified/added text at the beginning of the scene is a lighter blue to separate it from the original text. You can click the image for a larger/legible view.

To further clarify what all the possible combinations of scenes would be I'll draw a table:

The unique numerical values of all the scenes and sub scenes will be valuable in the programming phase. When writing Action-Script I will be able to concatenate groups of possible following scenes in "for" loops.

As I'm sitting here, trying to figure out the code I need to type, I'm realizing that another table can't be a bad thing. This one's only for the Sub scenes:

This time I enclosed the main scene numbers, within the sub scenes names, in parentheses because the sub scene (second) number is the actual scene - but modified - that is playing.

So, there are 8 spots in the main timeline. The first and the last are static, and the 7th is automatically selected, so the remaining 5 spots in between can be filled with any of the sub scene depending on the pervious spot's selection. Now I'm ready to write the general pseudo code:

• Spot 1 -
  Scene 1 (Static)
• Spot 2 -
  If player chooses scene 2 then 1-2 will play
  If player chooses scene 3 then 1-3 will play
  If player chooses scene 4 then 1-4 will play
  If player chooses scene 5 then 1-5 will play
  If player chooses scene 6 then 1-6 will play
• Spots 3 -
  
  If spot 2 ends with 2 and player chooses either scene 3, 4, 5, 6 then 2-3, 2-4, 2-5, 2-6 will play
  If spot 2 ends with 3 and player chooses either scene 2, 4, 5, 6 then 3-2, 3-4, 3-5, 3-6 will play
  If spot 2 ends with 4 and player chooses either scene 2, 3, 5, 6 then 4-2, 4-3, 4-5, 4-6 will play
  If spot 2 ends with 5 and player chooses either scene 2, 3, 4, 6 then 5-2, 5-3, 5-4, 5-6 will play
  If spot 2 ends with 6 and player chooses either scene 2, 3, 4, 5 then 6-2, 6-3, 6-4, 6-5 will play
• Spot 4 -
  If spot 3 ends with 2 and player chooses either scene 3, 4, 5, 6 then 2-3, 2-4, 2-5, 2-6 will play
  If spot 3 ends with 3 and player chooses either scene 2, 4, 5, 6 then 3-2, 3-4, 3-5, 3-6 will play
  If spot 3 ends with 4 and player chooses either scene 2, 3, 5, 6 then 4-2, 4-3, 4-5, 4-6 will play
  If spot 3 ends with 5 and player chooses either scene 2, 3, 4, 6 then 5-2, 5-3, 5-4, 5-6 will play
  If spot 3 ends with 6 and player chooses either scene 2, 3, 4, 5 then 6-2, 6-3, 6-4, 6-5 will play
• Spot 5 -
  If spot 4 ends with 2 and player chooses either scene 3, 4, 5, 6 then 2-3, 2-4, 2-5, 2-6 will play
  If spot 4 ends with 3 and player chooses either scene 2, 4, 5, 6 then 3-2, 3-4, 3-5, 3-6 will play
  If spot 4 ends with 4 and player chooses either scene 2, 3, 5, 6 then 4-2, 4-3, 4-5, 4-6 will play
  If spot 4 ends with 5 and player chooses either scene 2, 3, 4, 6 then 5-2, 5-3, 5-4, 5-6 will play
  If spot 4 ends with 6 and player chooses either scene 2, 3, 4, 5 then 6-2, 6-3, 6-4, 6-5 will play
• Spot 6 -
  If spot 5 ends with 2 and player chooses either scene 3, 4, 5, 6 then 2-3, 2-4, 2-5, 2-6 will play
  If spot 5 ends with 3 and player chooses either scene 2, 4, 5, 6 then 3-2, 3-4, 3-5, 3-6 will play
  If spot 5 ends with 4 and player chooses either scene 2, 3, 5, 6 then 4-2, 4-3, 4-5, 4-6 will play
  If spot 5 ends with 5 and player chooses either scene 2, 3, 4, 6 then 5-2, 5-3, 5-4, 5-6 will play
  If spot 5 ends with 6 and player chooses either scene 2, 3, 4, 5 then 6-2, 6-3, 6-4, 6-5 will play
• Spot 7 -
  If spot 6 ends with 2 then 7--3 will play
  If spot 6 ends with 3 then 7--4 will play
  If spot 6 ends with 4 then 7--5 will play
  If spot 6 ends with 5 then 7--6 will play
• Spot 8 -
  Scene 8

To try and make it clearer Here's a sample scenario of a game: