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