|
Distributed Streaming Flash Game Client
"If it were possible to utilize the wasted resources of a customer's PC while they were playing the game and reutilize the wasted resources as an actual development and processing background, how would this be best accomplished?"
Introducing the Distributed Streaming Flash Game Client -- a self-guiding Adobe/Macromedia Flash front-end with a 100% Java-based XML parsing gateway that combines the look and functionality of a streaming game client with a background processing system for handling distributed data packages. The distributed game client and its processing system will allow cross-system porting, thus able to run on Windows, Linux, Solaris and MacOS X operating systems.
Game Client Introduction
The game client front-end would be running under Adobe/Macromedia Flash MX while a Java XML parser/de-parsing 'bridge' environment would be found on the game server. The customer would initalize Flash program (interface) that would connect to a Java subprocess gateway daemon on the game server. The Java daemon acts as a telnet socket interface and a XML parser/deparser and a MySQL database interface for querying and updating data as needed. The gateway would check the customer's client version and make any upgrades and changes to bring it up to the latest release level. Then the gateway would retrieve the customer's profile from the database and build a set of client 'keys' and store them back into the customer's profile. Upon established connection, the gateway would review the client 'keys' and compare them to the account database. If the account was available and up to subscription par, the gateway would then point the client to the correct game server listening port and allow game play to commence.Distributed Client Project Interface
The second part of the interface will be based on a distributed project application. While the game client is actively running on the customer's system, a special message Java-based parsing interface (MPI) will be executed. The MPI part of the interface will communicate through the Java gateway to the distributed listening module on the game server and gather information about the customer's system for producing a unique 'data key' and 'data package' from the project database. The server will then 'update' the client, sending the data key and its package to be processed. When the MPI has finished with the data package, a 'solved' package and the data key will be uploaded back to the distributed listening module, thus updating the project database with the completed results. Then the process starts all over again. While the game client is actively being utilized by the customer, the MPI processes will continue to run. This is similar to the Distributed.net and Seti@Home projects, however only running while the game client is active.Mission Outcome
It's a win-win mission; our providers (customers) can play all the hosted games worlds we have to offer while allowing their systems to generate and solve data packages for unused computer time that normally would go to waste; and sponsors (organizations, laboratories, teaching centers, and businesses) can access more background processing power than they've ever had before, thus reducing overhead and saving power, resources, time, and money.Source Code
License Type: Common Public License, Version 1.0
Project Website: http://sourceforge.net/projects/dsfgc/
CVS Repository: http://dsfgc.cvs.sourceforge.net/dsfgc/DSFGC/
Client Design Aspects
The original design of the Distributed Streaming Flash Game Client (DSFGC) was developed for an online, text-based game called Realm of the Magi (ran from 1997 to 2006). This game was developed under the infamous LPC programming language created by Lars Penji. The original game was only connectable through telnet and limited to a number of Internet-based operating systems, thus became the base of the DSFGC and its creation point.
Since the inception of distributed clients for processing mathmatical and chemical equations during only idle CPU times, we paused and came up with a way to allow the processing to continue, but rather than wait for an idle session to start only, our processing would take place when the game client was actively being utilized. This would allow the game client to function normally, while in the background processing small blocks of data and passing it back through the secure game client data line back to the hosting server.
