Taktická hra pre viacej hráčov Tactical Multiplayer Game

Transcription

1 Charles University in Prague Faculty of Mathematics and Physics BACHELOR THESIS Ján Kis Taktická hra pre viacej hráčov Tactical Multiplayer Game Institution: Department of Software and Computer Science Education Supervisor: Mgr. Cyril Brom, Ph.D. Study branch: Theoretical informatics 2009

2 I would like to express a sincere gratitude to my supervisor Mgr. Cyril Brom, Ph.D. for the guidance he gave me throughout the work on this thesis. I also gratefully acknowledge Adam Hraška for his willingness and readiness to help and all the others who took part in the prototype testing. The work on this project was partially supported with the grant Information Society with project number: 1ET I hereby certify that I wrote the thesis myself, using only the referenced sources. I give consent to lending the thesis. Prague, 29. mája 2009 Ján Kis 2

3 Obsah 1 Introduction Tactics games What is UFO? Specification Thesis aim Prototype requirements Project course Time Flow Systems Real-time Turn-based Time flow with two phases Time flow with limited pause Summary Game Design Overview Command execution Squareness of the game Metric RPG Vision & Shooting Pausing support Implementation XNA Game loop and prototype structure Networking Path finding Graphical user interface

4 OBSAH 4 6 Results Testing background Survey Observations Summary Conclusion 35 A User manual 37 A.1 About the game A.2 Prerequisites A.3 Installation A.4 Quick Start A.5 How to set up the game A.6 Soldier A.7 Game items A.8 What you see in the game A.9 How to create a map A.10 Controls B Calculations 54 B.1 Skills and stats B.2 Vision B.3 Shooting C Survey 65 Bibliography 67

5 Názov práce: Taktická hra pre viacej hráčov Autor: Ján Kis Katedra (ústav): Kabinet software a výuky informatiky Vedúci bakalárskej práce: Mgr. Cyril Brom, Ph.D. vedúceho: Cyril.Brom@mff.cuni.cz Abstrakt: Taktické hry, ako napríklad UFO od spoločnosti Altar Interactives, sú v súčasnej dobe populárne. Najdôležitejší prvok hry UFO je možnost plánovat akcie jednotiek v čase, ked je hra pozastavená. V posledných rokoch hry pre viacej hráčov zaznamenali prudký rozvoj. V súvislosti s týmto rozvojom sa objavujú otázky typu:,,ako by mal vyzerat mód pre viacej hráčov k taktickým hrám podobným hre UFO? Odpoved na túto otázku sa snaží nájst táto práca. Práca skúma a navrhuje viaceré možnosti ako implementovat mód pre viacej hráčov v taktických hrách. Najväčším prínosom práce je prototyp hry, ktorý bol vytvorený za účelom overenia zábavnosti a hratel nosti navrhnutého dizajnu. Kl účové slová: viacej hráčov, taktické hry, ufo Title: Tactical Multiplayer Game Author: Ján Kis Department: Department of Software and Computer Science Education Supervisor: Mgr. Cyril Brom, Ph.D. Supervisor s address: Cyril.Brom@mff.cuni.cz Abstract: The tactics single-player games like UFO from Altar Interactives are quite popular in these days. The most notable feature of UFO is that the actions of game units can be planned in advance by the player while the game is paused. During the recent boom of multiplayer games a question arose of what should a multiplayer to a game such as UFO look like. This project addresses the question and discusses several possibilities of the multiplayer design to such a game. The main contribution of the project is the actual game prototype which tests the viability and entertainment of the multiplayer design introduced by the thesis. Keywords: multiplayer, tactics games, ufo 5

6 Chapter 1 Introduction During the past few years the gaming industry has tremendously evolved and it is not only the graphical part which has constantly improved. For example, the computer networking technologies have progressed rapidly as well. As a result, the games started offering the multiplayer mode which in these days is highly demanded and for many gamers it is almost a must have criteria on a computer game. Another area of games which has developed and shaped is the various game genres. Among them the strategy games have also evolved and later on the new genre of tactics games derived from strategies. Regardless of all the progress, there still are many areas in gaming industry which are not so advanced and need further exploration. For example, the multiplayer mode to tactics games. Although at present there are many successful tactics games on the market, they either do not have a multiplayer variant or it is not at all entertaining. This thesis closely analyzes the options of implementing a multiplayer mode to a tactical game and proposes a less common design which should overcome the shortcomings of existing solutions. This chapter should provide the necessary information for understanding the thesis and its objective. First of all, one has to be familiar with tactics computer games as well as the pros and cons of the genres derived from them. The tactics games are introduced in Section 1.1. Furthermore, it is good to have a basic picture of a game series called UFO since the prototype of a game created to support the thesis is based on UFO. Section 1.2 explains relevant features of UFO. 6

7 CHAPTER 1. INTRODUCTION 7 Structure of the thesis. Chapter 2 specifies the objective of the thesis as well as the requirements of the game prototype. Chapter 3 deals with possible time flow systems for the prototype. The design of the game is briefly examined in Chapter 4. The most interesting aspects of the implementation from the developer point of view are introduced in Chapter 5. Chapter 6 is devoted to the achieved results and information gained during the prototype testing. Finally, the possible future enhancements as well as the final summary is presented in Chapter 7. A user manual can be found in Appendix A. The most interesting calculations like vision and shooting calculations are introduced in in Appendix B. Appendix C shows the questions of the survey which was part of the testing. 1.1 Tactics games Nowadays the genre of tactics games is quite popular. However, it is frequently confused with the genre of strategy games. The essential difference between strategy and tactics gameplay is that the latter focuses above all on the battle itself rather than production of units and harvest of resources. Thus, the number of units is often fixed or considerably limited. It is not unusual for a tactics game to simulate a specific war situation and to implement a realistic or at least believable behavior. This genre can be further divided into real-time tactics (RTT) and turn-based tactics (TBT) Real-time tactics In RTT, as its name suggests, the time flows as in the real world. That means that at the same time all players can interact with the game and the actions of all players are executed simultaneously. The actual game is inclined to become a race in giving out commands and lacks the tactics part Turn-based tactics TBT games are played as chess where the player can interact with the game only during his own turn. The duration of the turn is usually not limited. However, the number of actions often is restricted. TBT can be considered a more tactical genre than RTT since it offers a plenty of time for the actual tactics.

8 CHAPTER 1. INTRODUCTION Multiplayer RTT and real-time strategies (RTS) have a great potential in multiplayer mode. Games like Warcraft III and its custom scenario Defense of the Ancients (DotA) are world-wide sought-after today. What makes the multiplayer so captivating is the fact that players compete against other humans rather than a form of artificial intelligence. What s more, the ability to communicate with other players makes it a form of a social event. The multiplayer mode in TBT in comparison with RTT is hardly entertaining. Its greatest disadvantage lies in the turn-based character itself. Most of the players are annoyed and bored by the non-interactive time period between two turns. 1.2 What is UFO? In the context, UFO stands for a series of games from ALTAR Games. It represents three titles, namely UFO: Aftermath, UFO: Aftershock, and UFO: Afterlight. The genre of UFO might be classified as both, real-time strategy and real-time-tactics. The dual character of the game is caused by its gameplay design [1] which can be split into strategic and tactical part. The strategic portion is not discussed here since it is irrelevant to the focus of the thesis. Figure 1.1: Screenshot from UFO: Afterlight.

9 CHAPTER 1. INTRODUCTION Tactics and RPG in UFO The tactical part of the game is a simulation of combat where a player is managing a small squad of human soldiers. Generally, the mission objective is to eliminate all aliens in the area. A screenshot from the tactical part of the game is shown in the Figure 1.1. A soldier is an indispensable unit. The determination of succeeding in a certain situation is strongly influenced by soldier s skills. The skills of soldiers are set up at the beginning by the player and can be increased in the course of game by gaining experience. This behavior brings in the elements of widely approved RPG genre. The implementation of the tactics is not entirely real-time and it brings in some turn-based features. Specifically, the combat runs in real-time, but the time flow can be stopped at any moment for as long as the situation requires. Although the actions of soldiers are suspended during this pause, the player still can assign, modify, and delete the plans of his units. As soon as the time is resumed the soldiers start to carry out the planned actions. This option of, possibly infinite, pause closely resembles the character of turn-based tactics where one can think over one s actions as long as one needs.

10 Chapter 2 Specification The central focus of the thesis revolves around multiplayer mode in tactics games. It is closely described in Section 2.1. To support the thesis, a prototype of multiplayer game based on the series UFO (Section 1.2) was created. Section 2.2 concentrates on the functional requirements of the prototype. The last section (2.3) specifies the path the thesis and the prototype take. It also states how the thesis and prototype interact with one another. 2.1 Thesis aim The goal of the project is to explore the numerous options of multiplayer design to a game like UFO. The most notable feature of UFO for the purpose of the thesis is the fact that the player can stop the time and assign actions to his soldiers. The primary question, which is addressed, is how to implement the stoppable time flow in multiplayer mode. In other words, the multiplayer mode should provide strong tactics where it is not necessary to immediately react to enemy s actions. For example, when a critical situation occurs, for instance the player is attacked, it is favorable to have a certain amount of time to think out the very next steps. 2.2 Prototype requirements The design of the prototype should offer several settings which support the tactics in multiplayer mode. In some aspects the prototype should resemble the tactical part of the UFO. It should preserve the RPG character of the game. That is to say, the soldier as a unit should have a few parameters which strongly influence his abilities like precision in shooting or speed of his movement. Furthermore, the 10

11 CHAPTER 2. SPECIFICATION 11 actions of the soldiers should be stored in a plan which can be modified at any time even if the rest of the game is inactive at that moment. Additionally, the prototype should implement a payment module which will allow the players to tune up their units and to configure their equipment. The main objective of the prototype is to test the viability and entertainment of the introduced multiplayer game design. 2.3 Project course First of all, the thesis consideres different time flow systems from the tactical point of view and chooses the most suitable one. Then it introduces further design elements and options which are intended to support the tactics of the multiplayer. Secondly, the prototype implements the chosen time flow system as well as the various supportive elements discussed in the thesis. Afterward, the prototype is tested by a smaller group of people who also take part in a survey, asking questions about the implemented options and the game as a whole. Finally, the thesis presents the summary of the achieved results.

12 Chapter 3 Time Flow Systems In the context, the term time flow system refers to a part of a game design which specifies the flow of the time in the game. This chapter considers several time flow systems with respect to multiplayer, similarity to UFO design and the amount of tactics involved in the game. It lists their pros and cons and chooses the most appropriate one for the game prototype. First of all, the real-time and turn-based systems, which were already mentioned in the introduction (Section and Section 1.1.2), are briefly recapitulated in Section 3.1 and Section 3.2, respectively. Then, two new systems are introduced which are designed to avoid the negatives of real-time and turn-based systems and concentrate on mixing together their positives. The first one is described in Section 3.3 and the second one is discussed in Section 3.4. Finally, there is a brief tabular summary of all the examined time flow systems in Section 3.5. The summary also shows the reasoning behind the choice of the most suitable system. 3.1 Real-time It is important to understand that in real-time tactics finishing certain tasks before the enemy does, is crucial. Therefore, the reflections and speed at managing the units might suppress the originally tactical character of the game. Additionally, this puts the more experienced gamers into a significant advantage over novices [2]. On the other hand, the real-time system is very successful in multiplayer mode. 12

13 CHAPTER 3. TIME FLOW SYSTEMS Turn-based The turn-based concept allows the player to plan actions of his units in a deeply detailed and precise manner. Consequently, the tactical aspect of the game is more profound than in real-time tactics. However, the multiplayer is quite tedious with its unbearable slow pace. 3.3 Time flow with two phases Time flow with two phases is based on switching between planning phase and execution phase. Only the former one is interactive and allows the players to assign commands to their units. The time is not running in this phase so the units are not moving, they are just receiving orders. The execution phase puts the game into the motion. The time is running during this phase and all the units behave according to the orders from planning phase. This time flow system would not suffer so badly in multiplayer as the turnbased one since the players are all kept busy at the same time. It also offers enough space for the tactics in the planning phase where all the players are granted a certain amount of time to manage their units. The weakest point of two phases system lies in the various anomalies caused by the switching of interactive and non-interactive phases. For example, it is possible that two enemy units spot one another, then pass one another and then peacefully disappear because no interaction is allowed in the execution phase. 3.4 Time flow with limited pause Time flow with limited pause is basically the same system that is found in UFO. The idea is that the game runs in real-time but it can be stopped at any time by any player. However, in this case the pause is limited. A certain amount of time, which is called pausing time, is assigned to each player at the beginning of the game. When a player stops the game, his pausing time is running and in a case it is all used up, the game is automatically resumed. The time flow with limited pause might not provide as much tactics as the turn-based system but it is still far more tactical than pure real-time. What s more, the multiplayer implementation is free of the deaf period during which only one player can interact with a game at a time. Thus, it suggests far more entertainment than the multiplayer of turn-based systems.

14 CHAPTER 3. TIME FLOW SYSTEMS Summary In order to simplify the task of choosing the most appropriate time flow system, a unified comparison of discussed systems was created. It is shown in Table 3.1. Time flow system Amount of tactics Multiplayer potential Resemblance to UFO Real-time low high medium Turn-based high low low Two phases high medium low Limited pause medium high high Table 3.1: Comparison of time flow systems According to the Table 3.1 it is obvious that the most suitable option for the prototype design is the limited pause time flow system. The strongest arguments in its favor can be summed up as follows: It is closest to the UFO design. Its similarity to the real-time system promises a good deal of potential in multiplayer mode. The amount of tactics it offers, is more than satisfactory.

15 Chapter 4 Game Design The previous chapter was devoted to the various possible time flow systems and chose the limited pause system as the most appropriate one. This chapter analyzes closer the design of the prototype. It discusses several possibilities of implementation of the most important parts of the design and chooses the most suitable solutions. It also gives a light image of the game to a reader who does not necessarily want to play the game. First of all, a compact overview of the prototype is provided (Section 4.1). Secondly, the most significant features of the prototype are discussed (Sections 4.2, 4.3, 4.4, 4.5, 4.6). Finally, the limited pause time flow system (described in Section 3.4) is examined more deeply and tuned up in Section Overview The prototype game is designed for a small group of players who can be divided into teams. Each player controls a few soldiers. The goal of the game is to eliminate all the enemy teams. The game provides simple 2D graphics with a bird perspective. It is meant to run primarily on LAN. 4.2 Command execution There are two possibilities how the commands which player gives to his soldiers can be executed. Instantaneous execution The first option is that the command is executed immediately. When a new command is given out while the previous one is not finished yet, the previous command is aborted and the current one takes over. This type of unit 15

16 CHAPTER 4. GAME DESIGN 16 control can be seen in the real-time games. However, it would be a burden in games where the players do not control their units entirely in real-time. It would cause that only one command can be assigned to a unit at a time. That means no planning. Delayed execution Better option for the prototype is to allow the planning. The idea is to store the commands in a queue and execute them sequentially. This type of command execution forces the player to think in advance. It creates the chess like atmosphere where one tries to guess the move of the other and adjust his strategy according to it. The delayed execution with planning creates more space for tactics and thus was chosen for the prototype. 4.3 Squareness of the game The result of the delayed command execution (planning) is that also the movement is a subject to planning and therefore we have to address the problem of finding the shortest path from soldier s current position to new destination. The algorithm generally used in games for path finding is called A* and it is closely described in the Section 5.4. The important thing is that any algorithm designed to find the shortest path must examine each possible position on the map. Lets suppose that the map has a size of imaginary units. That gives us positions to examine what is quite demanding on the CPU. In order to reduce the space of possible positions, the square grid is introduced where one square represents one possible position. One square for instance can have a size of imaginary units what diminishes the original positions to just positions. Due to this reason the game has square character. Also the most important position of the soldier is his square position and not his real position inside the square. Furthermore, the square coordinates are used in shooting and vision calculations. The disadvantage of the squareness is that the path and movement of the soldier seem to be less natural. The example of the soldier path is depicted in Figure Metric In mathematics a metric refers to a function which defines distance between elements of a set. In our case metric would be the way how we measure a distance between two squares. There are two possible approaches.

17 CHAPTER 4. GAME DESIGN 17 Figure 4.1: Path finding: The picture shows what a path from square A to square B would look like. Euclidean metric Euclidean metric is the most intuitive kind of metric which defines the distance between two points as the shortest line connecting them. Let s say we have two points p 1 = (x 1, y 1 ) and p 2 = (x 2, y 2 ). Then the distance between them would be defined as: (x1 x 2 ) 2 + (y 1 y 2 ) 2 Manhattan metric Although Manhattan metric is little less intuitive than the Euclidean, its definition is simpler. Again, let us suppose we have two points p 1 = (x 1, y 1 ) and p 2 = (x 2, y 2 ). The distance between them in Manhattan metric is defined as: x 1 x 2 + y 1 y 2 In order to put the math into words, we can say that if we want to walk from the point p 1 to the point p 2 we have to overcome their difference in x coordinate plus their difference in y coordinate. The main weakness of the Manhattan metric is illustrated in Figure 4.2. Judging from the above comparison and from the Figure 4.2, the Euclidean metric can be considered more natural. As a consequence, it is used in the prototype in most scenarios. However, when it comes to avoiding obstacles we use the Manhattan metric and prohibit diagonal movement. There are two good reasons for doing so. Let s assume that we are using the Euclidean metric and the diagonal movement is allowed all the time. Then the following odd situations could occur.

18 CHAPTER 4. GAME DESIGN 18 Figure 4.2: Picture shows the difference between Euclidean and Manhattan metric. In the Manhattan metric the length of the Path 1 is equal to the length of the Path 2 whereas in the Euclidean metric the Path 2 is shorter. 1. When there are two obstacles touching each other at the corners, it would be possible for the soldier to squeeze through that touching corners point exactly the same way as it is illustrated in the Figure 4.3a. 2. When the soldier is moving along one side of the obstacle then passes the corner and continues along the adjacent side of the obstacle, the moment when he passes the corner would look like as if he is going through the obstacle. Figure 4.3b demonstrates the situation. How does the movement along an obstacle look like when the diagonal movement is prohibited is presented in the Figure 4.3c. 4.5 RPG In order to mix into the prototype the RPG elements the soldier has several parameters which influence his vision, shooting, movement etc. In the prototype there are three sets of parameters influencing the soldier s behavior. Attributes There are just a few attributes represented by integers. They are set by the player at the start of the game. Attributes should make it easier for the player to decide where to invest his money. Skills The number of skills is approximately two times larger than the number of attributes. The skills are the values which are actually taken to account (used in shooting and other calculations). They are not set by the player

19 CHAPTER 4. GAME DESIGN 19 (a) Squeezing through the corner of two touching obstacles. (b) Passing the corner of an obstacle diagonally. (c) Passing the corner of an obstacle at right angle. Figure 4.3: Movement near obstacles. but are derived from attributes. One skill can be influenced by one or more attributes. All the skills have the same range. Consequently, they make it easy for the player to see the stronger and weaker qualities of the soldier. Stats Stats are similar to skills - they are the values used in calculations. For some skills (e.g. maximum hitpoints) the unified skill range is inappropriate or too unrealistic. Therefore, there are stats which shift the values of specific skills to a range more natural to them. For instance, if the skill hitpoints has the value of 7, the stat hitpoints would have the value of 76. Of course it would be possible to have just two sets of parameters or one. However, the three sets of parameters make the soldier more realistic and at the same time easy to set up.

20 CHAPTER 4. GAME DESIGN Vision & Shooting Although the player controls the game from a bird perspective, he can not see all the enemy soldiers on the map. The vision of the player is limited to the vision of his soldiers. The process of deciding whether one soldier sees another or whether the shot hit the enemy is not a simple one. Such answers are calculated in a complicated way described in the chapter about in-game calculations (B). In general, the output of the vision or shooting calculation can have two forms. Deterministic The first possibility is to have a deterministic calculation. In other words, for two equal situations there is always the same answer. In practice, that means that the calculation would take a look at soldier s skills and directly tell whether they are high enough or not to see an enemy. It s a little unrealistic to imagine that at one moment the soldier can t see his enemy and when he moves slightly forward suddenly he can see the enemy alright. Nondeterministic Another approach is to have a nondeterministic calculation. This means that the calculation would not directly yield the result but it would provide a probability of spotting or hitting the enemy. After calculating the probability a random number is generated. If it is smaller or equal to the probability the action is successful. Otherwise the action fails. This approach is far more realistic than the first one. Rather than jumping from yes to no it offers continuous probability model which is more similar to the real life. The problem of the probability model is its dependence on random numbers. Specifically, the handling of random numbers in multiplayer games is not so trivial. However, this problem was successfully solved (the solution can be found in the developer manual in the Section 5.3.1). Thus, the prototype features nondeterministic calculations with a probability model. 4.7 Pausing support The limited pause time flow system has one concealed flaw. It enables the players to play the game in a pure real-time way. Thus, the player can avoid the tactics at all if he wishes so. In the single player mode implemented in UFO there is an easy solution to this problem. The authors made sure to create the combat situation complex enough so that it is impossible to accomplish the mission without pausing. However, in multiplayer the complexity of combat situation can not be influenced by the developer. What s more, if all the players are comfortable with

21 CHAPTER 4. GAME DESIGN 21 real-time games and have have no or only little experience with tactics games, it is very likely that they will not use the advantages of pausing. Of course the experienced tactics gamers might be lured into the real-time trap as well. In order to solve this problem, the prototype provides various game options which support or force pausing. Auto-pause The idea of this option is to pause the game automatically on certain important events. For example, the game can be paused when a player s soldier is under attack or when he spots an enemy. Restricted planning Another way how to enforce the players to use the pausing is to prohibit the planning of particular actions in moments when the time is running. In other words, the game can be set up in a way where the player can plan a specific action (e.g. shooting) only when the game is paused. Skill bonus or heal The skill bonus option is designed to benefit the player each time he pauses the game. It enables the player to choose a favorable skill for each of his soldiers. Consequently, when the option is turned on and the game is paused the soldier s skills increase slightly. The heal option works exactly the same way but instead of increasing the skill of a soldier the soldier is healed a little. Both these options can be easily abused to pause the game in moments when there is nothing going on. Therefore, they can be limited to work on a soldier only when a significant game event relevant to that soldier occurred recently. For instance, a direct confrontation with an enemy can be considered to be a significant event.

22 Chapter 5 Implementation This chapter is devoted to the implementation matters of the prototype. It discusses the most interesting and challenging issues. First of all, the XNA game framework is introduced in Section 5.1. Secondly, an explanation of game loop and brief overview of the core game classes is provided in the Section 5.2. Afterward, Section 5.3 explains how the network synchronization is achieved and how networking fits into the prototype design. Rest of the chapter is devoted to the problem of path finding (Section 5.4) and the history of prototype s graphical user interface (Section 5.5). 5.1 XNA Microsoft XNA framework (XNA is not an acronym) is a.net library for game developers. It wraps load of code often found in the game development. The main relevant features of XNA can be summed up as follows. Game loop XNA creates and manages the game loop automatically. It provides the developer with numerous options to control the loop and to obtain information about the loop. The developer does not need to worry about implementing a timer since XNA provides a Time class through which it is possible to get the necessary information about time. The instance of Time class contains the total time from the start of the game, as well as the elapsed time from the last game update. XNA allows to set the length of the game loop and choose whether the length should be static or dynamic. What s more XNA provides us with two separate game loops. One serves to update the logic of the game, whereas the second does all the drawing. Such a distinction is useful when the processor can not keep up with the desired game loop length due to the computational complexity of the logic update loop. If this 22

23 CHAPTER 5. IMPLEMENTATION 23 happens, XNA automatically postpones the drawing loop in order to let the logic update loop finish and at the same time keep the desired game loop length. XNA even lets the game know that the processor is having difficulties to keep up through a property IsRunningSlowly. Consequently, the game can react to this fact and restrict the logic update loop. Drawing XNA uses DirectX for drawing. However, the programing with DirectX remains hidden to the developer thanks to the many wrappers around the DirectX which make one s life easier. XNA also wraps the work with textures and content handling. Helper classes XNA contains many helper classes such as Point or Vector2D. It also contains the MathHelper class which is a useful extension to the.net Math class. Portability Since XNA runs on.net it is to a certain degree platform independent. Therefore, the developer does not have to bother with different computer architectures and can concentrate solely on the game itself. As a result of the mentioned advantages of XNA we chose XNA and C# as the most appropriate for the game prototype. Another possibility would be to use C++ and one of its countless game libraries. However, C# simplicity and increasing popularity as well as the idea of having a managed code with garbage collection, outnumbered the pros of the rather old but in gaming industry widely approved C++. Of course Java is a good match for C# but after taking a look at the game libraries for Java, C# and XNA seemed to be a more suitable solution for our purpose. 5.2 Game loop and prototype structure The general idea of the game loop was already presented in the previous section. Now is the right time to explore how the automatic game loop provided by XNA is incorporated into the prototype structure. The most important classes of the prototype are shown in the Figure 5.1. As we can see the MyGame class is the top level class. It groups together the various game components. From the point of game loop the most essential class is the ScreenManager. It inherits from XNA class DrawableGameComponent. Furthermore, it is registered as a game component at the GameComponentCollection.

24 CHAPTER 5. IMPLEMENTATION 24 Figure 5.1: Simplified UML diagram of the most important classes. Therefore, the game loop automatically created by XNA calls the ScreenManager s Update and Draw method. Another function of the ScreenManager is to collect the input through the InputHelper class. Classes which are beneath the SoldierManager in the Figure 5.1 usually implement the following methods: Update Update method updates the logic of the object. For example, if the object is moving, each time the Update method is called, it calculates the new position of the object according to the object s velocity and elapsed time.

25 CHAPTER 5. IMPLEMENTATION 25 HandleInput The HandleInput method reacts to the input and according to it changes the state of the object. Draw The Draw method draws the object onto the game screen. It is not necessary to implement all three of the above methods. For example, the GameInfoScreen which only shows help and additional informations implements just the Draw and HandleInput methods. These methods are called in a chain-like manner. That means that the Update method of ScreenManager calls the Update method of the GamePlay which calls the Update method of the PlayerManager and so forth. 5.3 Networking One of the greatest challenges was without doubt the network synchronization and design. The prototype has the client-server network architecture. The communication is implemented using non-blocking TCP/IP sockets. In the gaming industry the word tick is often used interchangeably with the word game loop and we will be using it too Synchronization The network synchronization is achieved through a synchronized game tick. That means that if an action happens in the tick x on the server machine, it must happen in the tick x on all the client machines as well. This is accomplished in the following way. The server resends a new game tick each 40 milliseconds together with the input of all the players and the clients update their world according to the tick and input from the server. It is important to know that when a player, other than the one on the server machine, submits some input, it is not processed right away on the local machine. It is first sent to the server. Then the server resends the input with the current tick to all other players as well as to the one from which it received the input. Finally, when the input is received from the server (together with the tick) it can be processed. The whole procedure of handling an input of client machine is shown in the Figure 5.2. If the input of a player was processed instantly as it is submitted, there would be no guarantee that it would be received by the server in that same tick and thus there is a good chance of synchronization failure.

26 CHAPTER 5. IMPLEMENTATION 26 Figure 5.2: The picture shows how the input of a client is handled at a local machine. It is first sent to the server (gray arrows) and then it is resent to all the clients (blue arrows). The described synchronization method is not ideal. On slower connections there might be problems with server response time to client input as well as problem with jitter which might cause an uneven, choppy movement of the units. On the other hand this implementation is very easy and provides a 100 % synchronization. Even the random numbers can be synchronized by making the tick the seed for the random generator. What s more, one does not have to send and receive the information about the whole world. The only thing needed is the input of other players and tick. Therefore, each client can simulate the world on his own Design The design of the network communication is quite simple. The basic idea is to make as few differences as possible between server machine and client. Therefore, the logic of the game is the same at both machines. The classes which update the world and players are identical. The Figure 5.3 depicts how the network is built into the game. The Network class manages all the network communication. It is divided into NetworkClient, which runs at the client machine and NetworkServer, which runs at the server machine. All the differences between client program and server program are hidden in these classes. The GamePlayData is class holding

27 CHAPTER 5. IMPLEMENTATION 27 Figure 5.3: Network integration. the actual tick and all the input from all the players. It serves as a communication channel between GamePlay and Network. 5.4 Path finding The path of the soldier is found using A* algorithm which is very similar to Dijkstra s algorithm. A* uses a heuristic which promises to search the squares with higher chance of being in the path first. In the course of the algorithm we distinguish three sets of squares. The first set contains those squares which were already visited by the algorithm and they will never be visited again. The second set consists of possible candidates or squares which are right next to the visited squares and can be visited in the next iteration of the algorithm. The rest of the squares make up the third set. The most essential part of the A* algorithm is the way how it chooses among the candidates the one which will be visited in the next iteration. A* always chooses the candidate with the best evaluation function f which is defined as follows: f (x) = g(x) + h(x)

28 CHAPTER 5. IMPLEMENTATION 28 g(x) - shortest path from the start to x h(x) - estimated path from x to the destination There are numerous ways how to choose the heuristic function h. In the prototype we compute h(x) as an Euclidean air distance between x and the destination square. It is important to apprehend that the heuristic function h calculates only hypothetical distance since there might be some obstacles in the way whereas the g function gives us a true distance. The difference between A* and Dijkstra is that Dijkstra s evaluation function consists of just the g function. In another words, Dijkstra s algorithm is not trying to get closer to the destination. It always visits the nearest square and if the path exists the algorithm will eventually find it. On the other hand, A* is trying with each step to get closer to the destination and in most cases runs considerably faster. A more detailed description of A* is presented in the Algorithm Graphical user interface There were three possible solutions to the question of choosing a graphical user interface (GUI) for the prototype. Windows forms The first idea was to use windows forms. However, a day of research revealed that using windows forms from within XNA 1.0 (the version of XNA used at the time when the first GUI was implemented) is a very thorny path to take. GUI for XNA Another option was to use one of the existing GUI libraries designed for XNA. On the one hand they look better than windows forms and some of them have even customizable look and feel, but on the other hand their functionality is much weaker. New GUI The last option was to implement our own GUI. This option was right away out of question since it would be extremely time consuming and distracting. At first, the option of using one of the GUI libraries for XNA seemed as the most promising way to take. As a result, the first GUI was created in one of the existing libraries. Initially it was satisfactory but as the GUI of the game grew it turned out to be lacking some of the critical GUI features like support for copy and paste. Finally, with the new versions of XNA 2.0 and 3.0 the integration of windows forms became a little easier and therefore, the whole GUI was remade using the windows forms.

29 CHAPTER 5. IMPLEMENTATION 29 Algorithm 5.1: A* input : start - start square, destination - destination square output: p - array of predecessors begin foreach x in all squares do f [x] Insert(candidates, start) g[start] 0 f [start] ComputeH(start, destination) p[start] nil while candidates do { Select the square with minimum f function. } u ExtractMin(candidates, f ) if u = destination then return p end Insert(visited, u) foreach x in Neighbors(u) and 2 x not in visited and x not on obstacle do hx ComputeH(x, destination) newg g[u] + Distance(u, x) newf newg + hx if not x in candidates then Insert(candidates, x) end if newf < f [x] then g[x] newg f [x] newf p[x] u end end end return nil end

30 Chapter 6 Results This thesis introduces multiplayer design which in its principles closely resembles the UFO games. In UFO the player s enemy is artificial intelligence and it is strong enough to force the player to pause the game and to think over his following actions. However, we assumed that in multiplayer the players would easily fall for the real time way of playing and would not use the pausing at all. Therefore, we created three options whose main goal is to prevent the players from playing real time and use the advantage of pausing. In order to verify the effectiveness of the options which support pausing and to prove the viability of the design, the prototype was tested by a smaller group of people. Section 6.1 describes the course of the testing. Afterward, we present the results of the survey (Section 6.2). Then, few observations gathered during the testing are discussed in the Section 6.3. Finally, last section (6.4) points out the most important thoughts inferred from the survey and testing. 6.1 Testing background All together there were about 15 people who actually played the game for more than one hour. However, only 9 of them lasted long enough to take part in the survey which is included in Appendix C. Each of these people played the game at least for three hours. The age of the testers varied from 16 to 24. Approximately half of the testers were below 18 while the other half was above 20. As far as the experience of the players go, about half of them plays tactics games from time to time. However, most of the players play more often strategy games than tactics. The players tested the three game options which support the pausing as well as the setup with no pausing support at all. Consequently, they took part in the survey. 30

31 CHAPTER 6. RESULTS Survey The main goal of the survey is to get a general opinion about the implemented options which support the pausing and planning in the game (see Section 4.7). The remarks of the testers to the three options are summarized in the following list. Auto-pause Surprisingly, the auto-pause option turned out to be the least popular and most annoying. Its main weakness is that the players who are not involved in the event which fired the auto-pause are victims of often unnecessary pause and have to wait. As a consequence, the pace of the game is rather slow. However, this shortcoming was significantly reduced by limiting the auto-pause to be fired just on the enemy spotted event and by decreasing the pause. The advantage of auto-pause is that it gives the players some extra space for planning when they do not have to use their own pausing time. Restricted planning The restricted planning option proved to be the most unconventional and for most testers it took a while to comprehend what it actually does. Nevertheless, in the end it successfully forced even those most resistant, to pause the game. The survey shows that the popularity of this option is quite neutral. The most prominent disadvantage might be the fact that one must be careful with his pausing time since once it is gone, the affected commands (commands which can be planned only when the game is paused) can not be planned. Skill bonus or heal The skill bonus or heal option was in general the most favorite option. People especially liked the idea of having their soldiers healed during the pause. However, few testers objected that it slows down the whole game; especially, when the players pause the game for a long time just to heal their soldiers. The survey also asks the players how often they paused the game and how would they rate the pace of the game at the various setups. By the term pace of the game we mean how thrilling is the game or on the other hand how tedious it is. Figure 6.1 shows the average values of answers to these questions. The original answers were in the range from 1 to 5 where 1 means the least and 5 means the most. A little surprisingly, the players used the pausing most often during the skill bonus option and not during the restricted planning option as one would expect. This just means that the players are more likely to use the pausing when they

32 CHAPTER 6. RESULTS 32 are encouraged to do so but not forced to. However, the frequent pausing during skill bonus option also caused that the pace of the game was not the fastest. The low usage of pausing and low pace of the game during the auto-pause option suggests that this option paused the game too often and resulted in a slow and boring gameplay. Finally, as we can see the pace of the game was fastest when there was no support for pausing at all. At the same time, the amount of pausing was above average and even close to the amount of pausing during the restricted planning option what suggests that the players actually used the pausing even when they were not forced nor encouraged to do so. 6.3 Observations The actual testing and playing the game revealed few minor points presented in the list below. The players who frequently play the real time games at first used the pausing far less often than the players more familiar with turn-based games. What s more their pausing was even rarer than the pausing by players who do not have much experience with computer games. The longer the players played the game, the more they paused the game. Especially, when they played with more tactical players who paused the game often. The restricted planning option turned out to be a great learning option; especially, for the players from the world of real time games. Although, they did not like it first, it taught them to pause the game and made them more comfortable with a new time flow system. However, in the end it was quite useless since the players paused the game anyway. (A good setup for this option is to prohibit the planning of shooting when the game is not paused.) From the player s point of view there was not a big difference among the various options for pausing support. For example, when the restricted planning or skill bonus options were turned on, the players did not pause the game significantly more often than they did during the setup with no pausing support.

33 CHAPTER 6. RESULTS Summary The outcome of the testing and survey indicates that the options designed to support the pausing do not have as strong influence as we originally expected. The most influential factor when it comes to pausing the game stays the same as in the single-player mode implemented in the UFO series i.e. the complexity of the situation. Surprisingly, the numerous situations which occurred during the testing were complex enough to force the player to pause the game. Particularly, when two players met in a gunfire. Furthermore, it is important to state that the game design itself must be complex enough to provide a good tactics environment. For instance, when shooting from a gun does occur instantaneously and the magazine of the gun has about 20 bullets, then twenty clicks of the mouse are enough to kill the enemy very fast. A better approach is to put just 5 bullets into the weapon s magazine and to make the shooting last longer e.g. 1 second. Then the enemy soldier can not be killed so fast; consequently, the player has to pause the game and come up with a plan. Finally, the prototype proved to be quite enjoyable and successfully managed to awake the spirit of the gamer in most of the people who volunteered to test the game.

34 CHAPTER 6. RESULTS 34 (a) Average values which show how much the players used the pausing at different game setups. 1 means almost never and 5 means frequently. (b) Average values of the pace of the game at different setups. 1 means very slow and 5 means super fast. Figure 6.1: Comparison of different game setups.

35 Chapter 7 Conclusion In these days there are multiple popular tactics games. Most of these games only offer a single-player mode or if they have a multiplayer it is by far not so entertaining as the single-player. This project analyzes various options of implementing a multiplayer to a tactical game. The proposed design is to a certain degree similar to the UFO games. A prototype was created in order to test the viability of the design. The most important feature of the prototype is that the player can plan the actions of his soldiers while the game is paused. In order to support the pausing the prototype introduces several options which are designed to force or motivate the player to use the pausing. The prototype as a whole was subject to testing. Consequently, the results of testing are discussed in this thesis. In the end the options designed to support pausing turned out not to be as much influential as expected. However, they either help the players to grasp the basic idea of the game, what benefits the pausing of time provides, or they made the game more interesting. On the other hand, the players did not need to be pushed into the use of pausing. Soon enough they discovered that without using the advantage of pausing they do not stand a chance against the other players who frequently paused the game. The need for pausing is a result of the complexity of scenarios that arise in the prototype which offers plenty of tactical possibilities of how to approach and eliminate the enemy. Furthermore, the proposed time flow system did not restrict the entertaining character of the game and at the same time, it kept the tactics of the game at a high level. There are multiple alternatives how to extend and improve the whole project in the future. A further severe testing might be done to tune the options designed to support the pausing. There is plenty of space where one can improve the tactics of the game. One can spend months examining the parameters of the weapons and the calculations trying to balance the game, so that there are not two or three soldier setups which are apparently better than others. Even though it is just a prototype of a game, it would be nice to have a more appealing graphics (it can 35

36 CHAPTER 7. CONCLUSION 36 even be 2D) and some simple sounds. They would at least attract more volunteers for testing. Another idea which can help to get the opinion of a large number of different people is to put the project on an open source hosting facility like Google Code or SourceForge. It would not only help to bring new ideas into the project but also the actual implementation would improve. In conclusion, the objective of this thesis was successfully met. First of all, we managed to create a prototype of tactical multiplayer game similar to the UFO series. Furthermore, as the testing suggested the gameplay is interesting and enjoyable enough to promise a viable game design.

37 Appendix A User manual This chapter covers the necessary information for playing and configuring the game. Section A.1 introduces the game in a few sentences. The prerequisites are mentioned in the Section A.2. Afterward, simple installation guidelines are provided in the Section A.3. Section A.4 explains how to create a game or join an existing game. Section A.5 covers various game options. Section A.6 presents the details about soldiers. All the weapons and other game items are described in the Section A.7. An overview of all the information which is available through the course of playing is in the Section A.8. The Section A.9 explains how to create a custom map. Finally, the last section (A.10) lists all the controls. A.1 About the game First of all, it is important to state that the game is more of a prototype than a full-fledged game. Therefore, in many aspects it might seem incomplete. It is designed to test the viability of tactics games similar to UFO from Altar GAMES in multiplayer mode. The game can be classified as a tactics multiplayer game with some RPG elements. It features simple 2D graphics with a bird perspective and is intended to run mainly on LAN. There can be up to eight players. Each player controls a few soldiers (from one to four). Furthermore, players can be grouped in a team and fight together against other team. The tactical character of the game lies in the fact that the game can be paused at any time during which you can assign commands to your soldiers. The goal of the game is to eliminate all the enemy teams. 37

38 APPENDIX A. USER MANUAL 38 A.2 Prerequisites Software The game was tested primarily on Windows XP, but it might run on other versions of windows as well. Other software prerequisites are.net 2.0 SP1, DirectX 9.0c and XNA Framework Redistributable 3.0. However, these are included as a part of the installer, so you don t have to worry about them. If you don t have them the installer will automatically install them. Hardware The game requires a graphics card with pixel shader support 1.1 or higher. A.3 Installation In order to install the game just run the TMGSetup.msi. The installer installs the following components:.net 2.0 SP1 DirectX 9.0c XNA Framework Redistributable 3.0 game executables If you want to uninstall the game just navigate to the Control panel/add or remove and click the Remove button at the Tactical Multiplayer Game field. A.4 Quick Start You can launch the game either by navigating to the game s installation directory and running the file TMG.exe or through the start menu by running the Tactical Multiplyer Game entry. At the beginning you can choose to either create a game or join an existing game. In general, one player creates a game and all the other players must join that game, so they can play together. If you decide to create the game, the Game options window will be displayed (hint: window name is displayed in the application s title area). In this section we will focus just on the General tab, which can be seen in the Figure A.1. Here you can set your name as a player, number of soldiers that each player can command, port at which the server runs and desired map.

39 APPENDIX A. USER MANUAL 39 Figure A.1: Create game window - General tab. If you decide to join an existing game the Join game window will appear, as shown in the Figure A.2. Here you can again set your name as a player. Then you have to specify IP address or name of the server and port to which you want to connect. Figure A.2: Join game window. The next window is Player setup window. It does not matter whether you joined a game or created one the Player setup window is the same for both scenarios. There are two or more tabs in this window. The most important one is the Connected players tab, which is displayed in the Figure A.3. First of all you can see here a table with information about all the connected players. You see the name, state, team and color of the player. The state of the player signalizes whether he is ready to play or whether he is still buying some equipment for his soldiers. You can also buy or sell your pausing time in the Player setup window. Pausing time is a special amount of time which can be used to freeze the soldiers and plan their actions while the game is paused. The rest of the tabs handle the soldiers setup. For now, you can use the advantage of predefined soldiers and load them from the Soldiers directory located in the game s installation directory. Don t bother with details of soldier tab right now, they will be explained later in the Section A.6. Once you are ready to start just press the Ready button. Notice that the button changes to Shop. If you change your mind and decide to buy some more stuff, just press the Shop button. As soon as all the players are ready the game starts. Once in the game, use the left button of your mouse to move your soldiers and the right button to use their weapons. For more information on

40 APPENDIX A. USER MANUAL 40 controls either press F1 when in the game or see Section A.10. Figure A.3: Player setup window - Connected players tab. A.5 How to set up the game There are various game options which can be set right before the game is created in the Create game window. They are divided into two major groups: Time options and other options. They are described in sections A.5.1 and A.5.2. The options can also be saved or load with Save options and Load options buttons. A.5.1 Time options The time options are in the Time tab of Create game window. They group together multiple sets of options, as illustrated in Figure A.4. The first set of options are basic pausing time options. Here you can set for how long can each player pause the game or whether the pausing time should be rechargeable. When the pausing time is rechargeable it is recharged slowly as the game runs in real time. The recharge factor tells us at what rate the pausing time is recharged. When it is set to 0.1 it means that with each second spent in real time 0.1 second of pausing time is recharged. The Plan when paused options enable to restrict commands to be planned only when the game is paused. The Automatic time stop options determine at which events and for how long should the game pause itself.

41 APPENDIX A. USER MANUAL 41 Figure A.4: Create game window - Time options tab. The last set of options (Skill bonus options) is about applying bonus to a chosen skill when the game is paused. First of all, you can decide whether to allow such behavior or not. The next option Bonus magnitude tells us in percents how the skill should be updated. Apply bonus after option determines the interval at which the bonus is applied. In order to avoid pausing the game in a state when nothing is going on just to gain the bonus, one can choose the bonus to be applied only when some kind of important event recently took place. Pause registering Registering for a pause is a useful and important feature of pausing. It works in the following way. When the game is paused by somebody else or it is paused automatically you can press the pause button to ensure that the game is not resumed in the most inconvenient moment for you. By pressing the pause button during the pause you register for a pause and when the owner of the current pause (the player who paused the game) tries to resume the game it is not resumed right away. First the game checks whether there is anybody registered for a pause and if that is the case the pause continues on the account of the first registered player. If there is nobody in the queue of players registered for pause, the game is resumed. When you are registered for a pause a large PR sign is displayed in the right upper corner.

42 APPENDIX A. USER MANUAL 42 A.5.2 Other options The Others tab of the Create game window unites options for vision, events and money. It is presented in Figure A.5. Figure A.5: Create game window - Other options tab. The first set of options describes how much should the player see. The most limited setting is that the player can only see his soldiers and the visibility of teammate soldiers and enemy soldiers is calculated. A little less constrained setting is that the player can see his soldiers and the teammate soldiers but the visibility of enemy soldiers is calculated per player. That means that you can t see the enemy which is seen by your teammate. The least limiting setting is one that includes previous two plus the ability to see the enemy soldiers which are seen by your teammate. The second set of options controls the two main in-game events. Since the options of one event are very similar to the options of the other event we will focus just on one of the two events. The first option is Interesting vision target or Interesting attacker. It determines when the event is fired. It can be fired when

43 APPENDIX A. USER MANUAL 43 we spot an enemy soldier or an enemy player or an enemy team. For example, we set the Interesting vision target to the player. We spot a first soldier of an enemy player and the enemy spotted event is fired. Then we spot another soldier of that same player but since we are interested in the player and we already see the first soldier the event is not fired again. The second option is Enemy spotted duration or Under attack duration. This option addresses the following problem. Imagine that you spot an enemy and the enemy spotted event is fired but then the enemy hides himself behind an obstacle and a moment later he appears again. In this situation we don t want the enemy spotted event to be fired again. Therefore, we set the Enemy spotted duration option to for example 5 seconds and that means that we can lose the enemy for 5 seconds from sight and if he reappears in those five seconds the enemy spotted event is not fired. The last set of options are payment module options. You can choose how much money should each player have and how much can he spend on soldier attributes. The amount of money player can spend on soldier attributes applies per soldier. Value -1 means that there is no limit on how much money can be spent on soldier attributes. A.6 Soldier Soldier is the only unit you have. He can not be reproduced, substituted, resurrected or re-spawned. That means that if the soldier dies he is gone for good. A.6.1 Attributes, Skills and Stats Soldier s abilities are described by three characteristics: attributes, skills and stats. You can only manipulate with the attributes and then watch how it changes soldier s skills and stats. In the game itself only the skills and stats are taken into account. To fully grasp the reasoning behind three sets of characteristics see Section 4.5. A.6.2 Inventory Soldier s inventory contains four slots or storage places. There are active item and passive item slots where you can place a weapon or first-aid-kit. The soldier can use the item placed in active item slot. If you intend to use soldier s passive item, you have to first switch it with the active one so the passive item becomes active. Then there is a slot for soldier s armor. The last slot is Ammo Belt and it serves as storage place for magazines. Also when the soldier is reloading, the ammo belt is the place where the soldier looks for the additional ammunition.

44 APPENDIX A. USER MANUAL 44 Each item in the inventory has it s weight and when the inventory is too heavy the soldier moves slower. Especially, if the weight of the inventory exceeds the soldier s stat capacity. A.6.3 Soldier setup Now that you learned something about your soldiers it is the right time to take a look at the soldier tabs in Player setup window which enables you to set up the soldiers. The example of a soldier tab is illustrated in Figure A.6. You can specify here a name of the soldier, buy some equipment or train the soldier (buy attributes). We recommend to read the tooltips shown above the labels to get the general idea about the different options you can set up. It is also possible to save or load your soldier providing that you have enough money. Figure A.6: Player Setup window - Soldier options tab.