Contents
Carry Small, Game Large: Big Shared Screen Multiplayer Gaming
 
 
Printer-Friendly VersionPrinter-Friendly Version
 
Latest News
spacer View All spacer
 
November 22, 2009
 
Video Game Watchdog National Institute On Media And The Family Shutting Down [11]
 
Modern Warfare 2 Infinity Ward's 'Most Successful PC Version' Yet [12]
 
New Tech, Design Details Of Project Natal To Emerge At Gamefest In February
spacer
Latest Jobs
spacer View All     Post a Job     RSS spacer
 
November 22, 2009
 
Sucker Punch Productions
Character Artist
 
Sucker Punch Productions
3D Environment Artist
 
Sucker Punch Productions
Network Programmer
 
Sucker Punch Productions
Texture Artist
 
Sony Online Entertainment
Brand Manager
 
Monolith Productions
Sr. Software Engineer, Engine - Monolith Productions - #113767
 
Crystal Dynamics
Sr. Level Designer
 
Gargantuan Studios
Lead World Designer
spacer
Latest Features
spacer View All spacer
 
November 22, 2009
 
arrow Upping The Craft: Susan O'Connor On Games Writing [6]
 
arrow Small Developers: Minimizing Risks in Large Productions - Part II [6]
 
arrow iPhone Piracy: The Inside Story [48]
 
arrow And Yet It Grows: Analyzing the Size and Growth of the European Game Market [5]
 
arrow NPD: Behind the Numbers, October 2009 [13]
 
arrow Reflecting On Uncharted 2: How They Did It [5]
 
arrow Sponsored Feature: Rasterization on Larrabee -- Adaptive Rasterization Helps Boost Efficiency
 
arrow Postmortem: Wadjet Eye's The Blackwell Convergence [2]
spacer
Latest Blogs
spacer View All     Post     RSS spacer
 
November 22, 2009
 
Accepting the Inherent Value of Games
 
Planckogenesis, Part II: Song Structure & Gravy Train [1]
 
Designing Games Is About Matching Personalities [1]
spacer
About
spacer News Director:
Leigh Alexander
Features Director:
Christian Nutt
Editor At Large:
Chris Remo
Advertising:
John 'Malik' Watson
Recruitment/Education:
Gina Gross
 
Features
  Carry Small, Game Large: Big Shared Screen Multiplayer Gaming
by Omar Rodriguez, Erik J. Johnson, Scott Crabtree, Brad Werth
9 comments
Share RSS
 
 
May 6, 2008 Article Start Previous Page 2 of 4 Next
 

Game Client

Although the game is displayed on the big screen, players interact with their local game client. The game client provides the players with the form they use to create their character. Once the player is logged in, the JavaScript code executing within the game client's browser intercepts input in the form of keystrokes or clicks of buttons found on screen.

The input is passed asynchronously using AJAX to the server side code (PHP) that places it into the database. As mentioned previously, the game client framework requires a web browser that supports JavaScript and creation of asynchronous objects.

Advertisement
Besides processing player input, the game client is in charge of player creation and destruction. Player creation internally creates a unique, session-based player ID that is used in the game to track corresponding player input -- each AJAX call and each entry in the database contains the player's unique ID.

In addition, the game client receives notification of game restarts. When such a notification is received, the game-specific code is expected to take the appropriate actions (e.g., joining the new game or providing the user with the initial screen to create a new player).

Figure 3. Flow of players' input into database.

Game Server

The complement to the game client framework is the game server. The game server consists of the game UI and the server code that retrieves player input from the database. While the game server code operates much like the game client code, only in reverse, the main hurdle to overcome with the game server was processing user input and updating the game shared screen with minimal delay.

In web applications, a common way to retrieve updates from the server using AJAX is to poll the server on a set interval. In our case, we had to create an environment where the players' input would seem to flow directly from the players' side to the shared game view as quickly as possible. Using an asynchronous call to poll the server would be inefficient because the asynchronous object is created each time we make a call to the server.

Instead, we put a small twist on the asynchronous call to make better use of the existing object. An asynchronous object goes through five states when making a call to the server, results are processed on the last state, and the object is destroyed. In our case, we created collaboration between the server script and the asynchronous object to retrieve results continuously.

On the server side, we created a script that retrieves players' input in a loop and flushes its output buffer on each iteration. Flushing the output buffer makes the current results available to the asynchronous object without waiting until it reaches its last state. Once the server side loop is done, the asynchronous object changes to its last and complete state where it does nothing more than destroy and recreate the asynchronous object. With this setup, we are able to simulate multiple calls to the server in order to retrieve players' input with a single asynchronous object.

Another major function of the game server is to maintain the game instance. The game server deals with game creation and destruction. The game instance identifier used by players is created by the game server and made available to players via the database. In addition, the game server processes the players' input after retrieving it from the database.

 
Article Start Previous Page 2 of 4 Next
 
Comments

Jeremy Alessi
profile image
A great look at the future of gaming. With cell phone projectors any wall could become the shared display allowing impromptu Wii style play sessions anytime anywhere. Sweet article!

Steven An
profile image
Awesome ideas. This could solve the "not enough controllers" problem!

Dj Arcas
profile image
Bindun!

http://video.google.com/videoplay?docid=-1651221202388387390

ProjectorGames has been almost exactly the same idea for some 5 years now - and we're for hire ;-)

Scott Crabtree
profile image
Dj Arcas, thanks for letting us know.

It's hard to tell from the video, but it looks like you have multiple XBox controllers hooked up to a USB hub, is that right? If so, I would say the ability to use any Internet capable device as a controller is an important difference (along with the fact that we're giving away code).

However, I wish we had known about your work while we were working on this article. I'm still interested in comparing notes & sharing work. Is there any place we can learn more about the technology behind your work?

Thanks,
--Scott

Dj Arcas
profile image
I'm almost suprised you've not heard of us... we worked closely with Intel at a number of events, including Bloodlines and the Viiv launch, although I'm sorry to say that the current PG rig runs an AMD ;)

We've tried a number of different ways of getting people's input up to the main screen, including DS, PSP, mobile phones + bluetooth. Internet-enabled devices isn't something we tried, simply because people almost never have these at LANs (or they have massive alienware laptops that will singe their laps)

As for technology, well, the PG system is a custom game engine, built around a DirectX renderer, and has support for lots of abstract controllers, player naming, cross-event scoringkeeping, but there's nothing overly original there - all the cool stuff's in the game design. Feel free to grab me at djarcas@hotmail.com if you'd like to ask anything else tho.

Did I mention we were for hire for lan parties and corporate events? ;-)

Scott Crabtree
profile image
Hey DJ, As far as not hearing about you previously...That's been the biggest adjustment for me switching from small game companies to Intel. Intel is >80,000 people worldwide, so sometimes we don't all know what each other is up to.

I think we have a great pairing here. You say "all the cool stuff's in the game design" and we know our games are nothing special...indeed the games we created are just to show the usage model and the technology we used to hook it all together.

With more and more "mobile Internet devices" in the world every day, at some point it might be worth you checking out putting your games on our code (which we're giving away).

And I'll definitely keep you in mind for parties and corporate events. :)
--Scott

Grey Havoc
profile image
Hey,

I'm trying to get this to work, but I keep getting an error that says that the MDB2.php file was not found and then it gives me a fatal error. I have it uploaded at www.brandonbarnes.us/game/index.php . I noticed in the readme that it required Apache 2, but my server is only running 1.3.41. Could this be the problem, or am I totally wrong?

Thanks!

Omar Rodriguez
profile image
Hi Grey,

The reason the README file lists Apache 2 as a requirement is because I had Apache 2 installed when developing this project. I would say it couldn't hurt to try it on Apache 2 if you can. However, the error you are getting seems to be related to the MDB2 PEAR package. What version of MDB2 do you have installed? I used version 2.4.0.

Thanks for trying it out...I would like to help you get this working.

Grey Havoc
profile image
Hey Omar,

Can you shoot me an email at freelance.brandon@yahoo.com ? I would love to get this working.

I've got the MDB2 PEAR package installed, but it still doesn't recognize it, so I'm wondering what else it could be.

Thanks!


none
 
Comment:
 


Submit Comment