Next Generation In-game Message Interfaces

Next Generation In-game Message Interfaces Tobias Fritsch Freie Universität Berlin Takustrasse 9, D-14195 Berlin [email protected] +49 838 75250 ABSTRACT:

Instant messenger tools, such as AIM, MSN or ICQ have become fairly popular within the gaming community in the last years. On pair with the intensive use of game specific forums, these tools offer the player the keen advantage of having an individual buddy list with communication options outside the game. However especially next generation MMORPGs with full-screen playing option force the player to completely focus on the in-game chat mechanism. In order to create a satisfying solution for the current situation the parallel use of both applications at the same time is ineffective. This paper presents an integration of the AIM (AOL Instant Messenger) into the Eve-Online client. The integration includes an overview about the underlying network protocol OSCAR as well as a framework with interfaces towards gameengine and chat-protocol. With the very flexible and generic implementation the interfaces can basically be customized for any other games/ chatclient. Furthermore an online-survey concludes the most important information about player in-game chatting behavior. Author-Keywords:

Eve Online, In-Game Chat, Instant Messenger, Advanced User Interfaces ACM-Classification Keywords:

Interface Design, User Modeling Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. IUI 2007, January 28th–31st 2007, Hawaii

Jochen Schiller Freie Universität Berlin Takustrasse 9, D-14195 Berlin [email protected] +49 838 75212 1. INTRODUCTION

In the last years the importance of online games has significantly grown. An important evidence for this evolution is the still rising total revenue of the gaming industry that already exceeds the film industry by far (box-sales). Other evidences like growing social acceptance of gaming or professional/hardcore gaming (pro-gaming)[2] further reflect the increasing importance. As a part of this evolution the MMOGs (massive multiplayer online games), which offer the player a persistent virtual environment to compete in, have also seen a tremendous growth. In 1998 there were three released MMORPGs on the gaming market, meanwhile, 2006, more than 140 different titles already have been released; with even more to come. The current multiplayer games are divided into the following categories: FPS (first person shooter), RTS (real time strategy), MMORPG (massive multiplayer online role-playing game) and SG (sport games). Although each of the four types offers the player the opportunity to chat with others, there is still a significant gap in between them. Both FPS and RTS are dominated by a high in-game speed (often players in RTS games reach 80+ actions per minute). Such a rapid gameenvironment leaves less to no room for typing conversations during the action. Thus players tend to use voice communication tools like Teamspeak or Roger Wilco in order to coordinate activities better. But due to its extensive game nature, the significant importance of coordination and socialinteraction and the comparable low in-game speed we will focus on MMORPGs for now; although the general idea of integrated instant messenger tools is certainly not limited to a single game-type. A logical consequence of player interaction and group-orientated game content is the necessity for communication. Thus nearly every current multiplayer game features at least a chatting option; MMOGs often have private group and guild channels for further communication. Nevertheless every player has an individual social

preference; in-game buddy lists for instance offer a single player the opportunity to whisper (private chat) with online-buddies. The current situation however is not solving the underlying problem. Both in-game and other contacts are divided and often players need to decide whether to chat online or to use their instant messengers. Another significant flaw is the need to have an in-game client in order to stay in contact with other playbuddies while they are playing. This paper aims to find an in-game solution for the instant messenger problem. Therefore we create a generic framework that is capable of supporting the basic chat functionalities (send, receive, authenticate, etc.) and that also offers several interfaces towards the gaming client in order to visually integrate the messenger into the game. An important goal is to design a template for further implementations, which is neither limited to a certain game or chat-platform. Finally an online user-survey is designed to lighten up some of the important chat related gaming-aspects. The rest of the paper structures as following: Section 2 contains background information about Eve-Online (the target MMOG to implement the in-game chat) as well as a general introduction; Section 3 features our research approach, including the underlying protocol decision towards OSCAR and the design of the online survey. In Section 4 the framework implementation is shown, this also includes an analysis of the survey results. Section 5 gives an overview about related research material; finally Section 6 concludes the main findings and contains an outlook about upcoming work. 2. BACKGROUND

Different instant messengers feature similar techniques in order to offer live chat possibilities. Nevertheless, before taking a closer look at the current generation of instant messengers, one must first consider the underlying online games and their communication features. 2.1 EVE ONLINE

The setting of Eve Online is a space universe, where the player takes the role of a pilot. One is capable of designing ones individual space-ship and character abilities. Furthermore, the player has the option to follow various tasks, ranging from freelancing up to player vs. player activities. The game world (universe) is divided into different zones that are hosted by one of eight main servers. Like other MMORPGS, it shows the need to keep the players busy and balance the load in between the game world.

Eve Online is a so called second generation UMMORPG (Ultra Massive Multiplayer Online Role-Playing Game). The game itself shows similarities towards the traditional MMORPGs, however, there are important differences. On the one hand the game is called U-MMORPG, because it does not feature different shards and thus does not divide the game world into several parallel running realms. The result is a single realm with up to 25000 simultaneously playing users online. As a result of that, the chat volume exceeds the already high amount of other MMORPGs by far. The in-game client offers separate individual group, clan, and private channels as well as public ooc (out of character) and trade channels. Like in other second generation MMORPGs one can have a list of ingame buddies to directly communicate with (private chat). The buddy list does not include real-life friends and it also does not offer the opportunity to leave an offline player a message. In-Game Public Chat: Out of Character Trade Guild Group In-game friends (no out-of-game chat options)

In-Game Private Chat: Buddy List Private Messages Out-of-game friends that are playing the game

Out-of-Game Private Chat: Chats (IRC) Instant Messangers EMail Out-of-game friends that are not playing the game

Figure 1. Illustration of the current chat situation in MMORPGs

As one can see in figure 1, the current problem relies on the fact that the player is not capable of chatting with in-game friends meanwhile he is not online (except he/she has separately added them to their E-Mail / IM buddy list). Furthermore, while playing in full-screen mode, offline real-life friends and those who are not playing the game are also not available. The general idea should be to merge both in-game and out-of-game individual contact lists in order to give the player the opportunity to be most flexible while playing and even while using only his/her instant messenger. 2.2 INSTANT MESSENGERS

Current instant messengers do not only offer the pure service of exchanging messages over a network. Generally speaking they allow the user to communicate with others in real-time by using the form of text-based messages. The clear contrast to the classical e-mail communication relies in the fact that the messages are being sent by one user and received at the same time (besides delay, network loss, etc). In order to prevent constant

requests (by the potential receiver) a push mode is used. Thereby the server pushes the messages to the clients’ software whenever a new message is send. Another important aspect is the option to register other users as buddies and build an individual friends list. Each contact has its own chat-history and status; therefore, the user can see who is online and available and even (depending on the protocol) leave offline contacts messages. The buddy-list update is also done by the pushmode in order to minimize network traffic (especially with larger friend lists). During the last years the evolution of instant messengers has seen a significant growth and current clients are capable of transferring files (peer-to-peer sharing). Furthermore, audio- and video-chat options are also available.

Figure 2. Current AOL IM version. Left window shows the buddy list, right window is the ongoing instant message chat.

Not all of the mentioned features are necessary to improve the chat-situation in MMORPGs. A voice and video communication would increase the options in a player group and even give them an advantage towards the game-content. Although such a feature should be optional for now, not every player has a microphone and the bandwidth of a multi-user video chat can easily exceed the capacity of a current DSL/Cable connection. Therefore we will focus on the instant text message in-game integration. Section 3 contains further information about the protocol of the AIM. 3. RESEARCH APPROACH

By creating the integration for instant messengers into an MMORPG our main idea was a most flexible solution, which is generic and expansible for both new instant messengers and new MMORPGs. The current work however focuses on the integration of a single IM (the AOL instant messenger) into a target MMORPG. Furthermore,

a survey about users’ chat behavior in MMORPGs should give a deeper insight and point out which features might be required to further improve the existing user interfaces. 3.1 AOL IM INTEGRATION

Before taking a closer look at the general idea of a next generation in-game message interface, one must first analyse the given structure of the target instant messenger (AOL IM). The AIM (AOL Instant Messenger) was initially only available for AOL customers, however, from 1998 on the IM was opened up for a wider audience (regardless if one is AOL customer or not). On pair with ICQ (which uses the same underlying protocol), the AIM is available for every common operating system (including mobile systems). In 2006 AOL opened the AIM for third-party applications, such as the in-game interface (based on the given AOL SDK). Generally, AOL and ICQ use a single closedsource protocol called OSCAR (Open Service for Communication in Real Time). Several servers are organized in the accordant network: one central authorization server and several BOS (Basic OSCAR Service); figure 3 illustrates the login procedure. However, there is no reliable and official documentation available; although since the SDK for third-party applications was released there is a second protocol. The TOC (Talk to OSCAR) protocol is a text-based wrapper that uses gateway servers to translate TOC commands into OSCAR packets and vise versa. Hence its complexity is reduced towards the basic IM features (like login, send, receive and buddy-list functions).

Figure 3. Login at central authorization server, by submitting the password successful one receives a cookie and is redirected towards a BOS.

Eve Online on the other side uses its own in-game message protocol. Since the in-game chat mostly does not interference with the IM-chat the integration can focus on pure text messages. However, it is possible to send XML links ingame, by linking certain items that are viewable by other players in small pop-up windows. One can send these XML-tags with the OSCAR protocol; sadly the current clients are not capable

of presenting it correctly. The interfaces towards the game should also be as generic as possible and thereby support other games as well. Section 4 contains a detailed implementation and UML diagram. The basic approach can be seen in figure 4; the Eve Online client offers the possibility to use a part of its interface in order to login and use the IM chat integration functionality to send plain text packages to the TOC gateway server. Thereby a player does not need to have a separate ICQ or AIM running and can still communicate with other friends (those currently playing and those only online in the IM).

Figure 4.Integration of the AIM into Eve Online. Communication is done through simple TOC commands. 3.2 USER SURVEY APPROACH

The design of the user survey is one of the most important decisions, because both the content and the implementation have a clear impact on the result. In this case we decided to use an online user survey with a questionnaire and an underlying database system. The noticeable advantage of online surveys is the large number of participants and thus the more reliable results. However, one should keep in mind that without a tight IPcatching system or a user-account system one can not prevent users to fill the survey more than once. Nevertheless the huge advantage of having a large (and thus reliable) survey prevails over the disadvantages. To prevent cheating and unnecessary entries certain combinations were removed from the data set before analysing the results (such as 15 years old widows, etc). The design of the survey includes four parts: ingame questions, out-of-game questions, cross communication and deterministic values. Thereby most of the questions (except the deterministic values) use a version of the MOS (mean opinion score), where the user rates a feature by statements that are converted into numbers later. Part 1, 2 and 3 use this system to classify the frequency of interaction through certain media (like e-mail, voice chat, instant messengers, etc). The given values are 1 equals often, 2 equals occasionally, 3 equals seldom and 4 equals never. Each of the

three parts has its own background; the in-game questions aim to understand how the player chats while using his game, the out-of-game questions enlighten the way the user behaves when not playing and the cross communication section asks about additional communication methods while playing (in order to improve the current situation). Finally, part 4 concludes the most important deterministic values (such as age, gender and location). The survey aims to underline the current situation in MMORPGs with numbers to understand which of the features of crosscommunication is missing and if there are statistic correlations towards the basic deterministic values. On pair with the questionnaire the technical implementation includes ASP (Active Server Pages) and a database system; unlike in a poll one can create dynamic pages with different language sets [1], [2] (especially important in larger surveys). The underlying database model (see figure 5) contains following entities: (1) Survey – holding the different surveys; (2) Questions – the overall amount of questions; (3) Answers – possible answer structures and (4) Users - user ID and related data. As the ER- (entity relationship-) model shows, all entities are connected through a single central relation. Compared to a file system, the database offered various benefits like faster accessibility. Especially the statistical analysis was simplified, even with the huge amount of data. Questions PK

QuestionID Que_has Ans

Sur_has_ Que

Question kindOf Survey PK

ID

Answers Results

SurveyName Language

PK

AnswerID Answer

Users PK UserID email username password

Figure 5. ER-model of the underlying database. 4. ANALYSIS

Before taking a look at the results of the user survey, one should first examine the implementation of the IM integration and its UML diagrams. Unfortunately the cooperation with CCP-gaming (producer of Eve Online) broke up right before the IM could be integrated into the

game; thus the screenshot is a stand-alone client that uses the given interfaces towards the gaming software. However, due to its generic implementation the software could be used for any type of MMORPG. 4.1 INGAME INSTANT MESSENGER

As one can see in figure 4, the instant messenger application offers the game (Eve Online) several basic interfaces and chat functionalities. On the other side it uses the TOC protocol to communicate with the gateway servers (which translates the plain-text commands into the OSCAR protocol). The general generic design of the IM-Interface is shown in figure 6, where the Eve Online Client uses the IM-Interface.

Figure 6. General connection between the Eve Online Client and the IM Interface. The implementation of the interface is based on the CoreLibs of the AIM SDK.

Through its basic command structure the game client has plenty possibilities of implementing the graphical part of the user interface, either by using the standard buddy list options with separate popup windows and mouse support or by breaking it down into an IRC text based chatting system. Anyway the IM-Interfaces remain the same; once the commands are called at the Interface, it uses

the AccCoreLib that is provided by the AIM SDK. The IM-Interface design is split into three main classes: ClientManager, ClientInterface and BuddyList. As one can contemplate in figure 7 those classes form the centre of the UML diagram. By further regarding each of the mentioned classes one will see the distinct function that each of them fulfils. The ClientManager is responsible for the authentification; thereby it is vital that only one instance exists parallel. It handles the login with (client, username and password) by creating an appropriate ClientInterface. Yet the options are limited to AIM interfaces, but the generic structure easily allows a further integration of any other client. The ClientInterface on the other hand is responsible for a direct communication with the gateway servers (in our project those servers are the TOC gateway servers). It uses the TOC command structure in order to send and receive the data from the network, hence offering all necessary interfaces towards the TOC servers. An Example would be a simple send operation, where the GUI calls the required method at the ClientManager, which gets the destinations username and protocol. Afterwards the ClientManager directly communicates with the target Client (such as the AIMClient). The Client itself sends the TOC command towards the gateway servers, from where it is interpreted as an OSCAR command. Therewith it supports the basic functionality and updates the client status whenever needed.

Figure 7. UML diagram showing the three core classes ClientManager, ClientInterface and BuddyList. The ClientInterface is an expendable interface for further client types, such as the MSN client.

However, as soon as buddy list relevant operations are performed the ClientInterface cannot directly access the BuddyList. Again the buddy list contains all buddies, including those from different client interfaces (stored with username, display-name, client and buddy-state) in order to be as expansible as possible. For this reason only the ClientManager can access the BuddyList. As an example the augmentation of a new buddy would require the ClientManager to select a specific ClientInterface (such as the AIMClient). Thereby the selected client sends the appropriate command towards the TOC gateway servers. As soon as the acknowledgment returns the ClientManager administrates the buddy list, adding the new buddy with the appropriate parameters. The IM-Interface was intentionally designed to fit into the Eve-Online client; however through the missing cooperation in the end it was not possible to integrate the client into the game. To proof the functionality we used a simple UI on our own, thereby testing the features that are available for the games. An example of how the final interface might look like can be seen in figure 8 (the screenshot of our stand-alone UI). It is implemented in Java and contains all the basic features.

Figure 8. Stand-alone UI of the IM-Interface; one possible graphical representation.

As a requirement for in-game support a user needs an existing account, however it should also be possible to create one account in real-time by using the in-game user data. As a vision it should be possible to support multiple clients at the same time. Nevertheless that would require the user to create an account or have an existing account for every IM if he/she wants a complete buddy list

4.2 SURVEY ANALYSIS

The survey contains more than 1000 different answers; the data indicates a familiar deterministic distribution. The keen majority of participants are male (92.6%) and tend to play a significant amount of time (70% play more than 10 hours a week) – for further information about hardcore gaming behavior we refer to [2]. Also the age distribution does not significantly differ from other surveys (shown in figure 9); far the most players are between 16 and 25 years old.

Figure 9. An overview of the age distribution in the underlying survey. X-axis indicates the users’ age in years.

The survey itself was limited towards the MMORPG scene, therefore the answers about chatting behavior did not significantly differ in between the games; no statistical significant correlation between communication and a special game could be shown. However, especially the assumed need for third party IM application was clearly underlined. Thereby the dominating ingame communication method was the chat and personal messages, in both cases more than 70% of the users agreed to use them more than occasionally in order to communicate with others. Especially interesting was the recognizable amount of communication with friends while playing. Figure 10 illustrates that more than 50% communicate with friends (even if they are not playing the same game) while playing. The amount of non-known player communication shows the lowest distribution, social structures like in [3] are clearly recognizable in every current MMORPG. The demand to communicate with friends is further underlined by the fact that most of the communication is done through instant messengers. The buddy list feature, the fast and easy communication method and the instant replies favour this communication feature over

others like e-mail or voice communication. In combination with figure 11 one can recognize the huge impact that instant messengers have on the player communication.

order to discuss personal topics. 5. RELATED WORK

User interfaces is one of the most discussed topics in computer science overall, since their impact on user performance is significant. Thereby one can find a sizeable collection of related topics towards improved user interfaces. In order to select the most closely related ones we will focus on three approach categories: 5.1 USER SURVEYS

Figure 10. Overview about the communication behavior while playing the game. A majority also communicates with friends while playing.

Like in other sections of computer science the user has a distinct impact on the design through its personal needs. This impact is even significantly stronger when it comes to user interfaces. Thus user analyses form the substructure in order to understand the personal needs. Especially gaming orientated surveys show a trend towards explicit hardcore orientated gaming behavior (playing more than 8 hours each day) [2]; such a behavior moves the social interaction mainly into the virtual environment. As a result of that players find themselves having a distinct behavior in the virtual and real world [1]. Underlying approaches try to understand the motivation of MMORPG players and their social interaction. The design of user interfaces can also greatly profit by taking these results into account. Each of the persistent online worlds (like Everquest) forms its own set of behavior rules and its own language and communication base [3]. Depending on the individual motivation of the user [4] one can classify them into certain playertypes and thereby predict their online (chat) behavior better. 5.2 USER INTERFACE IMPROVEMENTS

Figure 11. Distribution of communication with out-of-game contacts with an instant messenger while playing at the same time.

Even further underlying this trend more than 70% would agree to have IM-communication in-game to make the cross-communication easier. Concluding the main findings one can see that the deterministic values of the test-group do not significantly differ from other surveys. The combination of a very frequent instant messenger use for out-of-game communication as well as the high demand to stay in contact with friends (even when playing) clearly underlined our assumptions. Further analysis of the topics show that especially personal issues are not discussed with onlineplayers; therefore even when playing there is a large demand to use the given internet resources in

Nearly every current application has a graphical user interface; hence the research is not limited to games. Every culture however prefers individual flaws and styles that also influence the design of the underlying user interfaces. A study towards the international difference in web-design [5] indicates noticeable differences in style, color and content. Similar observations can be made in the gaming sector, where local publisher often change the package or the initial interface, in order to fit the local standards. On pair with chat interfaces, language also has a broad impact on the chat. The interpretation of chat language is also not only limited to games, instant messengers feature a large list of common face marks and replace them by pictures to lighten the text up. Such a classification [6] helps to express emotions (and gestures) in the text better. Next generation games already feature certain

emotes that are linked to common text passages (like letting the character laugh, when the user types “lol”). Another important aspect is the migration from one platform to another. Not only the merge of existing technologies; furthermore the migration towards smaller devices [7] (like mobile end-devices) has a significant impact on the current user interface design. 5.3 INSTANT MESSENGER

Every instant messenger has its own underlying protocol; most of them are business solutions. However since 1998 the open GNU project Jabber offers a set of XML based network protocols with a main focus on instant messaging [8]. Beside the core protocol, Jabber also offers the Jabber Enhanced Protocol (JEP), which extends the basic functions. The underlying Jabber network supports different servers that can communicate with each other, leaving behind the traditional one server architecture. As a next generation instant messenger Google Talk uses the Jabber network. Another important aspect is the design of multiprotocol applications that support the different messengers. As examples one can find Trillian [9], Gaim [10], Adium [11] and Miranda [12]. The given examples use the underlying network protocols and offer a single user interface to combine them all. Those interfaces can be used to improve the in-game chat-client, in order to support all common instant messengers. 6. CONCLUSIONS

This paper introduces the problem of parallel chatting in the current MMORPG scene. Most of the players can not chat with fellow players ingame, while still staying in contact with their reallife friends and out-of-game contacts. After giving a brief introduction into Eve Online (a UMMORPG) and the current IM-clients we introduced our IM-Interface. It is a flexible solution that can be integrated in every userinterface of current games, giving the player the option to chat with the AIM while playing. After describing the initial approach we summarized the actual design of the IM-Interface by giving an overview about the three core classes ClientManager, ClientInterface and BuddyList. Especially the ClientInterface class is designed as generic as possible in order to have the opportunity of implementing other clients like MSN or YahooChat. Furthermore simple examples like sending or adding a buddy described the functionality of the Interface. Finally the prototype (a stand-alone GUI) included all the basic functionalities. The online survey again underlined the demand

for an in-game IM integration by showing that the keen majority of players tend to use chat or instant messenger applications and that even while playing there is still a high demand (for various reasons) to chat with friends (mostly by using IM technology). Therefore our assumptions turned out to hold true. The current instant messenger user interface integration certainly has not come to an end yet. The received data from the survey clearly indicate the need for a combined technology in order to offer the user a most flexible chat-solution. The current design still needs a general multi-protocol implementation to support all common protocols. Another important aspect is the in-game integration of sound; negative examples like counter-strike have shown that team-sound is not always accepted by the players (more than 80% turned the option to audio-chat with others off). A deeper analysis and improvement of the current chat client interfaces are still needed. 7. REFERENCES 1. Fritsch T., Voigt B., Schiller J: Personal Behavior and Virtual Fragmentation, IWIC 2007 in Kyoto, Japan (25th-26th January 2007) 2.

Fritsch T., Voigt B: Distribution of Online Hardcore Player Behavior, Netgames 2006 in Singapore (30th-31st October 2006)

3.

Mikael Jakobsson, T. Taylor: The Sopranos Meets EverQuest, Social Networking in Massively Multiplayer Online Games, Melbourne, DAC2003

4.

Bartle R., Hearts, Clubs, Diamonds,Spades: Players who suit MUDs, 1996 http://www.mud.co.uk/richard/hcds.htm

5.

Marcus A., Gould E.: Cultural Dimensions and Global Web User-Interface Design: What? So What? Now What? HFITW 2000 in Texas (19th June 2000) http://www.amanda.com/resources/hfweb2000/hfw eb00.marcus.html

6.

Tanaka Y., Takamura H., Okumura M.: Extraction and classification of facemarks. IUI2005 San Diego, California, USA (January 10th-13th 2005)

7.

Massó J., Vanderdonckt J., López P.: Direct manipulation of user interfaces for migration. IUI 2006 Sydney, Australia (January 29th - February 1st 2006)

8.

Jabber Foundation: http://www.jabber.org/jsf/

9.

Trillian: http://www.ceruleanstudios.com/

10. Gaim: http://gaim.sourceforge.net/ 11. Adium: http://www.adiumx.com/ 12. Miranda: http://www.miranda-im.org/