Firebolt MUD Client Development of a Client Prototype for Aeonfalls Online

2005:20 HIP BACHELOR'S THESIS

Firebolt MUD Client Development of a client prototype for Aeonfalls online

Emil Nilimaa

Luleå University of Technology BSc Programmes in Engineering

Department of Computer Science and Electrical Engineering Division of Media Technology

2005:20 HIP - ISSN: 1404-5494 - ISRN: LTU-HIP-EX--05/20--SE

Firebolt MUD Client

-Development of a client prototype for Aeonfalls Online-

Emil Nilimaa

Division of Media Technology, Dept. of Computer Science and Electrical Engineering, Luleå University of Technology

Luleå, December 2004

Supervisor and Examiner: Kåre Synnes Luleå University of Technology Abstract

Multi-User Dungeons or commonly called MUDs (”muds”) are computer games which users can enter and explore over a network such as the Internet. Each user takes control of a computerized persona/avatar/character which let them walk around, chat with other characters, explore dangerous monster-infested areas and solve puzzles or quests.

This project investigates existing technologies for text-based and graphical MUD (Multi-User- Dungeon) clients and gives suggestions and ideas for how to implement a MUD client for a text- based environment with a more user friendly and attractive interface. It also includes an implementation of a next generation client application for text-based games enhanced with features to make it the edge of today’s technology. It includes features from graphical games implemented in a way to make the text-based games more appealing to people outside of the special type that loves the mind thrilling and imaginative worlds made of text.

The application implemented is developed with the Swing package and Java 1.5.0 for the upcoming Aeonfalls Online game from Mythicscape. It features a network implementation based on the protocol developed for Aeonfalls and a rich graphical interface that implements all the special features that are available in the game.

2 Preface This Bachelor of Science thesis project is part of my exam work that I have been doing during autumn 2004 between September and December. I have done most of the work at Luleå University of Technology on my laptop and in the computer labs.

I decided to do this project as my Bachelor of Science thesis since it is an important part of the game that I am currently working on for my newly started company – Mythicscape. The development of a client prototype as in this project is exactly what I have been studying over the years and it seemed like a perfect end for my studies.

I would like to thank my examiner Kåre Synnes who has been a good resource for help and assistance during the project.

Luleå, December 2004

Emil Nilimaa

3

Preface...... 3 1 Introduction...... 6 1.1 About Mythicscape ...... 6 1.2 Background ...... 6 1.3 Purpose...... 6 1.4 Objectives...... 6 1.5 Document Outline...... 7 2 Aeonfalls Online ...... 8 2.1 Description...... 8 2.2 Fundamental Idea...... 8 2.3 Technology...... 8 2.4 Aeonfalls Network protocol...... 8 2.4.1 Network Protocol Classes...... 9 2.4.2 The Protocol Class ...... 9 2.4.3 The Interpreter Class ...... 9 2.4.4 The NetPacket Class ...... 9 2.4.5 Why not use Java RMI or Java Serializable network streams?...... 10 2.4.6 TCP/UDP Protocols ...... 10 3 Specification ...... 11 3.1 Requirement Specification ...... 11 3.2 At a Glance...... 11 3.3 High-level requirements ...... 11 3.4 Extra features...... 12 3.5 Performance, Quality and Appearance ...... 12 3.5.1 Minimum Hardware Requirements...... 12 3.5.2 Download Size...... 12 3.5.3 Efficiency...... 13 3.5.4 Reliability...... 13 3.5.5 Usability...... 13 3.5.6 Appearance...... 13 4 Implementation of the Prototype...... 14 4.1 Development Model...... 14 4.2 Change Analysis...... 14 4.3 Development Tools...... 14 4.4 Design...... 14 4.4.1 Automatic Updating...... 14 4.4.1.1 Java W eb Start – Not the Solution...... 15 4.4.1.2 PatchUpdate...... 16 4.4.2 Graphical User Interface ...... 18 4.4.2.1 Layout...... 18 4.4.2.2 Layout Managers...... 18 4.4.2.3 Custom Graphical Components...... 18 4.4.2.4 ImageButton...... 19 4.4.2.5 ImagePanel ...... 19 4.4.2.6 TexturedPanel ...... 19 4.4.2.7 TextPane ...... 19 4.4.2.8 Equipment Panel ...... 19 4.4.2.9 Inventory Panel...... 20 4.4.2.10 Drag and Drop...... 20 4.4.3 2D Tile Based Map...... 20

4 4.4.3.1 TileHandler and Tiles...... 20 4.4.3.2 Handling Terrain Transitions ...... 21 4.4.3.3 Terrain Transition Template...... 21 4.4.3.4 Tile Templates...... 22 4.4.3.5 Larger Blocks of Tiles...... 22 4.4.3.6 Scrolling...... 22 4.4.3.7 Icon Layer...... 23 4.4.4 Networking...... 23 4.4.4.1 NetworkHandler...... 23 4.4.4.2 NetParser...... 23 4.4.4.3 Why the Java NIO package is used...... 23 4.4.5 ImageHandler...... 24 4.4.6 SoundManager...... 24 4.4.7 AliasManager...... 24 4.4.8 Macros...... 25 5 Evaluation and discussion ...... 27 5.1 Results and Conclusion ...... 27 5.2 Future of the Client Prototype...... 28 6 Appendix – Terms ...... 28 7 Appendix - Use Case Diagrams...... 29 7.1.1 Start Client...... 29 7.1.2 Menu Manipulations...... 29 7.1.3 Command Line Manipulations...... 30 8 Appendix - UML Class Diagrams...... 31 8.1.1 PatchUpdate ...... 31 8.1.2 ImageButton...... 31 8.1.3 TileHandler and Tile ...... 32 8.1.4 TileMap2DPanel, TileMap and TileSector...... 33 8.1.5 NetworkHandler...... 34 8.1.6 SoundManager...... 35 9 References...... 36

5 1 Introduction

1.1 About Mythicscape

Mythicscape is a small company that was created 2003 in Luleå, Sweden. It focuses on creating online multiplayer games and in particular text-based MUDs for commercial use.

1.2 Background

The first MUD, MUD1, was written by Richard Bartle and Roy Trubshaw [1], back in 1979-80, and is generally accepted as the first MUD. These early day MUDs (and most MUDs today) are text-based games that are played through Telnet applications. Telnet is an old protocol used with network programs to connect to servers. MUD clients are programs that the players use to connect to the MUD server and let them play the game with a more user friendly interface than a raw Telnet console such as a standard terminal application. Today a lot of commercial MUDs are developed into 3D graphical beasts such as EverQuest [2], Dark Age of Camelot [3] and World of Warcraft [4]. These are also commonly called MMORPGS (Massive Multiplayer Online Role- playing Games). However, the old text-based games still remain active and draw a special niche of people. These games do not become “old” when new technology is invented as with their graphical counterparts which success heavily relies on astounding graphical environments. Text based games tend to focus more on social aspects, role playing and community than visual effects and groundbreaking technology. A rough comparison of text-based games versus graphical games is similar to comparing books and movies which both attract people although one is using hundreds of years older technology.

Aeonfalls Online is a new upcoming text-based game from Mythicscape. To make the game reach a larger audience and to make it stronger commercially than similar free games a new type of MUD client needs to be implemented. It must be more user friendly than current MUD clients and contain graphical enhancements to attract people outside of the current MUD community. A study of the current market for MUD servers and clients will help to analyze the need of new features and changes that could be made to make a more attractive application.

1.3 Purpose

The purpose with this project is to study the possibilities to develop a new kind of MUD client for a commercial game that will give it a greater appeal than the current existing games. This will be done by developing a prototype of the Firebolt client for the Aeonfalls game that integrates common features found in text-based games with those from the graphical MMORPGs to create a strong commercial application.

1.4 Objectives

The main objective is to implement a prototype of the Firebolt client for the Aeonfalls Online game. To do this the market of MUD clients and the technology used to create them needs to be investigated. The features of the Aeonfalls Online game must also be analyzed and solutions must be designed to realize these in the client application. A specification of the application needs to be written that includes all the ideas and features that should be implemented and a design needs to be created that shows how to implement the specification in an object oriented programming language.

6 1.5 Document Outline

The report is divided into 9 chapters. The Introduction part gives a thorough description of the objective, purpose and limitations of the thesis work.

The Aeonfalls Online section contains a short description of the game and its features. This is included so it is possible to understand what kind of game the software is created for. It also includes a section about the technology that is used in the game and is relevant for this project.

The Specification chapter contains part of the full requirement specification that I wrote for the application. It includes the most fundamental and high-level requirements and a UI flow chart. The specification is based on the Aeonfalls Online game and the analysis of current MUD technology that was done in this thesis.

Implementation of the prototype contains some design issues and explanations of the implementation for the client.

The Evaluation and Discussion section includes some discussion regarding the project and the work behind it.

The Reference section holds a list of links and references to places where I have collected and used information for the thesis.

The Appendices contains use case and class diagrams.

7 2 Aeonfalls Online This section contains information about the Aeonfalls Online game and some of its technology.

2.1 Description

Aeonfalls Online is a Multi-User-Dungeon (MUD) which is a type of text-based game that is available over the Internet. The game server lets users log in and explore the world through a graphical user interface.

2.2 Fundamental Idea

The basic and most fundamental idea about MUD games in general and Aeonfalls Online in particular is the multi-user aspect. Players log in to the game over the Internet from all over the world and take control of a fictional character to role play in a fantasy world. Together they form groups and solve quests and fight monsters. The social aspects are very important and the sense of a community is what makes the games come alive. A MUD that is not connected to a network is boring to play and does not serve its intended “multi-user” purpose.

2.3 Technology

Aeonfalls Online is a custom mud server developed solely with Java 1.5.0 [5]. The most interesting and important part of the technology used with the server in connection to this project is the underlying network code. It is based on the Java NIO package which allows a scalable server with non-blocking networking. The client prototype implemented here will need to communicate with the server through the special network protocol that is available in a separate Java package.

2.4 Aeonfalls Network protocol

A custom network protocol has been implemented for the communication between the Aeonfalls Online server and the client. The protocol is built so that it will be easy to use in network applications and implemented as a package with the Java language. The protocol includes classes and interfaces for initializing a network interpreter that reads bytes from a ByteBuffer (java.nio.ByteBuffer) and outputs a NetPacket (com.mythicscape.aeonfalls.protocol.NetPacket).

The NetPacket contains information about which particular protocol that should be used when interpreting the data that is encapsulated inside it. An identifier in the packet tells what kind of information that is stored in it and how to extract it. Each standard NetPacket (BasicPacket) contains an array of Strings and an array of short integers. It is possible to extend the NetPacket class and create new types of packets that hold other information, but most types of data sent between the server and client is possible to represent in the BasicPacket.

To implement the networking between the client and server with the Aeonfalls protocol the client application needs to open a socket to the server and create a thread that will read bytes from the socket stream and append them to an incoming buffer (ByteBuffer). The application then needs to process the input of the incoming buffer and send it through the protocol interpreter (com.mythicscape.aeonfalls.protocol.Interpreter) which will return a NetPacket if there is a full packet available in the buffer. The NetPacket must then be sent through some kind

8 of parser that the application needs to implement which should perform the correct actions based on the packet type and the encapsulated information.

2.4.1 Network Protocol Classes This section contains a brief explanation for the most fundamental classes available in the protocol package for the Aeonfalls networking.

2.4.2 The Protocol Class The Protocol class contains information and identifiers for the different NetPackets available in the protocol. This class also contains the getPacket() method that will take a ByteBuffer, the protocol identifier and the packet type of an incoming packet and then create a new instance of the correct extended NetPacket and return it. W hen creating and extending new types of NetPacket this method needs to be modified to include the new editions.

As an example the CTS (client-to-server) protocol identifier is defined as the short integer “2”. Whenever the getPacket() method receives the incoming protocol parameter with the value of 2 it will create a new CTSPacket with the parameter type and buffer as arguments and then return it.

2.4.3 The Interpreter Class The Interpreter is the actual object that is to be used when setting up a network with the Aeonfalls protocol. W hen the Interpreter is instanced it will create a new Protocol variable that it will use when interpreting packets from an incoming ByteBuffer. The Interpreter also contains a getPacket() method similar to the Protocol class but only takes a ByteBuffer for incoming data as parameter. It will read bytes from the buffer and fetch the identifier of the next available packet, the packet type and a ByteBuffer containing the data for the packet, which all is part of the Header for a NetPacket. It will then call the getPacket() method on the Protocol with these variables to get the correct instanced NetPacket which it will return. If no new NetPacket was found in the buffer, or a NetPacket was found that has not yet received all the bytes to complete the packet, null will be returned.

2.4.4 The NetPacket Class The NetPacket class encapsulates data that is communicated between the server and the client. A packet consists of a header of 7 bytes and a data body that is holding the actual information. The header is explained in the figure below:

Bytes Packet Header

1 Header tag (start of packet) 2 Packet type (short integer) 2 Protocol id (short integer) 2 Data length (short integer)

9 The header tag (a predefined byte) indicates the beginning of a packet. This tag is useful if somehow a data packet is corrupted or the networking in any way is disturbed. A packet can then be skipped and the beginning of the next packet can be searched out in the received byte buffer.

The short integer for the packet type shows which type of packet it is. Depending on what type of packet it is the data will be read in an appropriate way from the data bytes that are following the header.

The protocol identifier shows which protocol type this packet belongs to. There are several different protocols that have their own packet types. The packet types are split up on several protocols to be accessed and viewed in an easy way. Examples of protocols are “server-to-client”, “client-to-server” and “game command”.

A short integer defines the length of the data in the packet. This amount of bytes will be read from the received byte buffer and appended to the received bytes that will be processed as the data. This also makes it possible to wait until a whole packet has been received before processing the data bytes by simply making sure that enough bytes is available in the buffer.

2.4.5 W hy not use Java RMI or Java Serializable network streams? Java has a package called RMI (Remote Method Invocation) that allows a client and server to invoke methods remotely over a network which is a very convenient way to handle communication. The reason why I did not choose this approach for our server-client is that I wanted to keep the client separated from the server so that it would be possible to write new client software with another language in the future without too much hassle. The approach I took when designing the server and client allows a software developer to easily read through the javadoc files of the network protocol and see how network packets are composed to be able to create their own network code for communication with the server independent of the source language for the server.

I also experimented some with sending objects using the Java Serializable interface directly over network streams. This was actually the approach I used when initially programming the server (which is outside the scope of this thesis project) but changed that once we realized that we would probably be using client software in the future that would be developed with other languages than Java.

2.4.6 TCP/UDP Protocols The network protocol used with Aeonfalls Online for sending packets between the server and client are high level and used on top of existing transport protocols such as TCP or UDP. I decided to use TCP for the networking. The decision was based on that TCP is a reliable protocol that although it is slower than UDP provides enough speed for this kind of game and removes the extra work needed for detecting low level errors in the transmissions and repairing lost data.

10 3 Specification

3.1 Requirement Specification

After the analysis of the existing clients on the market today and what changes and features that should be available in the Aeonfalls game and client a full requirement specification was written. However, it is way too long to be included in this document (approximately 30 pages) and a lot of the content would not be relevant here. Instead only the most fundamental high-level requirements of the application will be listed here.

3.2 At a Glance

The client (application) is downloaded from the main website and installed on the end user’s computer. This is done by simply double clicking a setup file. The user then starts the program from the start menu (or equivalent) of the operating system. The client connects to the game server and lets the user login with his/her password and username. From the account menu the user can create a new character or simply login an existing character into the game world. W hen the user logs into the game world the main application window is displayed. This window contains the actual user interface for playing the game. It holds the main text-output window, command line, status window and all the different sub-windows that are used for the different features.

Top panel

Left side Right side top panel top panel Main text panel

Left side Right side bottom panel bottom panel

Prompt panel Command line Status prompt

3.3 High-level requirements

These requirements are a part of the full specification for the application and list some of the fundamental features that should be implemented.

11 • The application needs to be able to communicate over the Internet with the game server using the Aeonfalls protocol. • The graphical interface for the application should be very user friendly and easy to use. It should also be designed in such a way that it appears more like a “game” than a normal windowed program, which basically means custom graphics should be used for most UI components. • A “smart” command line that allows tab-completion and command history. • Definable aliases and macro keys. • Update feature that automatically connects to a website and downloads the appropriate “patch” to update the program to the current version.

3.4 Extra features

These features are considered as extras and are not part of the high-level requirements. These extra features have a lower priority and should only be implemented if possible within the given time frame. The extra features are included to enhance the community feeling and the communication between the community members.

• Voice communication through headset with microphone. • Web cam/video communication in a special frame.

3.5 Performance, Quality and Appearance

These requirements are based on performance, quality and appearance expectations on the client software.

The quality of the client represents the quality of the game. It is what the users will associate the game with and it is important that the program meets the following requirements to make the game look professional.

3.5.1 Minimum Hardware Requirements The minimum machine required to run the software must be relatively low but compared to the old fashioned MUD clients the requirements are a bit higher. The client must be able to run on a Pentium 600 MHz, with 64 MB of RAM, or an equivalent machine.

However, the requirements outlined in the specification should be matched for an Intel Centrino 1.6 MHz CPU with 512 MB of RAM. The requirements does not need to be fulfilled on worse hardware but the software should run (although perhaps with worse performance) on the Pentium 600 MHz with 64 MB of RAM.

3.5.2 Download Size The installation files for the program will be higher than normal MUD clients due to more intense graphics and sound files. However, it should not be larger than 100 MB. It should also be possible to easily create a CD with install files of the software so that users that are using slow modems can access the game by ordering a CD.

12 3.5.3 Efficiency It is of great importance that the client software is fast and responsive. The software should feel fast in such a way that no GUI widgets should react slowly to the user’s interaction. W hen using a GUI widget it should not take longer than 1 second before the response is visualized to the user (Not including network latency of course).

Text added to the main text window should scroll quickly so that the user never has to wait for text to become visible. It should not be possible for the normal human eye to see characters being added into the text window one by one, or line by line. After a packet of data has been received to the client, the textual representation of it should not take longer than 100 ms to render into the window.

3.5.4 Reliability No known serious bugs or devious flaws should be present in the software that will deadlock itself or the computer (putting the software or computer in a state where the user cannot control it any longer). It is important that any errors are handled in a good way without totally crashing the software and dead locking it. The errors should be presented in an understandable way to the user and also include Java Exception information and stack trace so that it is possible to debug the software. The user should be informed whenever an error occurs and the Exception information should be stored in a debug window. No blue screens!

3.5.5 Usability These are some usability requirements that should be fulfilled by the software:

• It is critical that the client is easy to use and understand by new players. Everything should be configurable and managed through a graphical interface to make it easier to understand. This means that all configuration of the client should be done with GUI widgets. • Tool tips should be used on all widgets to help the user understand their use.

3.5.6 Appearance The client should have a fantasy feeling and look like a game rather than a windows program. To accomplish this custom graphics should be used for most GUI components. Standard Java AW T or Swing widgets may be used but custom representations are preferred.

13 4 Implementation of the Prototype This section contains information regarding the implementation of the prototype.

4.1 Development Model

No specific development model has been used in a complete way when implementing and designing the prototype. The lifecycle model described by Andersen [6] has been used in certain areas with analysis and design of the application. The application can be viewed as a graphical interface for an information system which transfers data between an interactive database (MUD server) and the user. No fully detailed analyze of the information system has been made since it would have taken up too much time for the prototype to be finished within the deadline of the project.

4.2 Change Analysis

Today most MUD games do not have their own clients and the users themselves need to find their own solutions and applications to be able to connect and login to the servers. These clients are often built based on the Telnet protocol which is the standard for communication between clients and servers in the MUD community. Some commercial corporations have developed their own clients to be able to separate themselves from the vast amount of free MUDs available on the Internet today and to attract more customers.

Mythicscape has in the past used communication between the Sharune MUD [7] and the users clients based on the Telnet protocol. The users have found and installed their own client software and paid other companies. A common mud client is for example ZMUD from Zuggsoft [8]. In the beginning of year 2000 Mythicscape developed an own Java applet for the Sharune MUD which came to be used by a large crowd of the current users.

For Aeonfalls Online a new professional client is needed that can measure itself with the most common MUD clients on the market today, and in particular the commercial software. The users must feel that they get something for the money that they will pay to play the game.

4.3 Development Tools

I have chosen to use the Eclipse platform [9] for developing the application. In my opinion it is an outstanding IDE for Java programming and I have worked with it a lot in the past. I have also used JUnit for doing some testing on certain methods in the source code.

4.4 Design

4.4.1 Automatic Updating The application should be able to automatically update itself when it is started if there are some new patches on the web server available for download. This feature is in some ways related to the deployment of the program. If I decide to use the Java Web Start feature it would include both a deployment solution and a self update feature. However, there are some reasons to why I decide not to use Java Web Start and instead create my own updating feature for the application and use another deployment solution.

14 4.4.1.1 Java W eb Start – Not the Solution Java W eb Start is an application-deployment technology from Sun Microsystems that makes it possible to launch applications with a single click from a web browser similar to how applets are accessed from web pages. W hen clicking in the browser it downloads all necessary files and cache them on the local computer so the application is always ready be started. It also checks against the website to ensure that the current files are updated to the newest version of the program.

This all sounds like an excellent solution and it does most certainly work for many types of applications. However, there are some drawbacks with Java W eb Start which I will discuss here and which shows that it will be a better solution to create an own update solution for the Firebolt client.

For Java Web Start to work the whole application needs to be bundled into Jar files (.jar) as Java Web Start can only distribute Jar files. For some programs this may be insufficient and troublesome. The self-update part of Java W eb Start is made so that it will check for the date of the currently local Jar files and compare them against the Jar files on the remote web server. It will automatically download all the Jar files from the remote server that are of a newer version. The problem here is that for the game client prototype there will be very large amounts of graphic and audio resources that will also change frequently as new features are added into the game. This poses a problem where a single audio resource should be changed and only that part of the program should be updated. W ith Java W eb Start it would require that the audio resources would be bundled into a Jar file, and the whole Jar file would be downloaded and updated. It is possible to bypass this problem by doing some modifications to the JNLPDownloadServer which allows you to create JarDiff files that contain only the changes from one version of the jar to another. It is also possible to split up the resources of the program into several smaller Jar files so that modifying one of them does not affect the others.

When comparing the hassles with Java Web Start and how the program needs to be created and modified to work with it, the benefits of creating an own updating procedure can easily be seen. With an own updating solution it will be possible to simply change any part of the program, put it into a zip file and upload that as a patch to the web server. The next step would then be to simply edit a text file and write which is the current version and which file (patch) that should be downloaded to update the program from version x to version y. The end user will see the program automatically download the newest patch and unzip it into the program structure which then is updated to the newest version.

It is still possible to utilize Java W eb Start with applications that are running with an own update solution to get the easy installation and deployment solution.

15 4.4.1.2 PatchUpdate I decided to call the update feature for the program PatchUpdate. The functionality of PatchUpdate is to connect to a web server, decide which version that is current and download any appropriate patches to update itself to the current version. It should also be easy to create new patches and upload them to the web server.

The whole update feature is baked into a single java class called PatchUpdate which is abstract and extends the JFrame swing class. I tried to create a reusable class that could be used for any programs that needs to update themselves from websites. To use the update feature one must create an own class that extends the PatchUpdate class (since it is abstract). This forces the class to define several abstract methods such as how information should be displayed to the user.

(A screenshot of the PatchUpdate software).

The constructor of the PatchUpdate class requires several parameters such as the local path of the folder for the update feature, remote path on the web server (URL) and a few others. The liveupdate also contains methods for loading a few special files required by the update feature called boot.ini and server.ini. The boot.ini file indicates which version that the program is currently updated to and the server.ini contains the URL to the web server that will be used for updating.

On the web server a special directory for the update feature needs to be created. This directory is the same as the one we send as parameter to the PatchUpdate constructor. (It could for example be something similar to /patchupdate/theprogram/. This means that on a web server called http://www.theserver.com the PatchUpdate will use the following URL as remote path: http://www.theserver.com/patchupdate/theprogram/). A special file called versionlist.txt needs to be added to this directory. This file contains the current version number and a few lines that tell which patch to download based on the current local version of the program. W henever the program is changed and a new patch is created we will upload the patch to this directory and alter

16 the versionlist.txt to include the new version number and a line which tells what patch to download to update the program.

The core of the PatchUpdate class includes methods for opening an URLConnection to the server with a BufferedInputStream. A file is then created locally on the server for the remote patch and bytes are read from the input stream and are written to the file through a FileOutputStream. W e then have the actual patch file that we will use to update the program with. The patch file will be unzipped into the program structure. The PatchUpdate class also contains a few methods for reading the versionlist.txt and parsing out all the needed information, such as which patches to update and what version to set the program to after each installed patch file.

I did not also make the PatchUpdate updating itself automatically. Instead whenever the PatchUpdate software changes the new version of it will need to be integrated into the software that is using it as update solution. That could easily be done as a new ordinary patch for the software where the new version of the PatchUpdate jar file is bundled into the patch.

17 4.4.2 Graphical User Interface This section contains some of the design thoughts considering the graphical user design and information on how it is implemented.

4.4.2.1 Layout

This picture is a screenshot from the client software that shows how I decided to create the different side panels according to the layout picture in the requirement specification.

4.4.2.2 Layout Managers The Java API provides a wide range of layout managers that gives an “easy” way to layout components graphically. The benefit of using a layout manager is that components are “correctly” placed and positioned based on the operating system that the user is using. However, for the Firebolt prototype most graphical components use fixed sizes and predefined custom graphics. For most of the graphical component and containers we will be using absolute positioning by setting the layout manager to null and setting the bounds of each component individually.

4.4.2.3 Custom Graphical Components Since the application should have a fantasy game feeling of the user interface we cannot use the UI of the standard JComponent classes available in the Java Swing package or the classes available in the AW T package. We need to implement our own widgets that use custom designed graphics. This is done by extending basic Swing components such as JComponent or JPanel and overriding the paint() methods or by simply using no layout manager.

18 4.4.2.4 ImageButton The image button is a button widget that represents a button in the application. It extends the JComponent class and includes some methods and variables to represent it as a clickable button interface. The ImageButton contains a background image, mouse hover image and disabled image. It also contains a Boolean to show if the mouse cursor should change when hovering over the button. Sound for the button and actions for the clicking must be implemented by creating a MouseListener for the button.

4.4.2.5 ImagePanel The ImagePanel is a simple class that extends JPanel. It is created with an image that is drawn and scaled as background when the panel is repainted.

4.4.2.6 TexturedPanel This panel is similar to the ImagePanel except that it is created with a texture image that will not be scaled to fit the size of the panel. Instead it will be drawn as a texture, replicating itself until the panel is filled.

4.4.2.7 TextPane This is the main component of the application that handles displaying of colored text. It is an extended JTextPane with special methods for adding color coded text that is received from the server. The text that is received is parsed and added into the document of the TextPane with attributes based on the code in the text.

The parse method also checks for special codes representing TextObjects which are basically bundles of text representing an entity in the game such as an item or person. These are used with drag and drop so it is possible to drag a TextObject from the TextPane and drop it into the inventory list for example.

4.4.2.8 Equipment Panel This panel is able to display items from within the game such as swords and armors with graphical icons and colored text. The equipment panel is basically an ImagePanel containing a few extra components for displaying the icons of the items.

Each icon is able to contain an image for a particular item in the game. Whenever the user hover the mouse pointer over an icon the information for that particular item is displayed in a tool tip. This is easily done with the existing JToolTip class and MouseListener class that are available in the Java API.

19 4.4.2.9 Inventory Panel The inventory panel is a bit more complex than the equipment panel and involves a JList that uses a custom cell renderer to display the icons along with the text.

4.4.2.10 Drag and Drop Since it should be possible to drag things between the main textual window, the inventory window and the equipment window a drag and drop feature had to be implemented. This was done by creating special interfaces called ItemDnDAble and ItemDnDTargetListener for components that should be able to handle drag and drop. The drag and drop feature that is implemented is basically a simple implementation of the Java dnd package (java.awt.dnd).

4.4.3 2D Tile Based Map This component has taken a lot of time to implement and has been a large part of the project. It is an own package that is containing a bunch of classes to display and manipulate a graphical 2D tile based map. This map represents an overland wilderness view of the terrain around the character in the game. The map is composed from icons or sprites which are commonly called tiles. The tiles are small graphical images that represent a small part of the map. Together they form a larger image for the terrain layer of the map. There are several problems with creating good looking 2D tile maps which we will discuss and solve for the application.

4.4.3.1 TileHandler and Tiles Tiles are simple graphical images of a predefined size that together will create a larger image for the map. To handle these tiles I decided to create a class called TileHandler. It handles loading graphical images and storing them into a hashtable in the memory. A tile can then be accessed by a single call to the TileHandler. The TileHandler also includes some information about the particular tiles that are being used in the current setup of the tile based maps. It contains information about how to draw the tiles such as for example width and height. It is then easy to modify the size of the tiles in the map by changing the width and height in the TileHandler, which gives the ability to zoom on the map. The tiles are then scaled into the current tile size of the TileHandler when drawn on the map.

20 4.4.3.2 Handling Terrain Transitions A problem with 2D tile based maps arises when graphical images representing different terrains are placed next to each other to create a larger image for the map. Without some way of creating smooth transitions between different terrains on the map it will look blocky and artificial.

Terrain without transitions:

A brute force solution to this could be to create a special tile for each terrain to match other terrains when they meet on the map. However, a solution like that would require a huge number of tiles and it would not be possible to draw them with the resources available. Instead we use a similar solution to one proposed in an article by David Michael co-owner of Samu games [10] to handle terrain transitions.

We will create special templates for each tile terrain of the map. The template holds transition images for the edges of the tile. These are drawn on a transparent image so that the transition images can be drawn on top of the terrain layer without hurting the existing image.

Each terrain type is given a precedence integer which defines which templates that should overlap the others. A template with a higher precedence means that it will overlap lower precedence templates. The system is visualized in the image below:

Terrain precedence example:

4.4.3.3 Terrain Transition Template

The template follows a binary format. For the edges, west is considered "bit 0", north is "bit 1", and east and south are "bit 2" and "bit 3", respectively. Similarly for the corners, the northwest corner is "bit 0", the northeast corner "bit 1", and so on. How we arranged the actual terrain transition graphics is demonstrated in the figure above. If you think of the covered edges as 1 and the non-covered edges as 0, you can see that the columns proceed in normal binary manner: 0000, 0001, 0010, 0011, 0100, and so on.

With this method drawing the map is now a 2-step process. For each map cell (tile), the base terrain must be drawn, and then any transitions that overlay. For each tile on the map a loop will

21 go through the sides and corners of the tile and add bits into a bitset based on the adjacent tiles and their precedence. Finally the images will be drawn and a smooth transition will be present, removing the artificial blocky look of the original tile map.

The picture below shows an example of a map made with the drawing algorithms implemented for the client prototype. This map uses tiles with a size of 15x15 pixels.

4.4.3.4 Tile Templates The tile templates follow the format of the terrain transition template described above. Each terrain has its own template and is given a precedence number. An example template for the field terrain is showed here:

For Aeonfalls Online and the Firebolt client we use tiles of 15x15 pixels in size. However, the TileHandler and map drawing algorithms created for the tile map package are able to handle any sizes of tiles.

4.4.3.5 Larger Blocks of Tiles When drawing the maps with only one size of tiles (15x15 pixels) it is hard to visualize larger types of structures such as mountains and larger cities. To make it possible to display larger structures we have made a second type of tile template.

Mountain template:

This template contains a third row of information that includes a double sized tile that will be drawn on top of blocks of 4x4 similar tiles. This will make things such as mountain appear larger on the map with 1 single tile that replaces 4 smaller tiles.

4.4.3.6 Scrolling An important aspect of the graphical map display is how to allow fast and smooth scrolling. Most of the times the map will scroll a single coordinate in either direction when the player character moves. Redrawing the whole map for each move that the player makes is not a good solution. Instead copying parts of the existing image and only redrawing new additions of the map is a much better and faster way to scroll the map display.

22

W hen the map is scrolled one tile to the left (the player moves 1 tile to the left) the parts of the image that is currently shaded in the picture to the left is copied and moved the tile width pixels to the right. The empty space that is then found on the left edge (a column of tiles) is then repainted using a special column drawing method. Similar scrolling is implemented for north, east, west and south directions.

On a small map like in the Firebolt client which is approximately 12x12 tiles in size the speed improvement of the drawing is not directly visible on a computer of today’s standard. However, in a larger map that displays maybe 100x100 tiles this method of scrolling improves speed in a much appreciated way. Larger maps could for example be used in strategy games or in the map drawing tool for creating the game maps.

4.4.3.7 Icon Layer The 2D tile map panel does not in itself include a graphical layer for icons such as moving objects, players and vehicles. This must be implemented by extending the actual tile map panel and including a graphical layer for drawing these objects. For the Firebolt prototype an icon layer has been implemented for displaying players, non-players and items on the maps.

4.4.4 Networking Networking for the application is implemented with the mythicscape.aeonfalls.protocol package which is described in chapter 3. For the networking we created one large class called NetworkHandler which handles most of the connection, reading and writing to sockets and maintaining ByteBuffer objects for input and output. Another class called NetParser handles identifying received NetPacket objects and taking the correct actions based on their type.

4.4.4.1 NetworkHandler This class contains an incoming buffer for receiving bytes over the network and an outgoing buffer for appending bytes to send. It has a thread that handles sending data and a thread for reading data off the network. The networking is based on the java.nio package which uses a “non-blocking read and write” procedure. A SocketChannel is opened with an InetSocketAddress to the server. Reading and writing is then possible based on a read Selector and a write Selector.

4.4.4.2 NetParser The NetParser is a simple class that takes a NetPacket then based on its protocol and packet identifiers reads the data from the packet and sends it to the appropriate methods in the application. Basically the class consists of one method with a large switch-statement that splits up the different protocol and packet identifiers.

4.4.4.3 W hy the Java NIO package is used Using the java.nio package (New I/O) could be considered unnecessary. The ordinary java.io package would work with the blocking methods for reading and writing for the client application.

23 The reason we use the non-blocking version of the java.nio package is that it is used on the server as well and it makes it possible to read and manipulate ByteBuffer objects more easily using the same interpreter and protocol package on both the server and the client. The server uses the java.nio package for networking due to a more scalable architecture with non-blocking IO and more improved performance in the areas of buffer management. W ith the java.nio package the server only has one single thread for handling user connections whereas it needs to have a single thread for every user with the old java.io package. On a server with possibly several hundreds of users it could pose a problem. Managing and handling hundreds of threads is not, at least in my own opinion, very good performance wise or optimized software. Therefore we choose to use the java.nio package for the networking of both the client and server.

4.4.5 ImageHandler The ImageHandler is a class to easily access image files in the application. It is a single class that handles loading and storing images in memory. The ImageHandler is created with a path to a directory structure that will contain all the images it will handle. It is possible to construct the ImageHandler so that it will only load certain specific files into memory and to load images on the fly whenever they are called for. This is to reduce the amount of memory required for the application to run. The images are stored with their path and filename as keys in a hashtable. To access an image a simple call like the following is issued:

Image image = imageHandler.getImage(“GUI/theimage.gif”);

Depending on how the ImageHandler was constructed the image will already be loaded in memory (for quick access) or it will be loaded from disk when the method is called.

4.4.6 SoundManager The SoundManager is based on the JavaSound API and uses the Vorbis SPI to be able to playback OGG Vorbis soundtracks. The SoundManager consists of methods to read a stream from a sound file and play it in a separate thread. It is possible to play several sound files simultaneously. However, I have been having a lot of problems with simultaneous playing of sounds using the JavaSound API and have failed to find any good resources explaining how to make this efficient. By adding certain delays and yields in the sound threads I have been able to produce a sound player that works fairly well, but still with certain flaws in the field of simultaneous playing sounds which will need to be worked with more on in the future.

Since the game uses music for certain areas in the game and the player may switch from one tune to another rapidly I have also added a fading effect for musical tunes. It fades the currently playing music by lowering the gain and stops the play thread when it has reached below a certain value. Then the next music thread is allowed to start. This gives a smooth transition between music in the game.

4.4.7 AliasManager The AliasManager is a simple dialog that handles editing of aliases which are quick keywords that executes a longer command. The dialog contains a JList holding the different aliases and a few textboxes for editing the alias keyword and the commands. It also contains a checkbox for defining if the alias should be anchored such that it is only executed if it is typed at the beginning of a line or if it should be executed wherever it is typed.

24 Aliases are saved to file in textual form so that it is easier to change a whole alias file manually by opening it in a text editor or notepad.

4.4.8 Macros Macros are implemented in a hashtable with the access key being the integer number of a keyboard key number and the data as a String representing the command that should be issued when the key is pressed. The hashtable is then easily saved and loaded from disk through the Serializable interface available in the Java API. W henever a key is pressed (that lies outside the normal keys which cannot be added as a macro) the key code is checked against the hashtable to see if there is an entry for it available.

The interface for macros is accessed through a drop down menu from the main menu of the application. The drop down menu allows the user to open a previously defined macro set, create a completely new default macro list, save the current macro list, create a new macro and list the existing macro in the current set.

When creating a new macro the user is given a dialog box that says to press the key to add the macro to.

25

The user then gets an input dialog which has a text field for the command of the macro.

26 5 Evaluation and discussion

5.1 Results and Conclusion

The main purpose with this project was to develop a prototype of the Firebolt client for the upcoming Aeonfalls Online game by Mythicscape. A functional and working prototype was designed and implemented. Some features of the program took a little bit longer than expected to design and implement, such as the PatchUpdate and the 2D tile map drawing algorithms. Both of these particular features were designed in their own packages and are available to use in any future programs or games. I also created a webpage for PatchUpdate were its API is available to download and use free of charge for non-commercial software. It is available at http://patchupdate.mythicscape.com with a tutorial and documentation on how to use it.

During the project I have been forced to work a lot on the actual game server in connection to the work with the client prototype to be able to test all the different features. A lot of work has been put into modifying and extending the network protocol for the communication between the client and the server.

I think that I managed to fulfill all the higher level requirements for the application. The client uses functional networking and can connect to the server, send and receive input. By using almost exclusively custom graphics for most components in the software I believe I have managed to create a game interface that is appealing to gamers and is far from being similar to the standard windows applications and general mud clients. I have created a command line that saves a history of previously issued commands and also allows tab completion of words, alias manager for handling short abbreviation of commands and definable macro keys for accessing quick commands through single key presses. I also think that I fulfilled the high level requirement of having an update solution for the software with the PatchUpdate package that I created.

I have tested the application on my laptop (Intel Centrino 1.6 GHz with 512 MB RAM) and on another test computer (Intel Pentium 600 MHz with 255 MB RAM) and it runs smoothly on both systems although the speed of the textual panel is greatly enhanced with the more efficient computer. The download size of the full application is in the current state (when this document is written) approximately 17 MB in compressed format which is well within the requirements outlined in the specification.

I have tried to optimize the textual pane as much as possible and I think that the only limitations it has now with speed relies on the underlying Java API (JTextPane class) and their algorithms for adding attributed text to the widget. The speed of the text pane is well within the requirements for the specified systems. However, when testing the software on a lower machine (Pentium II 233 MHz) there are some serious issues with lack of speed.

I did not create the extra features mentioned in the requirement specification such as voice and video communication. There was not enough time for me to be able to work on them. In fact I believe this could be an own bachelor thesis in itself.

One of the requirements in the specification was to have everything configurable through a graphical interface. I did not finish this completely so this is something that needs to be worked more with in the future before a release of the software.

27 It was not possible to do a full testing of the program with the players available in the existing games by Mythicscape at this stage. This was mainly due to the fact that I did not finish enough of the client that it would be good to present it to the players, nor is the actual game server fully functional for game play. Most of the testing was done by me when I was doing the actual programming and designing and I have not included any test cases or benchmarking in the project report. However, I think I got rid of most of the bugs and flaws that arose throughout the development. It will be needed to run a larger and more complete testing on the product before releasing it to the public.

5.2 Future of the Client Prototype

The Firebolt prototype is functional and will be used with the game when it is finally released to the public sometime in 2005. Some features need to be finished on the server before they can be implemented into the client such as the friend list (ICQ-style), guild panel and the skill/spell panels. Most of the components that will be used to implement these features on the client side are finished and it will not take much extra work to get it working.

6 Appendix – Terms

MUD Multi-User-Dungeon or Multi-User-Domain. Refers to an online multi user game which usually is text-based, but not always. MMORPG Massive Multiplayer Online Role Playing Game. These games are usually commercial games with graphical interface and three dimension worlds. MUD Client A software program that is running on the user computer and enables the user to connect to a MUD server and play the game. Package A package in the Java programming language that bundles together classes and interfaces. Packet In this document this is referring to a packet of data sent over the network. Tiles Simple graphical images of a predefined size that together will create a larger image for a graphical 2D map. Thread A thread is a thread of execution in a program. The Java Virtual Machine allows an application to have multiple threads of execution running concurrently.

28 7 Appendix - Use Case Diagrams

7.1.1 Start Client This diagram shows the user case where the application is initially started.

7.1.2 Menu Manipulations This diagram shows the different use cases in connection with the menu manipulations.

29 7.1.3 Command Line Manipulations

30 8 Appendix - UML Class Diagrams This section contains class diagrams showing the relationships between classes in the source code. Only a few selected diagrams are present here that shows some of the most important classes.

8.1.1 PatchUpdate

8.1.2 ImageButton

31 8.1.3 TileHandler and Tile

32 8.1.4 TileMap2DPanel, TileMap and TileSector This is the class that represents the actual panel that the map is drawn upon. It extends the JPanel class and implements the ComponentListener interface so that it will redraw the map whenever the panel is resized.

33 8.1.5 NetworkHandler

34 8.1.6 SoundManager

35 9 References

[1] The Mudconnector, Internet 2004 http://www.mudconnector.com/mud_intro.html 2004-10-03 [2] EverQuest, Internet 2004 http://www.everquest.com 2004-10-03 [3] Dark Age of Camelot, Internet 2004 http://www.darkageofcamelot.com 2004-10-03 [4] W orld of W arcraft, Internet 2004 http://www.worldofwarcraft.com 2004-10-03 [5] Java 1.5.0, Internet 2004 http://java.sun.com/j2se/1.5.0/docs/index.html 2004-10-03 [6] Erling S Andersen. Systemutveckling – principer, metoder och tekniker (1994). Publisher. Studentlitteratur ISBN: 91-44-31042-0 [7] Sharune MUD, Internet 2004 http://www.sharune.com 2004-10-03 [8] Zuggsoft, Internet 2004 - ZMUD http://www.zuggsoft.com 2004-10-03 [9] Eclipse, Internet 2004 http://www.eclipse.org 2004-10-03 [10] Gamedev, Internet 2004 http://www.gamedev.net/reference/articles/article934.asp 2004-10-03 Responsible publisher: GameDev.net, LLC.

36