Design and Implementation of a Graph-based Game

Design and Implementation of a Graph-based Game

[MAIAR API]

Frank [email protected]

ABSTRACTMany problems are naturally modelled using graphs and di-graphs, and data structures implementing the graph or thedigraph ADT are commonly used throughout computer sci-ence. Besides the network applications, graphs and digraphsserve as natural models for a host of other applications andthis motivation lead us use it to model the world map of theMaiar Game. Graph played an important role in defining thenotion of our world map. This paper discusses the interest ofexplicit software process models for (1) process understand-ing and communication, (2) process reuse, and improvement.The considered architecture include asynchronous commu-nication mechanisms, which are modeled in the Java-basedMaiar API and achieved by message exchanges.

Categories and Subject DescriptorsH.4 [Software]: Distributed Systems; D.2.8 [Software Ecosystems]: API development—Java

General TermsDesign, Graph Theory

KeywordsXML; P2P; XML Parsing; Domain Object Models;

1. INTRODUCTIONCurrently there is a new and highly interesting paradigm forcommunication on the internet, known as P2P. Peer-to-Peer(P2P) is simply a system with a completely decentralizedself-organization and resource usage. P2P mechanisms canbe used to access any kind of distributed resources and mayoffer any new internet-based applications mostly in the areaof gaming [14]. This model offers adequate formal basis todeal with the reliable design of distributed system. It has be-come important that for internet-based applications, issuesof scalability, performance, security, flexibility and qualityof service needs to be taken care of. These requirements

are some good benefits which P2P offers in the main archi-tecture of P2P systems. In order to share resources, peersin Maiar interact directly with each through the exchangeof messages. Peers directly access and exchange the shareresources they utilize in without a centralized service. InFigure 1, a peer is a basically a Maiar Game Player withshared resources with other peers and the server is a repre-sentation of a virtual peer for cross subnet communicationover the internet. A framework called shoal1 based on thetechnology, JXTA [8] used in the design of our Peer-to-PeerGame System has the notion that for cross subnet commu-nication like the internet there need to exist a virtual list ofhosts which will be used to route all messages to other peersover the internet. In order to achieve that we introduce apeer called Server which is logically another peer with thesame shared resource as the other peers, Maiar Player-Peer.The Server is a Web Server precisely Tomcat [16] and thiswill enable the application to continue working once Tomcatis up and running. Figure 1 shows the details of our peer-to-peer network setup scenario.The rest of paper is organized as follows: In Section 2, wewill discuss the formal notion of a graph, defintions and abrief background necessary for our work. Section 3 gives thegraph representation of our game world, the overall overviewof the Maiar API with detail explanation of the 5 compo-nents. An introductory material and the design principlesof each of the major 5 components are provided. The archi-tecture of Maiar will be accessed on how it provides somemajor software quality attributes in Section 4. Finally, Sec-tion 6 concludes this paper.

2. MODEL AND BACKGROUNDWe model our distributed system as an asynchronous message-passing system without a shared memory or a global clock.Furthermore, at application level, a process at any processor(peer) may send message to any other processor. Graph [1]played an important role in defining the notion of our worldmap. The topology of our world map can be viewed as undi-rected graph in which vertices (nodes) represent the roomsand the edges represent the playable movements betweennodes. We will introduce some formal notions of graph.

1Shoal is a java based scalable dynamic clustering frameworkthat provides infrastructure to build fault tolerance, reliabil-ity and availability. The framework can be plugged into anyproduct needing clustering and related distributed systemscapabilities without tightly binding to a specific communi-cations infrastructure. https://shoal.dev.java.net/.

Figure 1: Peer-to-Peer communication model.

Definition 1. A graph G= (V, E) is a set V= V(G) callednodes(vertices), together with a set E= E(G) called egdes,such that an edge is an unordered pair of vertices.

A edge {e, e} is called a loop. All nodes in the world graphare mapped to vertices in G. The edge set E contains allcommunication links between two nodes, each uniquely iden-tified by an assigned integer. Each processor keeps a localstate of the distributed cache. When a message is beingreceived, it’s added to the appropriate history and the mes-sage adapters notify the listeners of a change in state. Thesnapshot is cloneable, serializable and thus can be loadedfrom the local processor’s disk at runtime. According to [5],recording the entire message history makes the applicationunscalable so we choose to record messages of relevant typeand content. The distributed cache is assumed to have infi-nite buffer and to be error-free.A distributed cache is a tuple of (CH , LH , NH , FH , UH ,CAH) where CH is the chatHistory, LH is the locationHis-tory, NH is the newUserHistory, FH is the fightHistory, UH

is the userLocationHistory and CAH is the cacheUpdateHis-tory. Despite our approach, [5] proposed three algorithmswith different characteristics that make them much morescalable. Their algorithm is based on grid, tree and central-ized models. We will not exhaust the differences of thesealgorithms here so see paper for much details.

Definition 2. A distributed program consists of a set of Nprocesses denoted by P= {P1, P2, P3,....,PN} and a set ofunidirectional channels.

The set of processes in the application is P= {cacheUpdate,Chat, Location, NewUser, Fight}. A process p ∈ P is athread-callback behavior that receives notification of mes-sages and updates state of the recipient peer’s distributedcache ,and deliver message to the onStateChange methodof all registered listeners. An event [4] is a detectable con-dition that can trigger a notification. A notification is anevent-triggered signal sent to a run-time–defined recipient.

3. THE MAIAR ARCHITECTUREIn this section, we will start with the representation of worldand discussion of the major components of the Maiar APIwith concise reasons of choice of technology. The API iscomprised of a number of components, specialized for a spe-cific purpose. Layers and domain objects are applied to thedesign of Angels and Demons game to introduce a clear iden-tification and modular separation of all baseline architectureelements in both their responsibilities and core usage rela-tionships. As such vertical and horizontal decomposition of

Figure 2: A Logical View of the Maiar Architecture.

the game’s functionality is realized using Apache Maven [10].Figure 2 depicts the logical layer of the Maiar Architectureand Figure 3 shows the components and connectors of theMaiar API.

3.1 World RepresentationIn this section, we will have a look at our algorithm for theXMLtoObject parser and the structure of our XML [3], [15]document.

3.1.1 XML Structure of the World.The xml structure of the world is defined with a DTD schema.The elements used in the representation of the World are asfollows:map: The map element is the root element of the worldrepresentation. It contains a rooms element and a globalelement. The rooms element contains room-specific com-mands, where the global element contains globally availablecommands.

<!ELEMENT map (exit|global|rooms|entry)*>

<!ATTLIST map

name CDATA #IMPLIED>

rooms: The rooms element acts as a container for a seriesof room elements.

<!ELEMENT rooms (room)*>

<!ELEMENT room (commands| directions| items

| look| intro)*>

<!ATTLIST room

id CDATA #IMPLIED


intro: The intro element has a message attribute that holdsa short description of the room which appears whenever aplayer moves into that room.

<!ELEMENT intro EMPTY>

<!ATTLIST intro

message CDATA #IMPLIED>

look: The look element contains a more detailed descriptionof the room in its description attribute. This description isused when a player enters the look command in a room.

<!ELEMENT look EMPTY>

<!ATTLIST look

description CDATA #IMPLIED>

items: The items element is a container for item elements.

<!ELEMENT items (item)*>

<!ELEMENT item EMPTY>

<!ATTLIST item


directions: The directions element contains at most fourspecial elements, each for each direction an exit is available.north/south/east/west: These direction elements eachhave an attribute roomId which contains an integer showingwhich room is connected in that direction.

<!ELEMENT directions (north|south|west|east)*>

<!ELEMENT east EMPTY>

<!ATTLIST east

roomId CDATA #IMPLIED>

<!ELEMENT west EMPTY>

<!ATTLIST west


<!ELEMENT south EMPTY>

<!ATTLIST south


<!ELEMENT north EMPTY>

<!ATTLIST north


commands: The commands element, contains a list of com-mand elements, representing the commands which are avail-able in the room.command: Each command element represents a commandwhich is available in the room. It has a name attributewhich shows what string maps to the effects of that com-mand. Each command element must contain exactly oneaction element.action: An action element, can be one of two types. It caneither hold a requirement element or a list of effect elements.The action element can be thought of as a binary tree ele-ment. An action which contains a requirement element canbe seen as a tree element, while an action containing a listof effect elements can be seen as a leaf element.requirement: The requirement element is a element whichcontains a satisfied and a notSatisfied element. It also hastwo attributes, the first being the parameter attribute andthe second being the value attribute.The parameter attribute can be one of the following:inventory: This is used when the existence of an item inthe inventory is required.activeQuests: This is used when there needs to be a checkon whether a quest is currently active.finishedQuests: This is used where a check on whether aquest has been finished.

fraction: The fraction value is used when a response de-pends on the player’s fraction. The value attribute can beany string as long as it is used consistently in other com-mands. This is the case in inventory, activeQuests and fin-ishedQuests, where values that correspond to fraction shouldbe one of angel or demon.satisfied: The satisfied element holds an action elementwhich is accessed when the condition in the parent require-ment element is satisfied.notSatisfied: On the other hand, the notSatisfied elementcontains an action which is accessed when the parent re-quirement element’s condition is not satisfied.effect: The effect element is the most important part ofthe commands, because they are the means of changing theplayer state, and progressing the game. Each effect has twoattributes and an optional third one. The first two are sim-ilar to the requirement attributes, one being the parameterattribute and the second being the value attribute. The pa-rameter attribute can be the same value as the parameterattribute in requirement except fraction which cannot be al-tered in the course of the game. Also an additional valueto the parameter attribute is introduced, the output value,which outputs a string to the game console. Also a param-eter value room is introduced which changes the location ofthe player. Its values can be either north, south, east or west.The values of the value attribute can again be any stringkeeping in mind that there should be consistency in the def-initions. The parameter output and room are the only oneswhich do not need the third attribute which is operator. Theoperator attribute can be either + or – where + adds thevalue ( inventory[i].add(IEffect) ) to the corresponding viewof the player and – removes ( inventory[i].remove(IEffect) )it where i is the ith element of inventory list, inventory[i].

<!ELEMENT commands (command)*>

<!ELEMENT command (action)*>

<!ATTLIST command


<!ELEMENT action (requirement|effect)*>

<!ELEMENT effect EMPTY>

<!ATTLIST effect

operator CDATA #IMPLIED

value CDATA #IMPLIED

parameter CDATA #IMPLIED>

<!ELEMENT requirement (notSatisfied|satisfied)*>

<!ATTLIST requirement

value CDATA #IMPLIED

parameter CDATA #IMPLIED>

<!ELEMENT satisfied (action)*>

<!ELEMENT notSatisfied (action)*>

<!ELEMENT global (commands)*>

<!ELEMENT exit EMPTY>

<!ATTLIST exit

id CDATA #IMPLIED

room CDATA #IMPLIED>

3.1.2 Parsing the XML to the world graph.In order of the world to be used during runtime it neededto be converted into an Object. The chosen object type forthe parsing was a graph of rooms for the room representa-tion and a map of commands for the global commands. For

parsing the XML, the use of the Jdom library has proven tobe the best choice because of the tree form of the XML fileit offers, and the access methods to the XML file. First theXML is read using a SAX builder, which parses the XMLto a tree. Then each room is parsed on its own using thegetChildren command which returns a list of the chosen el-ement type.

Algorithm 1. XMLtoObject ParserInput: filename, path to the XML file.Output: roomGraph, graph representation of the XML.Begin

1. Initialize 〈roomGraph = empty〉 and 〈roomMap = XML-Tree document〉 to hold the data extracted from theXML file located at filename.

2. for all room element in the root element of roomMapdocument do

(a) Get the room name and id attributes. Set themas id and name to an instance of a Room class,myRoom.

(b) Add id as a node to roomGraph.

(c) Get the intro child element of the room elementand set the extracted message attribute to my-Room.

(d) Get the look child element of the room elementand set the extracted description attribute to my-Room.

(e) for all extracted item element from the room el-ement do

i. Get the name attribute and set it as an itemto myRoom. end for

(f) for all direction element extracted from the childof room element do

i. Get name and roomId attribute of the ele-ment and set them as a direction to the my-Room.

ii. Add id and roomId attribute as an edge toroomGraph. end for

(g) for all command element extracted from the childof room element do

i. Get the command name attribute and as-signed it as a key to the command map.

ii. Get the child action element and parsed ac-tion as the subprocedure, parseAction follows:Get the child requirement of the action ele-ment:if (requirement == null) thenGet the effect elements.for all (effect element extracted) doGet the parameter attribute of effect as ef-fectType. Let EffectTypes= {output, Inven-tory, roomActivequests, Finishquests, Gamefin-ish}if(effectType ∈ EffectTypes) thenCreate an instance of the particular effect-Type with a value from the value attribute of

Figure 3: Component Architecture of Maiar

the effect element. Set the created instanceto an instance of Action class, rootAction.end ifend forelseExtract the parameter and value attributes ofthe requirement element. Set the attributesto a new instance of the requirement class.Set the created requirement to the rootAc-tion.Get the child satisfied and notsatisfied ele-ments of the requirement element. Parse thesatisfied and notsatisfied elements using theparseAction subprocedure described above.Set the actions from the satisfied and notsat-isfied elements parsed to the rootAction astrueAction and falseAction respectively.end ifend for

iii. Set the command name and rootAction areadded to the room instance, myRoom.

(h) Get the node from the roomGraph by the id andset the myRoom to the node as the weight.end for

End

3.2 Model ComponentSince the game revolves around commands and states of theworld, its engine required a way to handle each commandand send a response to it which must become visible to theplayer. For this functionality a number of classes are usedto represent the game entities which are extracted from theworld XML. These classes are a 1-1 mapping of the XMLelements with specialized effects, and additional remote ef-fects which are a way of indirect communication with themessage service.The main class of the game engine, the player includes allother classes mentioned and handles interactions betweenthem, and is responsible for communicating with other com-ponents of the game. It’s connected to other components us-ing a request-response protocol, where any component whichneeds to communicate with the game engine, must send itsinput and wait for a response output, and handle the out-put. The player interface is the only means of changing thestate of the player and the only way of verifying if a com-mand is valid. It is a full representation of the game world

as seen in a client, since the player class holds the player’sdetails, the room in which he or she is, the entire game mapas a graph, the player state (inventory, active and finishedquests, health points, and list of players with whom he orshe is fighting), as well as a map to the global commandsand their actions, as they are extracted from the XML.

3.3 Messaging ComponentOne of the most important aspects of communication be-tween clients, is the broadcasting and reception of messages.Through messaging, the clients, update their local worldstates, and represent the states of other clients.

3.3.1 Design PrinciplesThe publish-subscribe architecture pattern describes an ab-stract mechanism for loosely coupled, many-to-many com-munications between publishers of messages and subscriberswho wish to receive messages [6]. The messaging componentcan accept any number of listeners and when a message isbeing received all of the listeners are being notified of thischange and they can act upon the state change. The advan-tage of using this model is that we can add different com-ponents which can manipulate messages at any time just byhaving them subscribe to the message publisher. Also thisseparates the message component from the client componentwhich enables the possibility of replacing the implementa-tion of the message component with a different one with-out changing the subscribers. For the actual broadcast ofmessages there were several choices of technology includingJGroups [7] and Jxta.All the messages are an extension of the AbstractMessage

class, where a sender and a message string are defined, aswell as a date and the message type. The AbstractMessage

class is an abstract implementation of IGMessage interfaceas defined below:

public interface IGMessage extends Serializable

{

public String getSender();

public void setSender(String sender);

public String getMessage();

public void setMessage(String message);

public void setDate(Date date);

public Date getDate();

public String getType();

}

Each type of message extends this class by adding any ad-ditional information it may require. Specifically, Locationmessages add the room id of the players location as wellas the player’s fraction. Chat messages add a scope andthe receiving room id and/or player, cache update messagesadd a recipient who should update his or her cache. Chatmessages are extended by fight messages which are a specialtype of chat messages and use a specific message string forcommunication, and damage messages are a special type offight messages which introduce a damage amount integer.To achieve this, several types of messages are used, each onesent when the appropriate effect is triggered, and are pro-cessed accordingly. There is also a distributed and a localcache used for sharing the user states that need to be shared.

Sending Messages. Messages are sent through the JX-TAConnection class using the send method. Messages areformed according to the commands the player enters, andare broadcast on the group. When a message has a limitedscope, that message is discarded on reception if the receivingclient is not a member of that scope.

Receiving Messages. When a message is received, if itsscope includes the receiving client, it is added to the appro-priate history in the local cache and the message listenersare notified of an update of the local cache. Each receivingclient then processes the message and responds to it eitherby representing it or sending a message of its own dependingon the nature of the message.

3.3.2 Message TypesThe types of messages are separated into state changing mes-sages and player communication messages. State changingmessages are Location messages, New User messages andCache Update messages.Location messages: The Location messages are sent whena client moves to a different room, so that the other clientsupdate the state of the user locations they are using. Theyinclude the User name of the client, the Room in which theclient is moving and the fraction of the user (whether angelor demon). When a location message is received by a client,that client updates the User Location class which it holds,and if the rooms affected affect the receiving client (eitherthe room the player left from or the room the player entersis the room in which the receiving client is currently in) aroom representation update follows.New User messages: A New User message is sent whena new user joins the game, sending an update of his name,location and fraction for the other users to represent in theirlocal caches. The New User messages are processed differ-ently depending on whether the client is a group leader ornot. A new user has to get an update on the users who arealready in the game, and so needs to get an updated dis-tributed cache. When a client receives a new user message,it updates the user locations it keeps on its local cache, al-though if the receiving client is the group leader, it pushesan updated instance of the local user locations to the dis-tributed cache, and sends a Cache update message to thenew user to pull it.

Cache Update messages: The cache update messages aremessages that are sent when one or more players need to pullthe distributed cache to get an updated view of the world.These messages are sent by the group leader to clients whodon’t have an updated view. When a client receives such amessage, it must pull the distributed cache from the grouphandler and save it in its local cache. Player communica-tion messages are separated into combat messages and chatmessages. Fight messages include the Fight messages andthe Damage messages.

Fight messages: Fight messages are sent when a playerinitiates a fight with another player or when a player hasreceived a fight challenge message. To start a fight, a playersends a fight challenge message to the target client. When aplayer receives such a message, it sends a Fight acceptedmessage to the sending client which initializes the fight.When the client that sent the challenge receives an accep-

tance, the fight begins for it also. When a player’s life totalreaches zero during a fight, then a fight death message issent to all the players with which the player was fighting,and a fight reward message is sent to the first player whoinitiated the fight. When a client receives a death messagefrom another player, it stops fighting that player, and whena reward message is received, that player adds the rewardto its inventory.Damage message: Damage messages are the backbone ofcombat. When a fight is initiated, all participating playerssend damage messages to the other players with whom theyare fighting, over a two second interval. A damage mes-sage contains the receiving and sending user names, and thedamage amount which is an integer less than or equal to9. When a player receives a damage message, it subtractsthat damage amount from its life total. The other form ofcommunication messages are chat messages:Chat messages: Chat messages are the means of socialcommunication between players. They are separated intothree scopes. The global scope is sent when a player usesthe shout command. The room scope is sent when a playeruses the say command and the personal scope is used whena player uses the whisper command. The global chat mes-sages are represented in all clients, while the room messagesare represented only by players who are in the same roomas the sender, and personal messages are represented by theplayer set as a recipient, if that player is in the same roomas the sender.

All these types of messages are saved as a history in the localcache of each player. This cache contains a chat history,a new user history, a cache update history, and a locationmessage history. The local cache communicates with theplayer by using the State changed event listeners and thestate changed events. Whenever a change occurs in the localcache, the client is notified of the source of that change andcan manipulate the messages which were received by readingthem from the local cache.

3.3.3 Communication EngineThe engine component (model) communicates with othercomponents using a request - response architecture throughits interface. That interface is the player class interfacewhich offers methods for retrieving trivial data from theplayer class, and two methods which can result in game statechanges. These methods are the tryAction method, and theExternalEffect method, both of which return a list of effectsto be handled and represented to the GUI. The main dif-ference between them is that the tryAction method takes asinput a String command which is the player input commandafter it’s been parsed by the command parser, while the Ex-ternalEffect method takes as input a RemoteEffect, which isa type of effect which involves multiplayer interaction and isinvoked by an incoming effect. In Figure 4, the internal lifecycle of operational activities of state is depicted and Fig-ure 5 shows the life cycle of the remote interaction betweenGUI of peers. This architecture ensures that the enginecomponent can work independently of either a multi playercomponent or a GUI component, and can be used in a dif-ferent type of game, which could have a different GUI andno multi player mode with just slight modifications. Thisalso allows asynchronous communication with other playerssince the messaging engine works asynchronously from the

Figure 4: The life cycle of a local command.

GUI.

3.4 Logging ComponentMaiar Logging provides a facility for maintaining the devel-opment of the game in the development stage and for cus-tomers at production stage. Basically, the logging facilityprovides these core functionalities:

Developer Diagnosis: The most obvious functional meritof logging is to help developers under developmentstages to be able to debug the application. Becausea modular approach was used in designing the game,it is essential that each module is able to log its activ-ities to help us to identify other problems that occurat runtime and other low-level libraries were used inthe implementation, logs help locate problems in theapplication.

End-Users and System Administrator Diagnosis: It isimportant that messages sent by a peer are transmit-ted successfully to the group, which is the core build-ing block of our design. End-users can use loggingactivities in the application to convey the errors in theapplication to the System Administrators for systemdiagnosis. In practice, common end-user needed logsinclude system failure, memory issues and errors in theconfiguration files. With the Maiar Logging, these logsare generated and can be configured to send email tothe Maiar development team.

3.4.1 Design PrinciplesThere are a lot of logging frameworks out there, which eachhas different core functionality. The idea of designing MaiarLogging over the other frameworks inclusively SlF4J [13],Log4j [9] and JDK logging requires a common interface toabstract the implementations of the frameworks from ourimplementation. The Logging compound component showsthe three basic factory components each of which providesan access to a particular logging frameworks. The use of theabstract factory design pattern separates the details of theimplementation of a set of objects from their general usage.The basic details of the factories are:

InternalLoggerFactory: This creates an InternalLoggerwhich changes the default factory implementation. Thisfactory allows you to choose what logging framework

Figure 5: The life cycle of a remote command.

Figure 6: Screenshot of the Maiar Client.

Maiar should use. The default factory is JdkLogger-Factory. You can change it to your preferred loggingframework before other Maiar classes are loaded. Eachfactory implementation only uses the newInstance method.

JdkLoggerFactory: This factory class extends the Inter-nalLoggerFactory which uses the java.util.logging.Loggerto provide the new instance of the ILogger class bypassing the instance of java.util.logging.Logger to theJdkLogger class. The ILogger class provides access tobasic logging functionality like debug messages, warnmessages , info messages and error messages.

Sl4jLoggerFactory: This factory class extends the Inter-nalLoggerFactory which uses the org.sl4j.Logger to pro-vide the new instance of the ILogger class by passingthe instance of org.sl4j.Logger to the Slf4Logger class.ILogger interface provides the same functionality asthat of the above but different implementation.

Log4jLoggerFactory: This factory class extends the In-ternalLoggerFactory which uses the org.log4j.Logger toprovide the new instance of the ILogger class by pass-ing the instance of org.log4j.Logger to the Log4jLoggerclass. ILogger interface provides the same functional-ity as that of the above but different implementation.

3.5 SecurityAt the architectural level, security boils down to understand-ing the precise security requirements for an application, anddevising mechanisms to support them [6]. The most com-mon security-related requirements [2] are :Authentication : Applications can verify the identity oftheir users and other applications with which they commu-nicate.

Authorization : Authenticated users and applications havedefined access rights to the resources of the system. For ex-ample, some users may have read-only access to the appli-cation’s data, while others have readwrite.Encryption : The messages sent to/from the applicationare encrypted.Integrity : This ensures the contents of a message are notaltered in transit.Non-repudiation : The sender of a message has proof ofdelivery and the receiver is assured of the sender’s identity.This means neither can subsequently refute their participa-tion in the message exchange.Our architecture only supports authentication but the otherthree security-related requirements can be provided. Newusers to the system first create an account by registeringtheir details and choosing user name and password. Thisinformation is stored in the database. Whenever users wishto play the game, they would supply user name and pass-word and is checked against the one in the database, MySQL[11]. If the information provided matches with the informa-tion in the database, access is immediately granted. Thisensures that no unauthorised user ever gets access to thesystem.

4. SOFTWARE QUALITY ATTRIBUTESThis section provides an overview of the software quality at-tributes that our application attains much to do with thechoice of the technology. Quality attribute requirements arepart of an application’s nonfunctional requirements, whichcapture the many facets of how the functional requirementsof an application are achieved [6]. Our application capturedthe following major quality attributes (S-M-E-P) that soft-wares need :Scalability(S) : Scalability is one of the major concerns inclient-server connection that is effectively dealt with in peer-to-peer connection. In client-server connection, increasingnumber of users on server may lead to total collapse of theserver. On the other hand, peer-to-peer systems can haveany number of users without the need to be concerned aboutcentral failure. System load is divided between clients. TheMaiar game is designed using peer-to-peer model to take ad-vantage of scalability that peer-to-peer connection provides.Modifiability(M) : Post-delivery maintenance [12] is nec-essary in product development and as such corrective, per-fective and adaptive maintenance are things that requiremuch attention and were taken care of in Maiar application.Corrective Maintenance : Apache Maven as our software

Figure 7: Deployment View.

management and build tool helps us to modularly maintaindependencies to resolve coding faults.Perfective Maintenance : But with the current archi-tecture approach and using more industrial practise like de-sign patterns, interface-implementation approach gives moresimpler learning curve to make additional changes if so re-quired.Extensibility(E) : XML is used in the system to createa map of the worlds. Commands and descriptions are alsostored in XML file. Whenever a user issues a command, itis fetched from the XML file and executed. One of the mainadvantages of XML is extensibility.Performance(P) : P2P connection aid network performance,in that the bandwidth of the system increases as each peerarrives the bandwidth capacity of the system increases asmore peers arrive: each new peer requests service from, butalso provides service to, the other peers. The network canthus spontaneously adapt to the demand by taking advan-tage of the resources provided by every peer. We might haveto performed more test to assess the performance of this inrelation to our application.

5. DEPLOYMENTThe executable program will be installed on the peer systemafter has successfully registered with the Maiar Server WebApplication. For the client peer to work, it requires some de-pendencies which are just Java Executable jar files as shownin Figure 7. A Peer requires the Java Runtime Environment(JRE) installed on the system to be able to play the game,Maiar. There is an optional installation process for Peersthat does not have the JRE installed on their systems andthis is bundled with the Game installer deployed and hostedon the Application Server. Peer Dependencies: For a peerto successfully run the Maiar Game, these are the requiredartifacts on their system:

• Logging.jar: This artifact is the logging component ofthe application. It is required to provide the basiclogging functionality at the peer side.

• Model.jar: This artifact contains the domain model ofthe game

• Client.jar: This artifact contains the Graphical UserInterface, which is the Swing Application with inter-active response and user experience.

• Messaging.jar: This artifact is the most essential com-ponent of the peer dependency because of the

6. CONCLUSIONSHowever, today’s large-scale distributed applications span-ning from p2p computing, cloud computing poses new issuesthat are hardly addressed. Further work is to access the per-formance issues and perform some measurements to accessscalability and other related issues. Performance issues likethroughput, response time, deadlines and performance of thesystem are not consider because this paper did concentrateon the Maiar Architecture. In this paper, we showed thatdomain object modelling from XML datasource can bring alot flexibility in software API development in general. Graphmodelling of our XML datasource enhances the chances ofreusability: constant model structure and integration withother systems because of platform-neutral syntax of XML.

7. ACKNOWLEDGMENTSThis work was done with the following people Murtala Ab-dulrahman, Giorgos Georgiou, Collin D’Souza and BushraSaba when we were undertaking our Master’s in AdvancedSoftware Engineering at Department of Computer Science,King’s College London.

8. REFERENCES[1] K. A. Berman and J. L. Paul. Algorithms: Sequential,

Parallel and Distributed. Thomson Course Technology,Boston, Massachusetts, 2005.

[2] D. A. Blyth, D. D. Cunliffe, and D. I. Sutherland.Security analysis of xml usage and xml parsing.Computers and Security, 2003.

[3] B. Daum. Modeling Business objects with XMLSchema. Morgan Kaufmann Publishers, Germany,2003.

[4] T. Faison. Event-based Programming: Taking Eventsto the Limit. Apress, May 2006.

[5] R. Garg, V. K. Garg, and Y. Sabharwal. Efficientalgorithms for global snapshots in large distributedsystems. IEEE Transactions on Parallel andDistributed Systems, 99(RapidPosts):620–630, 2009.

[6] I. Gorton. Essential Software Architecture.Springer-Verlag Berlin Heidelberg, Germany, 2006.

[7] JGroups. http://www.jgroups.org/, 2010.

[8] JXTA. https://jxta.dev.java.net/, 2010.

[9] Log4j.http://logging.apache.org/log4j/1.2/index.html, 2010.

[10] Maven. http://maven.apache.org/, 2010.

[11] MySQL. http://mysql.com/, 2010.

[12] S. R. Schach. Object-Oriented and Classical SoftwareEngineering. McGraw Hill, Germany, 2005.

[13] SlF4J. http://www.slf4j.org/, 2010.

[14] R. Steinmetz and K. Wehrle. P2p systems andapplications. LNCS 3485, pp. , 2005. Springer-VerlagBerlin Heidelberg, 15(5):9–16, November 2005.

[15] C. M. S.-M. Tim Bray, Jean Paoli and E. Maler(Eds).Extensible markup language (xml) 1.0 (fifth edition).W3C Recommendation, 26, November 2008.

[16] Tomcat. http://tomcat.apache.org/, 2010.