{V_01P}…
1. 1NTR0DUCT10N
At this juncture in my project, I am very pleased with the outcome of this successful multifaceted endeavor. My Focus for this project was to create an intriguing and unique application that would easily connect people over the internet, touching them on a fundamentally visceral level. Most important to me was the possibility of applying an arbitrary and old physical activity such as Ping-Pong, one which you might find yourself lazily indulging, in a friend’s basement on a Saturday afternoon. Taking it as such and both applying it digitally to the internet, but also adding features such as streaming video, audio and a wireless physical interface device allows this activity to become the means to bridge the gap from a common multiplayer video game to more closely resemble its real-world counterpart.
11. PR0CESS
In order to arrive at a beta version of {V_01P}… it was necessary to concentrate on building the software from its base, one iteration at a time applying layers in small increments, while sticking to a strict schedule. In my first version I had decided to apply Macromedia’s Director MX development platform using real 3D created with the Havok engine, Smoothware’s Track Them Colors Pro (TTCPro) for the physical interface mechanism and the Shockwave Multiuser Server (SMUS) to stream audio, video and provide multiplayer functionality. After two solid iterations with little forward motion, it was decided that the best course of action was triage. I had to put aside Havok due in order to research other outlets to better make use of my limited time frame.
In the next set of iterations, I decided to research Flash MX as the base game production platform that would be integrated into Director MX for color tracking and streaming video, audio. During this process, I learned that not only did the SMUS not support video or audio over a network, but it was not compatible with TTCPro. Both code functions would compete for the video source yielding zero results for this project.
After learning this, I decided that the best course of action was to find another alternative for streaming audio and video. I settled upon the new Flash Communication Server v1.5 (FlashCom). It had the capability to stream audio and video but was limited by its bandwidth and inability to buffer incoming and outgoing data, an inevitable result of inefficient programming, which would lead to lag over the server. I dedicated my time and considerable effort to create the backend functions, which would handle any and all of my client side activity with little error.
After signifigant testing with TTCPro, it was learned that it was impossible to both track color change frame to frame and stream the selfsame video over the server, due to the nature of TTCPro and its requirement to have full control over all incoming video streams. Additionally, during extensive tests, TTCPro was found to be most inappropriate for this project given its added inability to track change swiftly enough to produce favorable results in this fast paced game.
It was at this stage where I initiated the final solution to realizing my project in its optimal form. I located a gyroscopic mouse device which operated mid air and wirelessly to produce X and Y coordinates which would correctly match the variables I had applied to my paddle sprites.
111. TECHN1CAL 0VERV1EW
Utilizing FlashCom to capitalize on its strengths, I was able to implement several unique functions using both server side (backend) and client ActionScripting. One of the most helpful, was the addition of Flash Shared Objects (FSO), not entirely a new concept in traditional server/client XML Socket applications, but extremely fundamental to creating sleek purposeful multiuser Flash applications. Similar to messages sent of SMUS, the FSO function requires little programming and if implemented correctly, can be the singular feature that optimizes client applications limited by bandwidth and the lack of an sufficient buffer.
I decided it was imperative that each client was separately connected as the master and slave to each other with the only exception being the player client would enslave the ball object, thus feeding the opponent client the extremely complex math held by ball position (X, Y, Z), spin, curve, speed and physical constrictions to the SWF stage, of which graphics, and minimal code were taken from different games on the internet. Several tutorials dealing with Shared Objects offer code and non-importable SWF files, from which I reconstructed the single player game actions located here. I created one Shared Object with Flash Remoting, which holds one copy each of the math needed to control the function of each paddle, funneling its combined coordinates to the other and control a smaller “dummy” paddle serving as the reference for each player to note the location of their nemesis’ movements. It was in this manner that made it possible to maximize my time and efficiently send each object over FlashCom, effectively preparing the server to accept the large bandwidth processes of streaming video and audio.
For my purposes, it was necessary to create a single player game with AI as a base on which to build my final multiplayer game. I went out to the Flash Community and I was directed to several tutorial sites and some people who could offer assistance. From these and other forums and tutorial sites FlashKit and WebMonkey it was indicated that Gary Rosenzweig had a hand in the creation of this 3D PONG Tribute: Curveball but I had a hard time finding the primary author, to whom I want to give a great deal of credit. I had posted on one of the forums Gary moderates and he was extremely helpful getting back to me about fake 3D in Flash!!! Even with all of this help, it was extremely hard to play a game 60 times or more to learn how the physics, paddles and balls interacted. But, with some help from programmers at Northridge, Stanford and another coder, P. Reynolds, I was better able to understand how to code the correct math/physics for my own game.
One of the primary examples of new code required for a game of this type is the Flash Shared Object (FSO), which I have mentioned above and detailed below.
//-----------------------------
// create a new connection object (required for each set of //FSOs)
nc = new NetConnection();
//create the connection to the proper server application
nc.connect(“rtmp://server_name/app_name/”);
//my_so is a reference to a shared object file “my.so.fso”
//”nc.uri, true” creates a persistent dedicated connection //to the internet for the object “my_so”
my_so.getremote(“my_so”, nc.uri, true);
//connects to “my_so” through connection object (nc)
my_so.connect(nc);
//-------------------------------
This was all that was needed for everything including the A/V functionality. Although, it was required to connect for each piece that is to be shared across the server. This is a daunting task in itself. Once the server had control of each variable to attach to the connection string (rtmp) it was just a matter of applying a little tweaking to the referred object variables.
The other processes of integrating video/audio were less tedious, only more frustrating due to the inevitable lag that was created from sending FSOs, and net streams over the server, which at some points in this prototype may produce varied, but comprehensible results for Player Two's client.
1V. C0NCLUS10N AND FUTURE TH0UGHTS
In its culmination, I feel that this prototype is the best that it can be without further optimization and debugging. I am not happy with the lag. Player Two’s experience should be much smoother. But, it works and that is the important part that I was able to execute and exhibit my rather ambitious idea using many moving parts is pleasing to me.
I see future versions of this game working with a similar model, but utilizing real, instead of faked 3D with vector math.
I would really like to have this be a suite of games with videophone connectivity built in and I would really like to know more about how to start from the multiplayer perspective without having to create a single player version as a base and I predict that it will be easier to make more complex games as I perfect my ActionScript technique. It is much harder to watch previous games for motion references, than it is to already understand the math required for the code.
V. IN FUTURE VERSIONS:
I would like to add incentives to hit your opponent or bounce the ball through or at a moving target to gain power ups or points.
Also, this could be a welcome diversion to large video conferencing sessions where a CEO could sit and throw a ball at his underlings video images causing their browser window to shake or become blurry and so forth.
Additionally, the Sony Eye-Toy has not produced a game of this fashion. Although, they do have the means; a small and efficient USB webcam, a broadband adapter and a USB headset for VOIP. A similar game may be in development, but until then, I would love to see more games of this type proliferate the internet.
Special Thanks to:
Perry Hoberman for keeping me on track and correcting me when I fell by the wayside...thanks for warning me when I may have done something improper or incorrect. I really appreciate all the guidance.
Scott Fisher for meeting with me and giving your input...would this be something that would meet your standards for Telepresence?
L. Tietz for code samples and helping me reconstruct the physics of the ball and the multiplayer paddles.
P. Reynolds you are amazing, thanks for the last minute network help with Flash Communication Server. Maybe with some further optimization, you can help me make this run even smoother over the available bandwidth.
-----------------------------------
Revision Notes: On a previous version authored on 5/06/04, I used the word "ostensibly" incorrectly. I was led to believe that it meant "supposedly" or "might have." As it turns out, I was wrong and it paints a much more indistinct picture with its meaning. The previous use of the word did not match my true intention, as the reader will note in the corrected document above.
Some More Sights of Interest on the Thesis Research Trail:
Implicit Association Test: Uses your perception and cognition skills and tests your biases toward various objects and races of people.
"The Visual Cognition Lab seeks to understand human vision during complex real-world scene and face perception. Because natural human perception involves active information seeking via eye movements, much of the work in the lab focuses on human gaze control. Topics of interest include gaze control in face and scene learning and recognition, visual search in natural scenes, visual memory, and scene representation."
University College London Interaction Centre: Course Subjects
Alternative Interface Technologies
: An article by Jerry Isdale
Eye Tracking in Advanced Interface Design:
A paper by Robert J.K. Jacob
Human-Computer Interaction Lab, Naval Research Laboratory, Washington, D.C.
David Lubke a possible human resource.
Maintaining Information Awareness in a Dynamic Environment: Assessing Animation as a Communication Mechanism: Thesis Document by D. Scott McCrickard
CHI'90 Trip Report Seattle, WA, 1-5 April 1990 by Jakob Nielsen
Steady-state VEP-based Brain Computer Interface Control in an Immersive 3-D Gaming Environment