Extending a Closed-Source Game with Multiplayer Functionality
Total Page：16
File Type：pdf, Size：1020Kb
University of Nevada, Reno Extending a Closed-Source Game with Multiplayer Functionality A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science with a major in Computer Science. by Mark Harmer Dr. Bobby D. Bryant, Thesis Advisor December 2010 THE GRADUATE SCHOOL We recommend that the thesis prepared under our supervision by MARK HARMER entitled Extending A Closed-Source Game With Multiplayer Functionality be accepted in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE Bobby D. Bryant, Ph. D., Advisor Sushil J. Louis, Ph. D., Committee Member Jennifer Mahon, Ph. D., Graduate School Representative Marsha H. Read, Ph. D., Associate Dean, Graduate School December, 2010 i Abstract The process of adding additional functionality to closed-source applications is gener- ally not well known. This thesis covers the motivation, tools and design for extending a game with multiplayer functionality. The purpose of this thesis is to introduce the back- ground concepts and methods needed towards implementing functionality changes within any application. Since games attract a variety of fields relating to graphics, user interfaces, storage, artificial intelligence, networking, audio, etc. they are best suited to display the ability to add additional functionality. Games are also a great motivational tool towards developing extended functionality because the results can easily be shown to people that are not experts on the application. The game of Torchlight is chosen as a real-world target application for added function- ality. Multiplayer functionality is added to the otherwise single-player, closed-source game. Multiplayer on the game of Torchlight is shown to be working. ii Acknowledgements I would first like to thank my advisor, Dr. Bobby Bryant for his support through this thesis. Additionally I want to thank my commitee, Dr. Sushil Louis and Dr. Jennifer Mahon. I would also like to thank Runic Games for making such a great game to base my work off of and the awesome Torchlight player community for their constant motivation. My thanks to my friends for their distractions (both good and bad) from this project. And finally, I want to thank my family for their continued support. Windows is a registered trademark of Microsoft Corporation in the United States and other countries. Torchlight is trademark of Runic Games. iii Contents Abstract ii Acknowledgements iii List of Figuresv 1 Introduction1 2 Background3 2.1 Torchlight.....................................3 2.2 Genre History...................................6 2.3 Modding......................................7 2.4 Motivation for Multiplayer Extension for Torchlight..............7 2.5 Reverse Engineering...............................8 2.5.1 High- to Low-level Code.........................8 2.5.2 Low- to High-level Code.........................9 2.5.3 Call Stack................................. 10 2.5.4 Virtual Functions............................. 11 2.5.5 RTTI and the vtable........................... 12 2.5.6 Function Pointers............................. 14 2.5.7 Patching Code at Run-Time....................... 14 2.5.8 Trampolining............................... 14 2.5.9 Dynamically Linked Libraries...................... 15 2.6 Previous Work.................................. 15 3 Torchlight API 17 3.1 Motivation..................................... 17 3.2 Overall Design................................... 17 3.2.1 Re-creating Data Layouts........................ 17 3.2.2 Event System............................... 18 3.3 Methodology................................... 19 3.3.1 Memory Locations............................ 19 3.3.2 Hardware Breakpoints.......................... 19 3.3.3 Obtaining Class Data Layouts...................... 20 3.3.4 Software Breakpoints........................... 21 3.3.5 Obtaining Function Details....................... 21 iv 3.3.6 Accessing Function Arguments..................... 23 3.3.7 Patching Mechanism........................... 24 3.3.8 Event System: Exposing Event Callbacks................ 25 4 Torchlight Multiplayer 27 4.1 Purpose...................................... 27 4.2 Overall Design................................... 27 4.3 Networking.................................... 28 4.4 User Interface................................... 29 4.5 TLAPI and Callback Functions......................... 31 4.6 Town Phase.................................... 31 4.6.1 Character and Item Synchronization.................. 32 4.6.2 Chat Interface............................... 35 4.7 Dungeon Phase.................................. 36 4.7.1 Level Transfers.............................. 37 4.7.2 Synchronizing Interactable Objects................... 37 4.7.3 Attacking................................. 38 4.7.4 Character Deaths............................. 39 4.7.5 Character Resurrection.......................... 39 4.7.6 Experience................................. 40 4.7.7 Placement new .............................. 40 4.8 Debugging..................................... 41 4.9 Overview...................................... 43 5 Results 44 5.1 Town Phase.................................... 44 5.2 Dungeon Phase.................................. 44 5.3 Overall Playability................................ 47 5.4 Future Work.................................... 47 6 Conclusion 48 v List of Figures 2.1 A screenshot from the canonical single-player game of Torchlight in the Town level. The player's character is always shown in the center of the screen....5 2.2 Compilation Process from a C++ input file to the Assembly code and final executable......................................8 2.3 A screenshot of the IDA Pro software used to aid in the reverse engineering process....................................... 10 2.4 A representation of a stack frame for a function. level, x, z are arguments passed into the function. The return value is stored so the function knows where to send program control when complete. Local variables needed within the function are stored on the stack as well................... 11 2.5 C++ class and vtable layout in memory..................... 13 2.6 Partial RTTI layout and pointer to the RTTICompleteObjectLocator from the vtable...................................... 13 2.7 Example of trampolining a function call into the intended, original function from the target application............................ 15 3.1 Memory layout of a CList class discovered in Torchlight. The CList class is one of the more simple classes discovered and re-engineered.......... 18 4.1 A screenshot of the multiplayer options screen.................. 30 4.2 A screenshot of the multiplayer join screen.................... 31 4.3 A screenshot of the multiplayer lobby screen................... 32 4.4 Multiplayer within the Town. The player's character is shown in the center of the image and the second player's character is shown on the left...... 33 4.5 Sequence diagram of the initial messages between the server and client game instances...................................... 34 4.6 Item synchronization as seen by the server player. Three items have been dropped to the ground by the client character.................. 35 4.7 Item synchronization as seen by the client player. The same three items are shown to the other player, displaying item synchronization........... 36 4.8 A door (trigger unit) is highlighted and available to a player to interact with. 39 4.9 The same door shown as opened by the other player, displaying the synchro- nization of the trigger units............................ 40 4.10 Microsoft Visual Studio running as the Just-in-Time debugger for Torchlight after a crash occurred. The disassembly of the instructions around the current instruction are shown, as well as memory of the stack.............. 42 1 Chapter 1 Introduction Many games are built with only single-player capabilities. Generally, these games lack mul- tiplayer capabilities because the developers chose to keep the design single-player only; lack of development time and resources may also be a factor. The amount of time a player may want to invest replaying a game can be described as replayability. Single-player function- ality can be a defining factor for replayability because of the predictive nature of the game mechanics and entities. The only opponent a player encounters is a computer controlled entity, which tends to only show a static pattern of behavior. A player may play through a game once or twice before they become familiar with how the computer responds. Supple- menting these computer controlled players with actual humans adds social interaction and much of the predictive nature is removed. Adding multiplayer capability to any game is not only technically challenging, but requires a fundamental design change of how the game will be played. No longer are all the characters idly standing by waiting for the human player to interact with them; human players can be added to the world to interact with other players. Design changes are required to enforce how multiple players can interact with the environment cooperatively and competitively. This thesis shows the techniques and results of an undertaking to add multiplayer functionality to the game of Torchlight, created by Runic Games. Torchlight is a commercial, closed-source game. For commercial game business models, the source code is usually not released, which complicates any game functionality modifications such as adding multiplayer functionality. It is shown here that the process