TRIVIAL.GZ:

A WEB-BASED COLLABORATIVE GAME TO

PROMOTE GALICIAN CULTURE

Miguel R. Luaces, Oscar Pedreira, Ángeles S. Places and Diego Seco

Databases Laboratory, University of A Coruña, 15071 A Coruña, Spain

Keywords:

Web application, user interface, AJAX, collaborative software, e-learning.

Abstract:

We present in this paper the architecture and some implementation details of a web-based version of a Trivial

game. Our implementation achieves such a high degree of interactivity between the players that they perceive

the game as being played real-time. More importantly, no plug-in or applet is used in the architecture of the

system. These properties are achieved by means of a carefully designed architecture that uses AJAX (Asyn-

chronous JavaScript and XML) for data exchange. Using this approach, it is possible to develop any type of

web-based collaborative software with few load on the web server. In the paper, we analyze traditional archi-

tectures for web-based applications and we show how our approach overcomes their limitations. Furthermore,

we proof the efﬁciency of our approach by means of an empirical comparison.

1 INTRODUCTION

The maturity of Internet users and the quality of con-

nections and services available are increasing the de-

mand of interactivity in web applications, not only

between the user and the system, but also between

the users themselves. However, the characteristics of

traditional web applications prevent developers from

building collaborative applications or games that re-

quire real-time interaction between the users (Paul-

son, 2005). This is due to two main reasons:

• Clients cannot Exchange Information. Connec-

tions in web applications are always established

between a client and the server, but never between

two clients. Hence, all data exchange must be

done through the server.

• A Web Server cannot Start Data Transfers. Web

servers can never communicate the information

received from one client to the others unless the

clients explicitly request it, thus restricting the in-

teraction possibilities between the clients.

As a consequence, applications where users col-

laborate or interact which each other in real-time to

perform a task have to be implemented using plug-

ins or a similar type of software for the web browser

that controls the exchange of messages between the

users. The only alternative without this type of soft-

ware is that each client requests frequent and periodic

updates from the server to retrieve the data that has

changed in any other client. However, if data change

frequently in the clients or the change has to be per-

ceived as real-time, the load in the web server will

be very high because many new pages will have to

be created and sent constantly. This results in a lim-

itation in the maximum number of users that can in-

teract. Nevertheless, this approach is better than the

previous one in the sense that users do not have to in-

stall any plug-in, which is an insuperable restriction

in application domains where users do not have the

required expertise level.

We have developed a software architecture specif-

ically designed to simulate interactivity between users

of a collaborative web application. Users perceive

their interaction as real-time, just like if they had a di-

rect connection between them. This architecture has

been used to implement a virtual version of the classic

board game Trivial Pursuit with two important advan-

tages over other applications of this type: it does not

require players to download and install any software

for the web browser, and a large number of games

with many players in each can be played simultane-

ously in an ordinary web server.

The rest of the paper is organized as follows. In

Sect. 2 the rules of Trivial.gz are described in order to

show the level of interactivity that can be reached with

this new approach of web application development.

Then, in Sect. 3, we present the differences between

the architecture of traditional web applications and

R. Luaces M., Pedreira O., S. Places Á. and Seco D. (2008).

TRIVIAL.GZ: A WEB-BASED COLLABORATIVE GAME TO PROMOTE GALICIAN CULTURE.

In Proceedings of the Fourth International Conference on Web Information Systems and Technologies, pages 67-73

DOI: 10.5220/0001524000670073

 SciTePress

the architecture we propose, and we describe AJAX

in more detail, showing its advantages for the system-

atic development of interactive web applications. Af-

ter that, we present a detailed description of the ap-

plication architecture in Sect. 4. This development al-

lowed us to evaluate and compare our approach with

respect to traditional approaches to web application

development, which is presented in in Sect. 5. Fi-

nally, Sect. 6 presents our conclusions and some ideas

for future work.

2 TRIVIAL.GZ

Trivial.gz is an initiative of the Galician Socio-

Pedagogic Association (AS-PG, from the Galician

name Asociación Socio-Pedagóxica Galega (Galician

Socio-Pedagogic Association, 2007)) to increase the

usage of Galician language on the Internet and among

the young people, and it was sponsored by the Gali-

cian government. The game was presented dur-

ing the computer party XuventudeGaliza.Net, which

took place in Santiago de Compostela in April 2006.

The game can currently be played at the web server

of the Galician Socio-Pedagogic Association (

http:

//www.as-pg.com/trivial.gz

). It currently has

more than 1500 registered users and more that 2700

questions. Figure 1 shows a screenshot of a game be-

ing played.

The main objective when the development started

was to create a web-based game similar to the Triv-

ial Pursuit board game which could be played on any

web browser without having to download any plug-in

or applet. Our version of the game has some differ-

ences with respect to the original board game in order

to get the most out of the virtual environment and to

minimize the effects caused by the players not sharing

the same physical space during the game. Moreover,

a big effort was devoted to simulate in a web page the

interaction between the players and the actions like

rolling the die, moving the tokens, watching the posi-

tions and movements of the other players, etc.

In a rough description, the goal of Trivial.gz is

answering correctly questions of three different dif-

ﬁculty levels and six different subjects: Culture and

Show Business, Geography, History, Language and

Literature, Science and Our World. All questions

have three possible answers of which only one is cor-

rect. The board is an hexagon divided into squares of

different colors, each representing one of the subjects

of the questions. When the game starts, all players

start from the central square. The player who has the

turn throws the die (by clicking on an animation of

the die rolling) and moves on the board in any direc-

tion as many squares as the number in the die. When

a square is chosen, the same question is showed to all

players who can try to answer the question before the

time ends. If the question is answered right points are

awarded to the player independently of whether the

player had the turn or not. If the player with the turn

fails the question, the turn passes to the next player.

To win the match, the player ﬁrst has to collect the six

wedges that are awarded when the question on a ver-

tex of the board is answered right. Then, the player

has to proceed to the center square and answer cor-

rectly a question from a random subject.

A detailed description of the game rules is outside

the scope of this paper. However, we think it is inter-

esting to discuss the modiﬁcations that were done to

the original rules of the game in order to improve the

experience of the players:

• The Game Board is updated in Real Time. A

player can see all the tokens, the die value, who

has the turn, and the points of each player. This

creates the sensation that the players share the

same virtual space.

• Players can Talk. A chat was added to the game

page so that players can communicate. It simu-

lates the verbal interaction between players.

• Wedges can be Lost. If a player fails the question

in one of the squares where wedges are awarded,

the player looses the wedge. This makes the game

more dynamic and enables players that are losing

to recover.

• It is Easier to Win Wedges. There is a special

square in each side of the board that moves the

token to one of the special squares. This makes

games faster.

• Everybody Plays. When the player with the turn

chooses a square, the question is presented to all

players. Everybody can try to answer the question

and points are awarded to everybody that gives the

right answer. Furthermore, it can be seen who has

already answered the question right or wrong in

order to increase the perception of playing with

more people.

• Limited Time. There is a time limit of 30 seconds

to answer for the player that has the turn. The

time for all the other players is limited to the time

required by the player with the turn. This avoids

long waits.

• Player History. The server keeps track of all the

games played, the points achieved by each player,

and the statistic of questions answered right for

each subject. This gives the game an additional

dimension because players can compete not only

WEBIST 2008 - International Conference on Web Information Systems and Technologies

Figure 1: Screenshot of the game.

to win one game, but also to be the one with

more games won, with more points, or with better

statistics.

• Solitaire Game. The game can be played by a sin-

gle player.

3 DIFFERENCES WITH

TRADITIONAL WEB

APPLICATIONS

The architecture of traditional web applications fol-

lows one of these two philosophies:

• Server-side Applications. All processing is per-

formed on the web server. Each client request im-

plies a processing time in the server and sending

a complete web page to the client. This architec-

ture is not very scalable because the number of

pages that the server has to process and send to

the clients grows with the interactivity of the ap-

plication and the number of simultaneous clients.

• Client-side Applications. In this type of architec-

ture as much processing as possible is performed

in the client, thus minimizing the information ex-

change with the server. This type of applica-

tions are usually implemented by means of web

browser plug-ins that have to be downloaded, in-

stalled and conﬁgured. Another approaches use

Java applets that require the Java Virtual Machine

to be installed and conﬁgured. In any case, this

philosophy requires some level of expertise from

the users, which limits its general use.

An intermediate approach uses scripts in the web

pages so that the client-side of the application has a

certain amount of processing capabilities without hav-

ing to install a plug-in or the Java Virtual Machine.

AJAX (Asynchronous JavaScript and XML (Garrett,

2005)) is the name of a new philosophy in the ﬁeld of

web application development. In fact, AJAX is not a

new technology but rather a combination of a number

of already existing different technologies. The cen-

tral element is the asynchronous usage of the XML-

HttpRequest API present in all web browsers of the

current generation. This allows a web page that is

being visualized at the client-side to use a script lan-

guage function to request some information from a

web server without blocking the user activity. The

web server returns the information requested using

short XML (World Wide Web Consortium, 2006)

messages and the web browser invokes a speciﬁc

script function that can process the response and mod-

ify the web page accordingly. Google has been a pi-

oneer in the use of AJAX, as can be seen in Google

Suggest, Google Maps or GMail (Google, 2007).

Figure 2 shows a sequence diagram represented

with UML that describes this behaviour. In both ﬁg-

ures a user invokes three actions in the user interface

of the web application. Figure 2(a) shows the be-

haviour in the case of traditional web applications. In

this case, the user has to wait until the action ends

before invoking the following one. Furthermore, the

processing time in the server and the amount of infor-

mation exchanged between the client and the server is

usually quite high. Figure 2(b) shows the behaviour

in the case of using AJAX. In this case users per-

ceive a higher response speed. They do not have to

wait for an action to end before invoking another ac-

tion because the data exchange is performed asyn-

chronously and long operations do not block the user

interface. Moreover, in traditional web applications

each content update requires a complete reload of the

web page, whereas in a web application using AJAX

the information in the XML message is used to re-

draw the appropriate section of the user interface. Ad-

ditionally, the processing time in the server and the

amount of information exchanged is smaller because

TRIVIAL.GZ: A WEB-BASED COLLABORATIVE GAME TO PROMOTE GALICIAN CULTURE

(a) Traditional web application (b) AJAX web application

Figure 2: Client-server interaction in different application models.

the server does not have to create and trasfer complete

web pages, but only short XML messages.

Furthermore, given that the processing time in the

server and the amount of information exchanged be-

tween the server and the clients is reduced, AJAX-

based web applications can include more interactiv-

ity than traditional applications because the remaining

processing time and bandwidth can be used to handle

a higher number of simultaneous requests.

A number of development tools have appeared

around AJAX to make its usage more easy. One of

them is Direct Web Remoting (DWR) (Direct Web Re-

moting (DWR), 2007). This open source library has

two advantages over the direct use of AJAX. First, it

enables the JavaScript code in the client-side to use

transparently Java classes in the server-side. That is,

it enables the developer to use AJAX in a similar way

to CORBA or RPC. This is achieved by dynamically

generating JavaScript code that encapsulates AJAX-

based calls to the Java classes in the server. The sec-

ond advantage is that DWR provides the developer

with a number of tools to make easier the update of

the web page contents in the client-side.

These two technologies are the center of the ar-

chitecture of our application. However, they do not

solve the problem of creating web applications that

allow users to interact in real time. Even though it

speeds up data exchange between the server and the

clients, it does not change the architecture of web ap-

plications. That is, data exchange is still performed

between the clients and the server and never between

clients, and the server still cannot take the initiative of

sending the data it has just received from a client to

the other ones.

In order to achieve a high degree of interactiv-

ity between the users, in our architecture each client

issues frecuent periodical requests to the server and

receives the relevant information regarding the state

of the game and the other players, which is used to

change the user interface accordingly. To keep track

of the current state of the game, the server implements

a state-machine that is controlled with the information

sent by the player that has the turn. Requests to the

server can be issued more in response to some actions

of the player (such as throwing the dice or answering

a question).

This approach cannot be implemented with the

traditional architecture of web applications because

the amount of information that had to be exchanged

between the server and the clients is too high. In

order to minimize the processing time in the server

and the trafﬁc between the clients and the server, we

use AJAX for the communication between the clients

and the server. By exchanging information by means

of short XML messages, AJAX frees the web server

from the creation of complete web pages when the

clients requests arrive. Furthermore, the logic of the

application is split between the client and the server in

such a way that the processing time in the server and

the trafﬁc between the server and the clients is mini-

mized. Finally, the functionality in the client-side can

be implemented using only JavaScript, thus no special

software has to be downloaded or installed.

4 DETAILED SYSTEM

ARCHITECTURE

Figure 3 presents a general view on the architecture of

the application. Just like in any web application, one

can ﬁnd two different parts: the server-side module

of the application that runs in a web server and it is

WEBIST 2008 - International Conference on Web Information Systems and Technologies

implemented using Java Server Pages (JSP), and the

client-side module that runs in the web browser of the

client and it is implemented using JavaScript and dy-

namic HTML. There is a part of the application that

deals with functionality such as user registration, con-

ﬁguration of lists of friends, or querying and browsing

statistics of the players, which is implemented as an

ordinary web application whose description is out of

the scope of this paper. Instead, we will focus on the

description of the game control and the simulation of

real-time interactivity.

There are two different types of players in the

game: the one that currently has the turn, and all the

others. The ﬁrst one has the control of the game and

generates events that produce the update of the game

state (e.g., rolling the die, choosing the square, or an-

swering the question). The other players only gen-

erate an event when they answer the question. The

server controls each game being played by means of

a state-machine. During the game, the server goes

through the states according to the actions invoked by

the player that has the turn. The other players do not

have any effect on the state-machine, they just query

the server periodically to retrieve the current state of

the game in order to update their user interface.

Figure 3: Application architecture.

The states in the state-machine of the server are

the following:

• Initial State. Just before the player that has the

turn rolls the die. There is no information to be

sent to the other players.

• Dice Thrown. The player with the turn rolls the

die and gets a number. The other players receive

this number when they request the game state in

order to update their user interface.

• Square Chosen. The player with the turn chooses

a square to move and receives a query for that

square that is selected randomly by the server.

The rest of the players receive the square selected

and the question when they request the game state.

• Answering a Question. Whenever a player with-

out the turn answers a question, the server updates

the points of that player and informs the other

players of the result. Therefore, all the other play-

ers can now whether one player has answered the

question right or wrong. When the player with the

turn answers the question, the time for answering

ends. If the player gave a wrong answer, the turn

passes to the following player.

Internally, the server-side module keeps a list of

the games that are being played at any given time.

Each game consists of a list of players and a list

of questions ready to be sent to the players. For

each player, the server keeps in memory the points

achieved, the wedges won, and the statistic of ques-

tions answered right for each subject. The list of

questions acts like a memory cache to reduce the fre-

quency of database accesses. Hence, instead of issu-

ing a query to the database each time a question is

needed, there is only one database access to retrieve a

set of questions that are used during the game. Only

when all the questions are used a new database access

is performed.

The client-side modules consists of a Dynamic

HTML page with JavaScript code. Its operation is

based on a JavaScript timer that requests the game

state every four seconds and updates the user interface

accordingly. When the user invokes actions on the

user interface, the JavaScript code informs the server

of the event and modiﬁes the user interface with the

information retrieved. The time between updates can

be easily conﬁgured. A longer time reduces the real-

time perception of the game but allows for a longer

number of simultaneous games in the server. On the

other hand, a shorter time improves the real-time per-

ception but requires more computing power on the

server side. The time that is currently being used has

been empirically chosen to achieve a real-time per-

ception of the game while using an average computer

as the web server.

Figure 4 shows the development of a game turn.

The numbers in the ﬁgure match the following enu-

meration and represent a temporal-ordering of the

event sequence. First, the JavaScript timer determines

the moment to request information from the server

(1). After that, a JavaScript function in the client-

side module that requests the current game state from

the server is invoked (2). The server receives the

request and delegates its fulﬁllment in the business

model (3). The business model implements the state-

machine that controls the game and computes the in-

formation to be answered according to the current

TRIVIAL.GZ: A WEB-BASED COLLABORATIVE GAME TO PROMOTE GALICIAN CULTURE

Figure 4: Communication protocol.

state and the current event (4). Then, the server re-

sponse is encapsulated and sent to the client. An ob-

ject is built with the information retrieved from the

business model and sent to the client (5). The client

receives the response, extracts the information from

the object, and uses the information to update the user

interface content (6). Finally, a new turn starts by

showing the animated picture that represents the die

(7).

5 EXPERIMENTAL EVALUATION

The Trivial.gz is installed in a 3.2 Ghz Pentium IV

with one gigabyte RAM. During its presentation at the

XuventudeGaliza.Net party, the web server received

almost a million hits (web server requests) and more

than 600 visits (deﬁned as a set of consecutive hits

originating from the same computer). Most of the re-

quests were concentrated in the hour when a Trivial.gz

competition took place. More than 200 players com-

peted to achieve more points than the rest. During this

hour, more than 800 games were played with an av-

erage of three players per game. Exactly 776 games

were played completely. The games that did not end

because all the players left the board were not regis-

tered.

Table 1 shows some ﬁgures regarding the amount

of information transferred by the web server execut-

ing Trivial.gz and a comparison to the amount of in-

formation transferred if the application were built us-

ing a traditional web architecture.

The HTML code of the web page occupies 35

kilobytes without taking into account neither the im-

ages nor the JavaScript code that sends the messages

to the server using DWR. On the other hand, the DWR

object that the web server sends to each client oc-

cupies 313 bytes, i.e. 0.31 kilobytes. As it was ex-

plained in Sect. 4, the game information must be up-

dated by each client frequently in order to achieve a

real time perception of the game. If we consider an

update time of 4 seconds, just like it is currently con-

ﬁgured in the application, a traditional web applica-

tion would require the web server to send the 35 KB

of the web page 15 times per minute. This means a

total of 525 KB per minute and player, whereas with

Trivial.gz this amount of information is reduced to 4.7

KB per minute and player.

We can suppose that 100 games with an average

of three players were played during 10 minutes in

the party where the Trivial.gz was presented. In fact,

more than 800 games were played in an hour, so our

supposition is quite conservative. Considering this ac-

tivity, 1.5 Gigabytes of information would be trans-

ferred through the network in a traditional web ap-

plication, whereas only 14 Megabytes were sent in

Trivial.gz. This represents that a traditional web ap-

plication requires 107 times more space for the same

information. As a consequence of this amount of in-

formation, a traditional web application would require

a bandwidth of 2.56 MBytes/s in the best case (as-

suming that the trafﬁc distribution is uniform). How-

ever, Trivial.gz only needed a bandwidth of 23.50

KBytes/s.

6 CONCLUSIONS AND FUTURE

WORK

We have presented in this paper the architecture of a

web application that implements a trivial-like game

WEBIST 2008 - International Conference on Web Information Systems and Technologies

Table 1: Empirical data.

Traditional Application Trivial.gz

1 message, 1 game, 1 player 35 KBytes 0.31 KBytes

1 game, 1 minute, 3 players 1575 KBytes 14.1 KBytes

100 games, 10 minutes, 3 players 1538.09 MBytes 13.77 MBytes

Network trafﬁc during these 10 minutes 2.56 MBytes/s 23.50 KBytes/s

where players can follow the game in real time. This

was achieved without using any plug-in or applet,

which means that the game can be played in almost

any computer without the common problems associ-

ated to the instalation of these components.

We have described how the AJAX philosophy is

used in the implementation for the data exchange

between the server and the clients. Moreover, the

message exchange protocol designed for Trivial.gz

and a general architecture for collaborative web ap-

plications are also described. These three improve-

ments over traditional web applications minimize the

amount of information that has to be transferred be-

tween the clients and the server. We believe that this

approach can be used to develop any type of collab-

orative software using a web application with a small

load on the web server.

Finally, we have performed an empirical compari-

son between Trivial.gz and a web application based

on a traditional web application architecture. This

comparison shows the advantages of using our archi-

tecture in terms of network bandwith and processing

capabilities of the web server.

The application has been a success. The game has

a solid player base and it is being used to promote

the use of the Galician language among young peo-

ple. New questions are submitted by player regularly

and a board version of the game is being developed.

As lines of future work, we are currently working on

the improvement of Trivial.gz to allow games with a

larger number of players. Another improvement that

is currently being implemented is the adaptation of

the application to make it completely conﬁgurable by

the ﬁnal users. When this is achieved, any user will

be able to install the application, decide the subjects,

and deﬁne the questions. A possible ﬁeld where this

application can be used is in education with teachers

conﬁguring Trivial.gz games with the questions of the

lessons they teach in the classroom.

A different line of future work is the study of the

requirements of other types of collaborative web ap-

plications, such as distance education or collabora-

tive work, and the adaptations that the architecture

requires. In this sense, a web-based version of the

popular game Scrabble is being developed with the

same goals in mind.

ACKNOWLEDGEMENTS

This work has been partially supported by “Minis-

terio de Educación y Ciencia” (PGE y FEDER) ref.

TIN2006-16071-C03-03, by “Xunta de Galicia” ref.

PGIDIT05SIN10502PR and ref. 2006/4, by “Minis-

terio de Educación y Ciencia" ref. AP-2006-03214

(FPU Program) for Oscar Pedreira, and by “Dirección

Xeral de Ordenación e Calidade do Sistema Universi-

tario de Galicia, da Consellería de Educación e Or-

denación Universitaria-Xunta de Galicia” for Diego

Seco.

REFERENCES

Direct Web Remoting (DWR) (2007). Web Site. Retrieved

from http://getahead.org/dwr in October 2007.

Galician Socio-Pedagogic Association (2007). Web Site.

Retrieved from http://www.as-pg.com/ in October

2007.

Garrett, J. (2005). Ajax: A New Approach

to Web Applications. Retrieved from

http://www.adaptivepath.com/publications/essays/

archives/000385.php in October 2007.

Google (2007). Google Tools Web Site. Retrieved

from http://www.google.com/intl/en/options/ in Octo-

ber 2007.

Paulson, L. D. (2005). Building rich web applications with

ajax. IEEE Computer, 38(10):14–17.

World Wide Web Consortium (2006). Extensi-

ble Markup Language (XML). Retrieved from

http://www.w3.org/XML/ in October 2007.

TRIVIAL.GZ: A WEB-BASED COLLABORATIVE GAME TO PROMOTE GALICIAN CULTURE