Gaming Service. Ankit Narang Ankit Sagwal Saurabh Gupta Sabyasachi Haldar

Size: px

Start display at page:

Download "Gaming Service. Ankit Narang Ankit Sagwal Saurabh Gupta Sabyasachi Haldar"

Alyson Hawkins
5 years ago
Views:

1 Gaming Service Ankit Narang Ankit Sagwal Saurabh Gupta Sabyasachi Haldar 6th November 2008

2 Contents 1 Introduction 3 2 Problem Statement and Interpretation Problem Statement Interpretation Objectives Details Features Offered Risk Risk Chat Risk Talk Integration with Web: TWiki Risk Profiles Source Code Evolvement and Improvement Risk Forums Virtual Machine Risk Install Design Choices What Do We Need? Choice made Development Process 11 6 Code Organisation Chat Code Organization VOIP code Integration with the Game Code Game Classes Modified Problems faced Game Integration And Automation VOIP

3 7.3 TWiki Virtual Machine Problems With Open Source World of Softwares Problem Statement Further Work VOIP broadcast Modifications in The Game Web Integration Our Learnings How To Use? References 21 2

4 Chapter 1 Introduction A lot of useful effort goes into the development of any software which has a team working on it for a long time. The team has to face some problems, like recognizing which part is done best by whom. In order to give us a taste of all the difficulties we were given a task of automating the integration of text and voice chat, and Twiki into an open source multiplayer network game. The task was certainly quite an interesting one, one that gave us a feel of actual software development. It certainly was a big learning curve for our group. Even though we did face many difficulties, ultimately the careful planning and the dedication of all the team members ensured that we were able to complete all our work. In the documentation we try to enlist the complete process that went into development of this project. In the end all the group members felt that we needed to thank Prof. Anirban Mahanti for giving us a direction to work in and learn in the process. 3

5 Chapter 2 Problem Statement and Interpretation 2.1 Problem Statement The objective of this project is to build a multi-player gaming service that creates the best possible user experience by combining a set of useful functionalities into a single Web interface. The focus of this project is on automating the integration of various gaming related services and their deployment on virtualized hardware infrastructures as opposed to developing a new gaming application. Students will work with an existing open-source multiplayer game of their choice. They will also work on integrating entities such as VOIP-based messaging services, Instant Messaging services, and TWIKI pages of players to enhance the gaming experience. To further enhance the user experience, the students will investigate the suitability of Web 2.0 as an integrating mechanism. The team will also develop tools to automate the deployment of the gaming service. Specifically, one of the deliverables of the project will be a CD/DVD that contains a Xen Virtual Machine (VM) image of the service. The image should allow a system administrator to rapidly deploy the VM on any supported hardware platform. Furthermore, the students will also develop a synthetic gaming client application to demonstrate the service. Finally, to permit reuse of the automation techniques, the team will also produce detailed documentation relating to various aspects of the project. 2.2 Interpretation Objectives The primary objectives of the project are: 4

6 1. To automate the integration of text chat service and VOIP based chatting service to an opensource multiplayer game playable on a network. 2. To integrate TWIKI pages and Web 2.0 with the game. 3. To provide a seamless installation package for the gaming service alongwith all the integrated features Details The objective is to implement a network based multiplayer gaming service by enhancing the gaming experience by integrating certain general purpose utilities and providing add-on features. We intend to implement generalized features like text based instant messaging service and VOIP based messaging service which can be integrated with any opensource java application to provide platform independence. So, we plan to work with an open source multiplayer java game playable over a network as an example to demonstrate the integration of these generalized features. We also aim to provide utilities like TWIKI pages (which are based on Web 2.0 technology) to maintain the documentation and avail user updation of source code, sharing cheats and discussing strategies. We also wish to provide user profiles to maintain user information. After all this, we intend to create a Virtual Machine image for easy deployment of the service and also provide an installer package. 5

7 Chapter 3 Features Offered Take The Risk is a multiplayer network gaming service which provides the users to play a java version of the classic board game Risk. A user can play with automated bots or with other users over a network. While playing over a network, the users can communicate to each other via instant text messages and/or voice conversations. The users can create account and maintain profiles over the net which they can use to maintain and update their gaming history. Users can modify the source code and publish it on the net, they can also share cheats and other gaming strategies on the internet using TWIKI pages. 3.1 Risk Risk is a strategy game based on the classic game of Risk. The user can either choose to play a single player game with challenging AI or with other users over a network or both simultaneously. There is a wide variety of maps and a number of game types to choose from. The user can have different views of the maps during game play. 3.2 Risk Chat The users are provided with a general purpose text messaging service integrated with the game of Risk. While playing a multiplayer game over a network, the players can text chat either peer to peer or Broadcast the message to all other players. Each user is provided with a list of users that are currently playing the game which can be used to start a P2P conversation. 3.3 Risk Talk The users are also provided with a general purpose Voice Over IP based messaging service integrated with the game of Risk. This is a Peer to Peer 6

8 voice messaging (telephony) application. A user can select another user from a list of players in the game and start a voice conversation. The User is also provided with the facility of adjusting audio and connection settiungs. User can also perform mic tests and test connections also. 3.4 Integration with Web: TWiki Take the Risk users are also provided with a web interface implemented through TWiki pages based on the Web 2.0 technology. TWiki provides an interactive interface to users and visitors by allowing them edit and modify the web pages. Users can create their TWiki accounts and Start using the Take The Risk Twiki Web. The Take The Risk TWiki Web provides the following features to the users Risk Profiles Users can create and maintain their personal TWiki profile pages. These pages may or may not be editable by others depending on the users Topic access settungs Source Code Evolvement and Improvement The users can also download Take The Risk source code. This code may be used for further development and uploaded on the UploadCode topic in the Take The Risk web. This feature is a mark of the commitment of the Take The Risk Development Team for the enrichment of the World Wide Web Open Source Community Risk Forums The web users can also share game cheats, strategies, news, updates and other interesting stuff on the RiskForums Topic of the Take The Risk web. Various types of forum topics like CheatForum, DevelopersForum, etc are available. 3.5 Virtual Machine For easy deployment of the Take the Risk gaming service, the service administrator is provided with a VMware image of the service. This can be copied onto the system and mounted on a VM player to deploy the service. 7

9 3.6 Risk Install In order to provide a user friendly and seamless installation process, the user is provided with the Risk install installer package. The user can deploy the service simply by double clicking the setup executable file and the installation is done in no time. 8

10 Chapter 4 Design Choices The Given Design Challenge which is stated in the starting of this document demanded that we automate the integration of text and voice chat, and Twiki web-base in an open source game, thus enhancing the game experience. 4.1 What Do We Need? 1. An open source multiplayer network game with an elegant code that allows us to easily comprehend and edit it, to suit our other choices. 2. A text based instant messaging service, that allows users to talk to each other during the game. 3. A VOIP based service for real time audio conversation. 4. A knowledge management system to host the game pages and allow users to interact, eventually leading to further enhancements. 5. A suitable VM Player to create the VM image of the gaming service for easy deployment. 6. A compiler for compiling scripts and packaging files in order to create a seamless installer package. 4.2 Choice made 1. We preferred a java-coded game over games in other possible languages. This inherently made it platform-independent and also enabled us to keep our options open in terms of a possible implementation in a web-browser using applets. However, later we decided that an independent stand-alone application running without browser support is a better option. 9

11 2. We developed our own text chat in java. Initially we worked on a Server-client model(with single client). Then we updated it to multiway chat(more than one client). After major testing, we integrated it with our game code. Our chat offers both a peer-to-peer talk option, with a drop-down menu to select a particular player from the available clients, as well as a multiway broadcast, wherein the chat is displayed on the screens of all connected clients. 3. Our VOIP - Voice over Internet Protocol software is also a java code. We integrated it to the game to allow for automatic IP acceptation from the game itself. It is a peer to peer chat, with both players having the possibility of starting and stopping it anytime during the game. 4. Twiki was preferred over other similar knowledge management because it is very user friendly compared to some well established commercial groupware systems like Lotus Notes. 5. The KM system also displays the source code, and just like many other open source softwares, allows the users to edit and upload their verisons of the game, thus leading to enrichment of the open source community. 6. We chose VMware for making the VM image of our gaming service. We installed an Apache 2 server on Ubuntu8.04 in the VM and used this to implement the Risk Web Interface using TWiki. jdk was installed on the VM for the proper functioning of the game. 7. For the installer package, we used the NSIS compiler to compile our installation scripts and Package the files into a user friendly installer package. 10

12 Chapter 5 Development Process The following is the process through which we planned our development. 1. Planning and assignment of reading work to individuals. 2. Reading up material for new technologies to be used. 3. A large number of google searches, to narrow down on our game and other pieces of open source codes we needed. 4. Deciding what technologies to use and distribution of work among group members. 5. Individual work on independent components. 6. Integration of the core services offered. 7. Putting it all together in the form of a software package. 11

13 Chapter 6 Code Organisation The project had three core things to do. These were implementing a generalised Chat Service, integrable with any java application; finding (or building) a suitable opensource VOIP service, which could be integrated with the Game and the actual integration of these utilities with the game. Here s a brief description of these utilities and the process of integration. 6.1 Chat Code Organization The model that we used to implemented is shown in the fugure below. Here, when a Server is started, it starts a new Thread which continues to listen for incoming client connections at the specified port number. On Receiving a new connection, a new Socket is created and a new handler to continuously receive input streeams from the client is started. On the Client side, when a client connects to the server at the predecided port, it receives a Socket through which it can interact with the handler at the Server side. The client also interacts with a GUI at the Client Side, to receive inputs (to send them to the handler for broadcast to other connected clients) and also provides the incoming strings to the GUI for displaying. The code base thus generated can be easily integrated with any existing java package. This can be done easily by starting a new Server at the Server Side (by creating a new Server Object) and launching the Client part at the client side, giving it approriate functions in the GUI, to input and output chat messages. 6.2 VOIP code The opensource code picked up from the net, offers a Peer to Peer voice interaction. Two clients can launch the service at their ends, and connect by specifing the IP address of the other, to connect and have voice transfer. 12

14 Figure 6.1: Figure showing how chat has been implemented 6.3 Integration with the Game Code These two services obtained independently were integrated with the existing game, by modyfing the game GUI, to have input and output feilds for the chat messages and selection pane for voice chat. All setup of connections was done by obtaining network information stored in the game internally, to seam to the user as though it is not three applications running in parallel, but an integrated applicaiton which is running. Features such as selective chat and group chat were also added by appropriately accessing player and group information from the Game Data Game Classes Modified 1. Risk.java To obtain the Information about Players, their IP addresses. 13

15 Figure 6.2: Figure showing how Integration has been done 2. MainMenu.java Starting the chat Server when we start the game server. 3. GameFrame.java Added the required GUI for the chat messages and options. 4. Other minor modifications to retreive stored information. For complete technical documentation, we have also generated a complete java documentation of the code we have generated. This can be accessed using the following links 1. Java Docs 2. Documentation in Doxygen 14

16 Chapter 7 Problems faced 7.1 Game Integration And Automation Inadequate game documentation has been a big problem. It was important for an integrated chat service to start automatically when the game window opens and use the same IPs which the game has already taken. Basically we had to fish deep inside the game to make the service name based instead of IP based. The only time we ask for an IP address is when the game starts, and everything after that is user friendly and easy. Multiple gaming clients couldn t be run on localhost simultaneously. 7.2 VOIP VOIP service required a time delay to setup. The code we used for VOIP gave the server an option to either accept or refuse the incoming connections. As soon as we removed this option to allow easy starting of voice chats... we got an error. The problem of automatic acceptation of voice chats was that the server accepted the connection and looked for packages even before the client could send one. This led to a break in connection. We introduced a little delay to allow for smooth connections. 7.3 TWiki Thw TWiki installation and configuration required a lot of effort. After that, the main problem was to set access restrictions to the pages created in TWiki. Someone had been bugging us by interfering in the TWiki develoment process by altering administrator created pages and resetting passwords. So, it was inevitable to set security restrictions to these TWiki pages for modifications. Finally, we figured it all out and made our pages editable by administrator only. 15

17 7.4 Virtual Machine Appropriate configuration of the VM was a big problem. Detection of network card and audio hardware also required a great amount of effort to be put in. 7.5 Problems With Open Source World of Softwares Most open source games available on the net are generally non-functional. They require a lot of debugging before they become operational. Sometimes the jar files work while the source code is incomplete. Thus, chosing a game becomes a tough job. 7.6 Problem Statement Figuring out the problem statement was also a problem. It included a lot of various things that could be implemented in a number of incorrect ways, even though they might seem fine to start with. 16

18 Chapter 8 Further Work 8.1 VOIP broadcast The voice chat could be made multiway. Presently we cannot broadcast it to all users. A major problem with extending the present model to a multiway chat is that we require a very fast processor to process and handle the voice traffic at the server side. At present the computers can implement multiway only by sacrifising on the performance, leading to lags and breaks in the audio content received. And even if we get a fast processor, the model is not scalable to a large number of users. 8.2 Modifications in The Game 1. The game has a few errors, which can be removed. One such problem is that while playing multiplayer games, if we create players before every client has joined, it lead s to an exception. 2. We can extend the game to be playable over a WAN, but that would require some optimization measures to be taken. 3. Adding Sounds for events in the game. 4. Generating scores and score files to be uploaded onto the internet Twiki Profile. 8.3 Web Integration We also wanted to have more integration with the web, by adding the following more features 1. Posting the scores on the user profile. We can generate a data file containing the score and performance of 17

19 the palyer after each game. The player could then post that file onto his Twiki profile for others to see, and generate overall rankings. 2. Creation of New Maps. The Risk fan club all over the World can create new Maps for the game, and then put them up online on the Risk TWiki. These maps can then be downloaded and used by users all accross the world. OA 18

20 Chapter 9 Our Learnings The development process of this project has been a memorable journey for all the team members. We have had a huge number of successes and pitfalls, each of which has been a great learning experience for us. The following are to name a few: 1. Setting up a secure web application: While developing the TWiki based web interface, someone tried to break into our pages and manipulate them. This was possible due to the globle modifiability of TWiki pages. This compelled us to figure out ways for putting security restrictions on web pages. 2. Generalized process for compiling linux applications: While trying to install a lot of games on linux all of which had different library requirments, we ended up learning about makefiles, software packages, etc. 3. Creating a Generalised Installation: In an attempt to make the code compatible for a variety of platforms, we looked into all platform dependent attributes and tried to fix them. We were able to fix quite a few, but a some still exist, prompting us to learn further in this direction. 4. Object Oriented Programming Concepts: In the process of modifying the game code, we looked at a lot of professionally coded programs, which helped us develop our skills of code abstraction and organisation. 19

21 Chapter 10 How To Use? Our game DVD includes a Risk.jar file. It is a platform independent java file to run the game. Use the java version jdk or higher for best performance. This is how you can run the game on our computer. 1. Linux java -jar Risk.jar or double click on it 2. Windows double click on the file The DVD also contains the source code. Risk original is the old source of the game. Risk new is the new updated source of the game, with integrated chat, VOIP based service and a better interface. We also provide our user with server capability, which can be taken using our vmware image for the same. 20

22 Chapter 11 References 1. the starting point of all searches the site includes a list of linux based games. 3. Various chat tutorials 4. a comprehensive java guide 21

Evaluation of Visual Fabrique (VF)

Evaluation of Visual Fabrique (VF) Dr Peter Lappo www.smr.co.uk Scope and Method This is a review of Visual Fabrique (VF) V1.0.371 EAP Release. In order to conduct this evaluation I followed the tutorial