Gamasutra: The Art & Business of Making Gamesspacer
Carry Small, Game Large: Big Shared Screen Multiplayer Gaming
arrowPress Releases
October 31, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Carry Small, Game Large: Big Shared Screen Multiplayer Gaming

May 6, 2008 Article Start Page 1 of 4 Next

Do portable games have to be small? What if multiple players were in the same physical space, all looking at one large shared screen? What if each player controlled his avatar through a laptop or a hand-held device with all the action visible on the big screen?

We decided to find out. Therefore, we built a prototype framework to test out this new gameplay model. We learned this new model is quite fun and not difficult to implement, or even add to existing games. We're giving away the framework and game code and encourage you to try it as well.

As part of an Intel team looking to push the limits of gaming, we decided to challenge the notion that games on small devices had to be small games. Instead, we set out to see what a "carry small, game large" framework might look like if we assumed:

  • The game clients will be mobile internet devices or small-form factor PCs connected to the internet.
  • The game is multiplayer -- we believe that most gaming is best done together.
  • The game framework should gracefully deal with groups of people as they gather and disperse. This means no installation of game software on game clients.
  • All players had access to a common, large, shared screen.
  • The supported games were not "twitch" games. While much of the responsiveness of the framework varies with network speed, the framework itself introduces some delay unsuitable for twitch games.

The result is a game framework on top of which we produced two games: a tanks game shown in Figure 1, and also a multiplayer jigsaw puzzle.

Figure 1 - (left) A client screen suitable for a small-form factor PC and (right) the large shared screen of the game.

How and where would this new game play model be used?

The last assumption we made -- a shared screen -- is as intriguing as it is unorthodox. Requiring all game participants to be physically co-located restricts where this new game model can be used. We envision this game model being used in coffee shops, malls, theatres, conventions, and more. We also see this used in bars, where today group games are sometimes played, but with proprietary controllers as opposed to any internet-capable device.

While the shared screen assumption is restricting, it also frees the game designer to leverage the myriad of human-to-human communications. Because people can all see the same screen, they all can see and hear each other. When we tried playing this way with groups, they were able to strategize and laugh with one another because they we co-located. We also found the in-game taunting was good spirited -- nothing like a lack of anonymity to suppress some of the uglier side of multiplayer gaming.

Game Framework

Our usage model expects players to join and leave the game quickly and easily. To achieve this, we looked at the structure of web applications as our inspiration. Web applications place few software requirements on clients because they run inside a web browser. We decided to follow a similar model by implementing our usage model to run inside a web browser. This way the only requirement on the client is to have a modern graphical web browser.

To play the game, a player opens up a browser and goes to the game's URL, enters their name, and then their character appears on the big screen. Players are assigned a unique name and icon to keep track of their input and score. Players control their avatar using controls in the browser on their portable device. Players' input is transferred asynchronously using JavaScript/AJAX from the player's screen to a server database.

On the server side, we use well-known web technologies such as a web server, PHP, JavaScript/AJAX, and a relational database. The shared screen, which happens to also run in a web browser, is updated by new players' input found in the database. The database is used as a shared, synchronized, queue for players' input and to keep track of the current game instance. The current game instance is identified by a unique identifier that is saved in the database and is used to notify players of game restarts. When the saved game identifier changes, the database is updated and players automatically join the new game.

In all, the structure consists of two main components that we call a game client and a game server. The game client includes the players' interface to the game. The game server is made up of the UI that displays the playing field and the code that retrieves players' input from the database. The whole game is a variation of the producer-consumer problem. The players are the producers, the game is the consumer, and the database acts as the shared buffer. In our case, the database system takes care of the synchronization issues in the producer-consumer problem. This framework is illustrated in Figure 2.

Figure 2 - The main components of the game framework.

Article Start Page 1 of 4 Next

Related Jobs

InnoGames GmbH
InnoGames GmbH — Hamburg, Germany

Mobile Developer C++ (m/f)
Activision Publishing
Activision Publishing — Santa Monica, California, United States

Tools Programmer-Central Team
Amazon — Seattle, Washington, United States

Sr. Software Development Engineer - Game Publishing
Intel — Folsom, California, United States

Senior Graphics Software Engineer


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

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?



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 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. :)


Grey Havoc
profile image

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 . 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?


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 ? 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.