<%BANNER%>

Coordinated Behavior for Predator Prey Modeling

Permanent Link: http://ufdc.ufl.edu/UFE0022893/00001

Material Information

Title: Coordinated Behavior for Predator Prey Modeling An Approach to Next Generation Console Development
Physical Description: 1 online resource (45 p.)
Language: english
Creator: Nguyen, Thien
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2008

Subjects

Subjects / Keywords: behavior, coordinated, playstation3, xbox360
Computer and Information Science and Engineering -- Dissertations, Academic -- UF
Genre: Computer Engineering thesis, M.S.
bibliography   ( marcgt )
theses   ( marcgt )
government publication (state, provincial, terriorial, dependent)   ( marcgt )
born-digital   ( sobekcm )
Electronic Thesis or Dissertation

Notes

Abstract: With each introduction of a new generation of video game consoles, the user's expectations for larger environments, better A.I., and smoother graphics rise. To deliver these features on the newest generation of consoles, Microsoft and Sony had to shift their architecture paradigm for the design of the Xbox 360 and Playstation 3, emphasizing parallelization instead of dependence on a single CPU core. My study provides a software architecture to make use of the multiple cores of next generation hardware. To demonstrate these principles, my study focused on the design of a predator/prey ecosystem model, whose main processes are split across different threads. A blackboard system and messaging architecture handles data coherency across the different threads while coordination is handled by a planner system, which sets the overall goal for each individual entity. This design aims to maximize what can be parallelized as well as provide data coherency that is not tightly coupled to a particular system. The result of my study was a more robust software architecture that has the potential to deliver a deeper, richer experience to the user, as well as lowering the cost of development of games on these consoles.
General Note: In the series University of Florida Digital Collections.
General Note: Includes vita.
Bibliography: Includes bibliographical references.
Source of Description: Description based on online resource; title from PDF title page.
Source of Description: This bibliographic record is available under the Creative Commons CC0 public domain dedication. The University of Florida Libraries, as creator of this bibliographic record, has waived all rights to it worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law.
Statement of Responsibility: by Thien Nguyen.
Thesis: Thesis (M.S.)--University of Florida, 2008.
Local: Adviser: Dankel, Douglas D.

Record Information

Source Institution: UFRGP
Rights Management: Applicable rights reserved.
Classification: lcc - LD1780 2008
System ID: UFE0022893:00001

Permanent Link: http://ufdc.ufl.edu/UFE0022893/00001

Material Information

Title: Coordinated Behavior for Predator Prey Modeling An Approach to Next Generation Console Development
Physical Description: 1 online resource (45 p.)
Language: english
Creator: Nguyen, Thien
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2008

Subjects

Subjects / Keywords: behavior, coordinated, playstation3, xbox360
Computer and Information Science and Engineering -- Dissertations, Academic -- UF
Genre: Computer Engineering thesis, M.S.
bibliography   ( marcgt )
theses   ( marcgt )
government publication (state, provincial, terriorial, dependent)   ( marcgt )
born-digital   ( sobekcm )
Electronic Thesis or Dissertation

Notes

Abstract: With each introduction of a new generation of video game consoles, the user's expectations for larger environments, better A.I., and smoother graphics rise. To deliver these features on the newest generation of consoles, Microsoft and Sony had to shift their architecture paradigm for the design of the Xbox 360 and Playstation 3, emphasizing parallelization instead of dependence on a single CPU core. My study provides a software architecture to make use of the multiple cores of next generation hardware. To demonstrate these principles, my study focused on the design of a predator/prey ecosystem model, whose main processes are split across different threads. A blackboard system and messaging architecture handles data coherency across the different threads while coordination is handled by a planner system, which sets the overall goal for each individual entity. This design aims to maximize what can be parallelized as well as provide data coherency that is not tightly coupled to a particular system. The result of my study was a more robust software architecture that has the potential to deliver a deeper, richer experience to the user, as well as lowering the cost of development of games on these consoles.
General Note: In the series University of Florida Digital Collections.
General Note: Includes vita.
Bibliography: Includes bibliographical references.
Source of Description: Description based on online resource; title from PDF title page.
Source of Description: This bibliographic record is available under the Creative Commons CC0 public domain dedication. The University of Florida Libraries, as creator of this bibliographic record, has waived all rights to it worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law.
Statement of Responsibility: by Thien Nguyen.
Thesis: Thesis (M.S.)--University of Florida, 2008.
Local: Adviser: Dankel, Douglas D.

Record Information

Source Institution: UFRGP
Rights Management: Applicable rights reserved.
Classification: lcc - LD1780 2008
System ID: UFE0022893:00001


This item has the following downloads:


Full Text

PAGE 1

1 COORDINATED BEHAVIOR FOR PREDATOR PREY MODELING: AN APPROACH TO NEXT GENERATION CONSOLE DEVELOPMENT By THIEN NGUYEN A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLOR IDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2008

PAGE 2

2 2008 Thien Nguyen

PAGE 3

3 To my loving wife, Ajda. Without your love, understanding and support, none of this would be possible. Your encouragement and strength inspire me every day to be the best husband, engineer and partner I can be. To Sammy and Oscar, who remind me to take a breath every once in a while and enjoy life.

PAGE 4

4 ACKNOWLEDGMENTS I would like to thank Dr. Dankel for supporting m e through UFs M.S. program. It was a long journey, riddled with roadblocks, tremendous work demands, missed deadlines, and everchanging topics. Through it all, Dr. Dankels unwavering support and encouragement helped me to complete this long journey. I would like to thank my wife, Ajda, w hose love and support guided me through the toughest of times. With so much going on, hers was the steady hand that kept me on course. I would like to thank Alex Moreland, who ha s shown me what true strength of will and perseverance are. This thesis is a testament to being able to accomplish anything if you believe and work hard enough at it.

PAGE 5

5 TABLE OF CONTENTS page ACKNOWLEDGMENTS...............................................................................................................4LIST OF TABLES................................................................................................................. ..........7LIST OF FIGURES.........................................................................................................................8ABSTRACT.....................................................................................................................................9 CHAP TER 1 INTRODUCTION..................................................................................................................102 NEXT GENERATION DEVELOPMENT............................................................................ 13Generation 2 Console Architecture........................................................................................ 13Xbox Architecture...........................................................................................................13Playstation 2 Architecture............................................................................................... 13Next Generation Console Architecture...................................................................................14Xbox 360.........................................................................................................................14Playstation 3.................................................................................................................. ..14Software Design................................................................................................................ ......15Threading................................................................................................................................15Conclusion..............................................................................................................................163 SIMULATION ARCHITECTURE........................................................................................ 19Simulation..................................................................................................................... ..........19Unit Testing............................................................................................................................21Conclusion..............................................................................................................................214 SIMULATION DESIGN........................................................................................................24System Design........................................................................................................................24Simulation..................................................................................................................... ..........24Unit Testing............................................................................................................................27Conclusion..............................................................................................................................275 RESULTS AND ANALYSIS................................................................................................. 30Introduction................................................................................................................... ..........30Results and Analysis........................................................................................................... ....30

PAGE 6

6 6 CONCLUSION..................................................................................................................... ..35Summary.................................................................................................................................35Possible Future Work........................................................................................................... ..36APPENDIX: RAW COMPUTATIONAL DATA......................................................................... 38LIST OF REFERENCES...............................................................................................................44BIOGRAPHICAL SKETCH.........................................................................................................45

PAGE 7

7 LIST OF TABLES Table page 5-1 Total thread time in single thread ed mode of si mulation, in cycles.................................. 34 5-2 Total thread time in multithreaded mode of the simulation, in cycles ............................... 34 A-1 Single threaded time....................................................................................................... ...38 A-2 Multithreaded time......................................................................................................... ....38 A-3 Antelope metrics, test case 1.............................................................................................. 39 A-4 Antelope metrics, test case 2.............................................................................................. 40 A-5 Antelope metrics, test case 3.............................................................................................. 41 A-6 Lion metrics, test case 1.................................................................................................. ...42 A-7 Lion metrics, test case 2.................................................................................................. ...42 A-8 Lion metrics, test case 3.................................................................................................. ...43

PAGE 8

8 LIST OF FIGURES Figure page 2-1 Sonys Playstation 2 architecture.......................................................................................16 2-2 The Xbox 360 architecture.................................................................................................17 2-3 Sony Playstation 3 architecture.......................................................................................... 18 3-1 Information flow in PackHunt simulation......................................................................... 22 3-2 Blackboard interaction graph............................................................................................. 22 3-3 Message system flow.........................................................................................................22 3-4 Single-threaded processing................................................................................................ 23 3-5 Multithreaded processing................................................................................................... 23 4-1 PackHunt simulation with tuning window.........................................................................28 4-2 Entity hierarchy........................................................................................................... .......28 4-3 Message passing............................................................................................................ .....29 4-4 PackHunt simulation........................................................................................................ ..29 5-1 Thesis development time................................................................................................... 34

PAGE 9

9 Abstract of Thesis Presen ted to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science COORDINATED BEHAVIOR FOR PREDATOR PREY MODELING: AN APPROACH TO NEXT GENERATION CONSOLE DEVELOPMENT By Thien Nguyen December 2008 Chair: Douglas D. Dankel II Major: Computer Engineering With each introduction of a new generation of video game consoles, the users expectations for larger environments, better A.I ., and smoother graphics ri se. To deliver these features on the newest generation of consoles, Microsoft and Sony had to shift their architecture paradigm for the design of the Xbox 360 and Playstation 3, emphasizing pa rallelization instead of dependence on a single CPU core. My study provides a software architecture to make use of the multiple cores of next generation hardware. To demonstrate these pr inciples, my study focused on the design of a predator/prey ecosystem model, whose main pro cesses are split across different threads. A blackboard system and messaging architecture handles data c oherency across the different threads while coordination is handled by a planne r system, which sets the overall goal for each individual entity. This design aims to maximize what can be para llelized as well as provide data coherency that is not tightly coupled to a particular system. The result of my study was a more robust software architecture that has the potential to deli ver a deeper, richer experience to the user, as well as lowering the cost of developm ent of games on these consoles.

PAGE 10

10 CHAPTER 1 INTRODUCTION On Nove mber 22, 2005, the launch of the Mi crosofts Xbox 360 brought with it a new era for video game development. Every advent of new console hardware comes with higher expectations on what can be delivered in the users game experience. Games like Madden NFL 06, Project Gotham Racing and Condemned, whic h were available on launch day, promised smarter, more interactive NPCs (non-player char acters), lush, realistic environments, expansive worlds and a richer gamer experience than anyt hing that was previously seen in the previous generation of game consoles. To deliver on th ese promises, the hardware manufacturers had to drastically change the way the consoles were designed. Chapter 2, Next Generation Develo pment, covers the hardware architecture for the current and next generation of consoles. At the end of the Xbox and Playstation 2 lifecycles, developers found that the single core hardware of that generation has been al most fully utilized to its full potential by game developers. It became clear to Sony and Microsoft th at increasing the clock speeds on their processors or marginally improving their throughput on a single Central Processor Unit (CPU) core would not satisfy what they were trying to achieve with their next iteration of hardware. This insight signaled the end of the single core era and the beginning of multi-core architectures for video game consoles. To take full advantage of the next generation of console hardware, the designs had to center around doing more work in the same amount of time. Microsoft accomplishes this with their four powerful multi-purpose cores with two hardware thread s running on each core. Sony chose a different route, going with their PPE/SPE architecture, where the cores are less powerful, but are more specialized and more of them exis t to distribute the work among. To make use of this new architecture, from a game developm ent standpoint, developers had to focus on

PAGE 11

11 parallelizing the work to dist ribute it to each CPU thread or processing element. My study focuses on decoupling the traditi onal concept of a game loop to better utilize the Xbox 360 and Playstation 3 hardware. Chapter 4, Simulation Design, covers the implem entation and design. The system contains several layers of predators and preys, with each entity trying to find and consume their food source as well as trying to stay alive by running away from their natural predators. The apex predators in the simulation are lions, who work in packs and employ a layer of coordination for catching their prey. The medium level entities are antelopes, which are autonomous entities whose primary goals are to feed a nd stay alive. The bottom of the food chain entities are plants, whose only goal is to provide a food source for th e antelopes. This simulation and video games both need similar processing. The work in this simulation is divided in to common logic pieces of execution that are common in all game engines. This simulation breaks out the processing for audio, rendering, and simulation processing as well as pack coordination from the main l oop and processes each in a separate thread. Coordination is done by a planner system, which determines what A.I. state each entity in the pack should be in and ensures they are in that state, similar to Orkins system used in F.E.A.R [Orkin 2005]. A major concern that needed to be addressed in this simulation is data coherency. In a single threaded environment, the state data can be assumed to be shared and can only be altered by the current instruc tion. Moving to a multithreaded environment, those same assumptions cannot be made. Separate threads c ould be examining or modifying the same piece of data. This implementation uses both a blac kboard system and a messaging system to address these issues.

PAGE 12

12 These systems aim to decouple the state data fo r each entity from the threads that utilize them. The blackboard system keeps track of each entitys state information. If another entity needs information about others or the world, it can query the blackboard instead of calling the entity directly. Updates to an entitys state information are registered immediately to the blackboard. The messaging system is used to pass data from the simulation thread, which contains all the entity information, to the othe r threads. The render and audio threads do not have any concept of the entity representation themselves. The only information needed is the state data on which it works on. By using thes e systems and employing the designs in my study, the results show that game processing can be decomposed in this manner and that the architecture allows for easier expans ion and modification in the future. In the results section, Chapter 5, an examinati on of the simulation results is reviewed and analyzed not only from a computational standpoint, but also from a developers perspective. To test this simulations performance, a comparis on was performed on the average time each thread executed in single-threaded mode and multithre aded mode. By distributing the work and decoupling the processing, the average time spent in each thread decreased significantly. By keeping the systems separate, iterating and a dding new functionality became quicker and had a lower impact on the overall architecture. Chapter 6 summarizes the findings and explorers future areas of research.

PAGE 13

13 CHAPTER 2 NEXT GENERATION DEVELOPMENT This chapter covers th e hardware for the prev ious and current generation of game console hardware. The Xbox and Playstation 2 are single core consoles with si ngle-instruction stream multiple-data streams (SIMD) vector processing unit. With the next generation of console, this shifted toward multi-processor hardware. With console development, hardware and software work very closely together. This chapter also briefly covers software design for video game consoles. Generation 2 Console Architecture Xbox Architecture The Xbox architecture consists of a single core CPU and Gr aphics Processor Unit (GPU) along with a unified m emory system. The Xboxs memory system allows either processor to access the same memory. The CPU a llows the instructions to be ordered in a single-instruction stream multiple-data streams (S IMD) manner to increase the throughput of the processor. The GPU allows the use of programmable shaders, wh ich can offload rendering specific work from the CPU onto the GPU. Playstation 2 Architecture The Playstation 2 uses the Em otion Engine, wh ich features a single CPU core to handle general processing while also relying on a numbe r of smaller specialized processing elements (PE) to do specific tasks (Figure 2-1). The S ound Processing Unit 2 (SPU2) is one such unit, performing all the sound processing on the console. The Input Output Proce ssor (IOP) is used to provide backwards compatibility for Playstati on 1 games. Both the SPU2 and IOP are very specialized and self-contained. The Playstation 2 features two vector processing units (VPUs), one dedicated to processing simula tion data and the other dedicated to processing graphics data.

PAGE 14

14 Each PE has its own memory space. To transf er work from one unit to the other requires a Direct Memory Access (DMA) to copy the data from one destination to the other. Next Generation Console Architecture Xbox 360 Microsofts Xbox 360 fe atures three independent PEs: each one capable of executing two hardware threads (Figure 2-2). The hardware threads on each PE share the same execution unit, so the gains from parallelism are not as large as from an independent thread architecture [Dawson 2006]. The system design implements a unified memory, which is the same as its predecessor, the Xbox. The philo sophy for this design is to di rect the programs parallelism away from the instruction level and into the thread level [Sto kes 2005]. It is now up to the programmer to organize the execution to take advantage of the hardwares parallelism instead of relying on the compiler to make th e code execute faster. Each core contains a vector processing unit, which supports SIMD instruction issuing. Playstation 3 The Playstation 3 arch itecture is a drastic de parture from Sonys pr evious generation of hardware, the Playstation 2 (Fi gure 2-3). The backbone of this design is the Cell processor, which consists of a Power Processor Element (PPE), which handles setting up the work for the Synergistic Processor Elements (SPEs). The PPE has two hardware threads that alternate issuing instructions to the SPEs. There are seven active SPEs on the Playstation 3. Each SPE is designed to perform a small specific task quickly. The SPE is an independent vector processing unit that specializes in performing SIMD tasks. These processors contain local stores, which are small memo ry units that are attached to each individual SPE. The local stores offer quick access to memory, like cache, but do not need to worry about data coherency. The tradeoff is the data has to be copied in when the SPEs work

PAGE 15

15 is started and copied out when the work is complete. This copying is accomplished through a DMA, just like Sonys previous generation of hardware. Because the performance of a Playstation 3 is highly dependent on transferring work around quickly, an ultra fast bus is used. Memory transfers along the Playstation 3 bus is accomplished at the rate of 25.6 gigabytes/second while I/O transfers are perfor med at the rate of 76.8 gigabytes/second. Software Design Ga me loops have traditionally contained all th e processing necessary for each frame of the game [LaMothe 1999]. The games main loop sequentially processes each piece of the game one step at a time, starting with the simulation pr ocessing and ending with the rendering. A speedup could be achieved by vectorizing the instruc tions being executed [Dobson and Brace 2003], but on current generation architectures, it is still c onstrained by the single core. The next generation consoles improve by expanding on this concept of spreading out the work to multiple cores. Threading Multithreading is the concept of dividing the work am ong independent processing units to make minimize the CPUs idle time [Schildt 2004]. This is a powerful tool because it allows the programmer to accomplish more work in the same amount of time and to do it in a more efficient manner. Switching from a single threaded applica tion to a multithreaded environment is not as trivial as creating threads a nd dividing work among them. Without designing up front and thinking about the interaction between threads, wh at could be implemented is a system that is more complex and may see little or no performance gain [Dawson 2006]. Designing for multithreaded systems is a departure from the traditional way programmers think of performing an action. Instead of relying on a sequential set of inst ructions to perform a function, the program now has mu ltiple independent logical opera tions working together to perform the desired action [Mnkknen 2006]. The most important part of the system design is

PAGE 16

16 to find independent logical units of executi on and managing the points where those execution units do have to intersect. Mnkknen describes three methods for implem enting parallelism in game engines. Synchronous functional parallelism divides the wo rk among different threads, but has some notion of order. Some threads may need information provided by another thread. Asynchronous functional parallelism is based on the principle that the threads run whenever they want with whatever data are available. Data parallelism involves allowing multiple threads to work on the same set of data types. Next generation console architectures uses all th ree of these models. Conclusion This chapter provided an overview of the hard ware for the current and next generation of consoles. T he focus on the next generation of consoles is to spread the work across multiple cores. To support this type of architecture, we saw increases in the bus speeds and memory architecture, specifically for the Playstation 3. Threading was discussed, covering a high level overview of the concept and its impact on game so ftware design. The next chapter will discuss how we could take advantage of this architecture. Figure 2-1. Sonys Play station 2 architecture

PAGE 17

17 Figure 2-2. The Xbox 360 architecture

PAGE 18

18 Figure 2-3. Sony Playst ation 3 architecture

PAGE 19

19 CHAPTER 3 SIMULATION ARCHITECTURE This chapter covers designing a system that takes advantage of th e next generation of console hardware. A large portion of this desi gn revolves around decoupli ng the data to allow each thread to run as fast and independently as possible. The hardware setup is simulated as software threads. To lower the cost of de velopment, unit tests ar e used to validate the subsystems. Simulation To adapt to next generation console architec tures, the design focuses on fully m aximizing the threaded environment on the hardware as well as promoting a design that maintains scalability for a large system. To simulate the next generation console hardware, my study created multiple threads, with each thread perf orming a major piece of work from the games main loop. The data is shared among the different threads via a messaging system, which transfers state data from one thread to the ot her. Entities share their information through a blackboard system, which contains a copy of all th e important state information for each entity. Decoupling the state data from the entities in this manner allows the system to expand while having a lower impact on the existing system. At any given time in the simulation, an enti ty is executing an assignment to achieve a motivational goal. After processing an assignment during each frame, an entity uploads its state information to the blackboard. This allows ot her entities to discover information about each other or the environment while al lowing the entities to continue working in a thread-safe way. The blackboard is responsible for relaying info rmation to the other entities as well as the other threads. During each frame, the blackboa rd posts the entity information to the message system, which is then read by the other thr eads such as render and audio. There is no

PAGE 20

20 coordination mechanism for when to read or write between each thread. The assumption is the thread information is the latest or within a few frames of the late st. The work done in each frame by the threads is tolerant enough to lose a frame or two of information without being noticeable to the user. Figure 3-1 shows the information fl ow from the entities to the subsystems running on each thread. The blackboard system, used by the simulati on, passes information about the entities to other entities and other threads. All communicable information about an entity is encapsulated by a blackboard state. Entity information is stored as a map, with the entity id being the key. Lookups and updates are all performed by pass ing the entity id along with the updated information about the entity. Figure 3-2 shows the flow of information to a nd from the blackboard. In step 1, an entity processes its assignment and updates its state information. After this is done, the entity updates the blackboard with this information, as show in step 2. At the end of the simulation step for PackHunt, the blackboard transmits the state information for a ll the entities to the message system, as shown in step 3. The messaging system provided a way to pass information around in a thread-safe and decoupled manner. The messaging system was res ponsible with storing its own local copy of the state for each entity while the ca lling threads were responsible for keeping their own local copy of the state data. This allowed data passing to occur with a minimal amount of time where one thread would have to wait for the other to finis h. Figure 3-3 diagrams th e flow of information from the sim thread to the other threads. The ThreadManager class manage s all the threads for the simulation. In the simulations multithreaded mode, all the threads are started by the ThreadManager. In single threaded mode,

PAGE 21

21 the ThreadManager ensures each threads process method is called in a sequential manner (Figure 3-4). Figure 3-5 shows that in the mu ltithreaded mode, each logical process (e.g., audio or sim processing) is running i ndependently of one another. The assignment system is responsible for cr eating and deleting assignments used by the simulation. When an entity needs a new assignment, it queries the assignment system for the needed state. The assignment system then dest roys the previous state, creates the new one and initializes all the parameters needed before passing it back to the ca ller. The assignment parameters are pointers to the state data for each entity. By using the state data of each entity directly, my study was able to decouple the behavior of each assignment from each entity. The entities did not need to know anything about the assignment specific logic, while the assignments did not need to worry about passing data and state information back and forth with the entity. Unit Testing Unit testing was im plemented as part of my st udy as a way to test new subsystems in an independent way as well as to ensure existing or added functionality performed in the expected manner. By creating and testing in this environment, the added interfaces to the subsystems were ensured to work correctly and provide the correct information. This allowed for faster iteration time when adding a new or modifying an existing subsystem. Unit testing also ensured that adding new functionality did not break existing functionality. Conclusion This chapter discussed using a m essaging system and blackboard system to separate information from the different threads. This allows each thread to run as separate logical process, pulling whatever data it needs from th e messaging system. The next chapter discusses how this system is used to create a simula tion for an ecosystem. The simulation uses the blackboard and messaging system to create c oordinated behavior for the entities.

PAGE 22

22 Figure 3-1. Information flow in PackHunt simulation Figure 3-2. Blackboard interaction graph Figure 3-3. Message system flow

PAGE 23

23 Figure 3-4. Single-threaded processing Figure 3-5. Multithreaded processing

PAGE 24

24 CHAPTER 4 SIMULATION DESIGN This chapter discusses implem enting the system design described in Chapter 3 to simulate a predator-prey ecosystem model. The entities in the system have preys that they feed on and predators that they try to a void. Their behavior is contro lled through assignments, which represent a shared type of beha vior. This simulation uses an object-oriented approach for the assignments and the implemented systems. This chapter also contains an overview for each object in the implementation. System Design This sim ulation illustrates the architecture outlined in Chapter 3 by modeling coordinated behavior for the predator entities. The apex pred ators in this system are lions, which belong to a pack. When a lion spots a prey entity, it signals the PackManager that a viable prey has been spotted. The PackManager then uses this information and factors in the environmental parameters to determine if this is an ideal situation to stalk that prey. If the situation is ideal, then all the pack members are given a stalk assignment; otherwise, the lions are left in their current assignment. Each lion entity is entirely dependent on the PackManager to determine what state it should be in and when. Gathering the data about entities and the environment is performed by interaction with multiple systems in this simulation [Orkin 2005]. Simulation Simulation. The sim ulation portion of my study contains the ecosystem simulation populated with entities in the world. There are two windows created for the program. One displays the simulation itself while the other contains controls for tuning certain properties in the simulation. Figure 4-1 shows the simulation with the tuning window. PackHunt. PackHunt is the main object that starts the simulation. It is responsible for starting the program and creating th e windows used by the simulation.

PAGE 25

25 GameCommon. This class contains all the property parameters for the simulation. The properties specified include world properties, information about the entities in the simulation as well as information about how the simulation functions. Some of these properties are dynamically tunable. GameCo mmon also is responsib le for creating and monitoring the tuning window used by the simulation. World. This class is responsible for starting and populating the simulation world. Entity. All entities derive from the LivingEntity class. LivingEntity. This is the base class for all living entities. It contai ns common attributes and methods shared by all the entities. The processing for ent ities is done on the simulation thread. Each entity interacts w ith the world through th e blackboard system, posting information about itself and retrieving information about othe rs. Figure 4-2 shows the inheritance hierarchy for all the entities in the simulation. Plant. This class represents the plant entity in th e simulation. Plants ar e always in the idle assignment state, which means they have no mo bility and only switch between the live and dead states. Antelope. This class represents the antelope ent ity in the simulation. Antelopes are single entities, with no coordinated behavior with ot her entities. Their primary goal is to find plants on which to feed and will only divert from that assignment if they spot a predator within their vicinity. Lion. Lions are the apex predators in this simulation, who have no natural competing species. Each lion belongs to a pack, which determines the overall goal for the individuals. Each individual performs their assignment with no knowledge of the other members, depending predominantly on the pack to determin e what is best for their coordination. Pack. The pack object is the planning system fo r the lion entities. The pack object keeps track of the entities and the environment. Th e planning system then determines what the ideal assignment is for the pack, ensures ea ch member is executing the right assignment, and coordinates their behavior with the other members. PackManager. This class is the manager object for all the packs in the simulation. It determines which entity will be long to which pack and keeps track of their states. The PackManager does its processing on a separate thread. Blackboard State. The BlackboardState object is the in formation structure that describes an entity to other systems. Blackboard. The Blackboard object keeps track of all the state information for the simulation. This allows for other systems to que ry and use this information in a thread safe manner. Each entity updates their information to the blackboard when they have finished processing their assignm ent.

PAGE 26

26 MessageSystem. The MessageSystem class passes information about the entities to the other threads that need the information. Th e render thread uses this information to determine how to draw the entities in the simulation. The audio thread uses this information to determine if any sound effect s were triggered and plays them. This interaction is shown in Figure 4-3. ThreadingSystem. The threading system is responsi ble for dividing the work in the simulation and ensuring everything is processed correctly, in the right order. It uses software threads to simulate the hardware cores used by the Xbox 360 and Playstation 3. Thread. This is the base class for a single logi cal piece of execution. It contains common functionality that is used by the other threads. Audio. The Audio thread handles the audio processi ng for the simulation. It keeps track of the state information coming from the blackboard, and if a sound effects flag is set, it will trigger the appropriate s ound in the simulation. Render. The Render thread is responsible for draw ing the physical representation for the simulation world and all the entities in it. Figure 4-4 displays the simulation running. Sim. The Sim thread handles processing all the entity assignments and uploading the entity information for the other threads. AssignmentSystem. The AssignmentSystem object manages all the entity assignments in the simulation. Assignment. This is the base class for all the assign ments in the simulation. It contains the common behavior used by all other assignments. AttackAssign. The AttackAssign assignment handles moving an entity toward a food source. IdleAssign. The IdleAssign assignment is the defau lt world assignment for an entity. It has no other behavior than to k eep track of when to respawn an entity if it is dead. RunawayAssign. The RunawayAssign state is responsible for moving an entity away from a predator until it is back in a non threatened situation. StalkAssign. The StalkAssign assignment handles moving an entity into some ready position for a planned, coordinated attack. TestAssign. The TestAssign assignment is the test case assignment to ensure data are correctly passed from the entity to the assignment. WonderAssign. The WonderAssign state handles moving the entity around in the world. This assignment is meant to be a complim ent to som e other assignment to meet an objective. For example, the wonder assignment is used to move an entity until it is within

PAGE 27

27 range of seeing a food source, then the entity will then be put in the attack state to head toward and consume that food source. RenderEngine. The RenderEngine is responsible for th e actual drawing of the simulation. For my study, OpenGL was used as th e technology for drawing. For future implementation, it could easily be changed to some other technology by replacing just the RenderEngine object, with little impact to the rest of the subsystems. MetricReporter. The MetricReporter object handles keeping track of the simulation metrics for this project. It supports the ability to export all that informa tion into a text file. This text file was used to analyze the results of the simulation. Those results are later analyzed in Chapter 5. Unit Testing Unit tes ting was used to validate the functi onality and interfaces for the subsystems developed for my study. UnitTest. The UnitTest class was used to start the unit tests for each subsystem. BlackboardUnitTest. The BlackboardUnitTest was used to test the func tionality of the Blackboard system. MessageSystemUnitTest. The MessageSystemUnitTest was used to test the functionality of the messaging system. ThreadManagerUnitTest. The ThreadManagerUnitTest was used to test the functionality of the threading system. AssignmentUnitTest. The AssignmentUnitTest was used to test the functionality of the assignment system. Conclusion This chapter discussed th e ecosystem simula tion implemented using the next generation design described in Chapter 3. An overview is given for all the object classes for the simulation and how they fit together. The next chapter discusses the results collected from this simulation as well as an analysis of those results.

PAGE 28

28 Figure 4-1. PackHunt simu lation with tuning window Figure 4-2. Entity hierarchy

PAGE 29

29 Figure 4-3. Message passing Figure 4-4. PackHunt simulation

PAGE 30

30 CHAPTER 5 RESULTS AND ANALYSIS Introduction The system design aims to improve the perf ormance and development process for next generation consoles. To improve the performance, the architecture needs to take advantage of the hardwares multiple cores. This was perfor med by splitting the work traditionally done in the games main loop into independent processes that could be run on separate threads. Another focus of my study was to improve upon the softwa re development process for these projects. This chapter discusses improving the software development process, which involves lowering the cost of development overall for the project. With the promise of what next generation co nsoles can deliver comes the cost of more code to manage, more engineers working on the code base and an increase in the number of places where breakdowns could occur during devel opment. The aim of my study was to design a system that reduces the amount of dependencies by each subsystem, increases the stability of new code being introduced as well as abstracting details about a s ubsystem from things that did not need to know about it. These objectives were achieved by using object-oriented programming principles to organi ze the class structures, unit tests to ensure stability and object interfaces to decouple systems from one another. The next subsection covers the findings of my study. Results and Analysis For the sim ulation, the antelopes were give n a significant speed boost when trying to escape a threat, such as a stalking lion. This forced the lions to be more dependent on stealth and coordination, waiting until the very last moment until moving in for the kill. With the default simulation parameters, the packs success rate fo r capturing a prey was 52%. This number is

PAGE 31

31 actually low, due to the fact that most of the unsuccessful takedown attempts happened along the border of the simulation. If an antelope wraps around the world by moving off the boundary of the world, then the chase was abandoned. It was observed that most chases occurring within the 80% interior area of the world saw a 100% success rate for the packs chases. The hardware cores have to work independently but together to delive r the type of content expected for next generation cons oles. Traditionally, in previous generation of consoles, all the work was done by a single thread. The games were constrained by the amount of processing that could be done by that single frame on that si ngle thread. This was observed when running the simulation in single threaded mode (Table 5-1). The data collected here was the total cycles from three runs of the simulations. The data shows that the main loop is the sum of all the work done by each of the other threads. Table 5-2 shows the simulation running in multithreaded mode. Each thread is now able to run independently of each other. A comparison of the numbers in Tables 5-1 and 5-2 shows a significant increase in cycle time. This is due to the thread context switch time for the test. The test cases were run on a single core comput er using multiple software threads. The timing was captured by taking the different ial of the start time when entering the threads main process method and end time when leaving the method. If there was a context switch in the middle of processing, that time w ould inflate the total tim e spent processing the thread for that frame. With the advent of next generation console came a shift in the way games were made. More content meant more code created by more e ngineers on a project, which leads to a higher cost of development. In an attempt to re duce these costs, my study focuses on reducing the

PAGE 32

32 amount of time fixing bugs, increasing stability and designing maintainable code. Reducing the amount of bugs and stability are separate issues but can be addr essed in the same manner. Unit testing was used to ensure new pieces of functionality were introduced with as few bugs as possible. There was a small cost of deve loping the unit tests, but that cost was offset by not having to spend that time tracking down bugs later in the developm ent cycle. All the development time was entered into a log for my study. Figure 5-1 shows the time spent for this project. The chart shows that a large percentage of time was spent working on the implementation and only a small fraction of time was needed to fix bugs in the program. Without unit testing, there would be a small reduction in the implementation time spen t but a big increase in debug time. The code cleanup section involved cl eaning up dead code, commenting the code and adding method/file headers into the files. Implementing maintainable code meant designi ng for portability. The assignment system was an example of this. Each assignment had a specific task and was not concerned with what type of entity was performing it. By encapsulatin g their behavior into obj ects, this functionality could be shared among several entities. The idle assignment is used by all three entities in the simulation. Another example of portabi lity was the rendering system. Initially, the implementation was performed us ing DirectX. Halfway through, that effort was shelved in favor of an OpenGL implemen tation. Changing the draw system had minimal impact because the functionality was only e xposed through interfaces. The only files that changed were the render systems .h and .cpp files. As long as the new rendering system offered the same interfaces, the other subsystems do not need to know or care about the change.

PAGE 33

33 My study provides a roadmap on developing for next generation consoles. Shifting hardware design means developers had to shif t the way they think about tradition game simulations. A move toward multithreaded envir onment means better content and more content over what was ever delivered on the previous ge neration of hardware. To meet these demands, more code had to be generated. To maintain this growth in the code base size, the processes in place had to ensure the engineers on these projects worked smarter, not harder. Process changes that could lower the cost of development long term are adoptions of newer programming principles such as object orient ed programming, investing in th e software validation process, designing the system for tomorrow and not just for today. This chapter discussed the advantages of decoupling the work, allowing each thread to act independently. The discussion al so provided an analysis of th e effectiveness of the planner system. Chapter 6 summarizes my study and discu sses possible future work in this area.

PAGE 34

34 Table 5-1. Total thread time in single threaded mode of simulation, in cycles Singlethreaded Audio Render Sim PackMgr Main case 1 533 1291 40 0 1864 case 2 660 1002 50 0 1712 case 3 550 920 20 0 1490 Table 5-2. Total thread time in multithread ed mode of the simulation, in cycles Multithreaded Audio Render Sim PackMgr Main case 1 910 5569 820 0 0 case 2 700 5331 831 0 0 case 3 1102 5639 1051 0 0 p Debug time 6.65% Code cleanup 5.07% Unit test 10.61% Implement time 77.66% Figure 5-1. Thesis development time

PAGE 35

35 CHAPTER 6 CONCLUSION Summary Im plementing a next generation game on the Xbox 360 and Playstation 3 is more complex and time consuming than anyone originally an ticipated. The audien ce expectations have increased the number of features delivered, the depth of each feat ure and the time spent working on those features. To deliver this type of content, programmers ha ve been making use of parallelization of work. Chapter 3 discusses how, by having multiple cores, the hardware is able to do more work within each processing frame by offloading complex task to these cores and having them work independently with a small le vel of coordination between the threads. The tradeoff is the programmer has to explicitly ma nage the thread-level parallelism from the software. The ecosystem simulation implemented in Chapter 4 illustrates that this architecture could take advantage of the parallelized power of the next generation consoles by splitting the traditional game loop into independent logical chunks of processing that could be handed off to another processing element. The simulation is a simple three entity system composed of different types of animals. Each entity has dis tinct behavior for how th ey interact with each other and the environment. The autonomous entities in the simulation are plants and antelopes. Antelopes feed on plants and try to stay away from lions, viewi ng the world and their objectives only from their perspective. There is no unifyi ng behavior between the antelope entities. Lions implement a more robust behavior, coordinati ng their attack with peers in the pack. The planning is accomplished by a PackManager, which oversees what state each individual in the pack should be in based on the current environmental parame ters. The planning processing for the pack is

PAGE 36

36 done on a separate thread. The other parts of the simulation that are processing their logic on separate threads are the sim, rende ring and audio. The results chap ter of this study is an analysis on the performance of this system in a threaded environment as well as th e process of developing the simulation. The data discussed in Chapter 5 were gathered by running test cases for the simulation in both single-threaded and multithreaded mode. Wh at was observed in the single-threaded data was a constraint on the processing by the games main loop. The simulation could only run as fast as the main loop would allow. By running the simulation in a multithreaded environment, the games main loop had a processing time of zero. Now, the work was only constrained by how fast the individual work threads could run and not the main loop. As part of the development, unit testing was used to validate func tionality and interfaces for the major systems. This had a large efficiency impact, where only 7% of the time was needed to locate bugs and address issues with the implementation. My study is not the definitive guide for how to develop applications on the next generation of video game consoles. It only defines a possible approach to ach ieving thread level parallelism on the hardware. Parallelism was achieved by boiling down the work traditionally done in each game to its essential parts and running their execution on an independe nt processing element, whether that is a hardware thr ead on a CPU core of the Xbox 360, a SPE for the Playstation 3 or a software thread, which was the case for this simulation. Part of this work was also designing an architecture that decoupled the behavior and properties for each system in such a manner that the work could be handed off to the PEs. Possible Future Work Future work in this area could be broken dow n into short term and long term goals. In the near future, the gam e development industry will see a shift toward achie ving better performance

PAGE 37

37 and delivering more content by making use of all the hardware available. This means every cycle will be an active cycle, a nd not spent doing an id le operation. An example of this is NVIDIAs current exploration of exciting ways to use the GP U cards to do non-traditional GPU work. The GPU typically does all the processing fo r render operations. This year, NVIDIA introduced their PhysX and Cuda technology, wh ich allows the programmer to push non-GPU related work onto the GPU. The type of probl ems that would benefit most from the GPU is SIMD operations on large sets of independent data PhysX and Cuda are just the beginning of a revolution into exploring non-traditional ways to get the most out of the hardware. A longer term goal would be improving the software development process for video games. The shift from Xbox and Playstation 2 to Xbox 360 and Playstation 3 has seen an increase in the number of people needed for these projects as well as the amount of time needed. To lower the cost of development, an effort n eeds to be made to invest in unit testing and development of tools to ensure programmers are working smarter and not ha rder to deliver these products.

PAGE 38

38 APPENDIX A RAW COMPUTATIONAL DATA Table A-1. Single threaded tim e Singlethreaded Audio Render Sim PackMgr Main case 1 533 1291 40 0 1864 case 2 660 1002 50 0 1712 case 3 550 920 20 0 1490 Table A-2. Multithreaded time Multithreaded Audio Render Sim PackMgr Main case 1 910 5569 820 0 0 case 2 700 5331 831 0 0 case 3 1102 5639 1051 0 0

PAGE 39

39 Table A-3. Antelope metrics, test case 1 TYPE ID #suc chase #total chas e #suc run #total run # target ANT 45 6 6 0 0 0 ANT 46 6 8 3 3 0 ANT 47 1 1 4 5 1 ANT 48 5 7 4 4 0 ANT 49 5 6 2 3 1 ANT 50 6 7 4 5 1 ANT 51 6 7 3 3 0 ANT 52 7 9 2 2 1 ANT 53 6 6 0 0 0 ANT 54 6 6 3 3 1 ANT 55 7 9 4 4 1 ANT 56 9 9 4 4 0 ANT 57 8 10 7 7 1 ANT 58 3 3 2 2 0 ANT 59 3 3 0 1 1 ANT 60 6 10 8 8 0 ANT 61 6 6 3 3 1 ANT 62 7 7 0 1 1 ANT 63 2 5 4 4 0 ANT 64 6 8 3 5 2 ANT 65 3 3 2 2 0 ANT 66 7 8 0 0 0 ANT 67 6 9 4 4 0 ANT 68 8 10 4 4 0 ANT 69 6 7 6 6 0 ANT 70 6 7 4 4 0 ANT 71 5 7 4 4 1 ANT 72 6 6 0 0 0 ANT 73 7 7 4 4 0 ANT 74 5 8 3 3 0 Total: 170 205 91 98 13

PAGE 40

40 Table A-4. Antelope metrics, test case 2 TYPE ID #suc chase #total chas e #suc run #total run # target ANT 45 1 1 4 4 0 ANT 46 8 9 4 4 0 ANT 47 4 5 5 6 1 ANT 48 9 10 0 0 0 ANT 49 9 9 0 0 0 ANT 50 5 5 2 3 1 ANT 51 12 13 7 7 5 ANT 52 7 7 0 0 0 ANT 53 5 6 1 1 0 ANT 54 3 4 1 2 1 ANT 55 9 10 2 3 1 ANT 56 7 9 7 7 0 ANT 57 2 3 4 5 1 ANT 58 3 4 7 7 0 ANT 59 9 9 1 1 0 ANT 60 10 10 0 0 0 ANT 61 3 4 3 5 1 ANT 62 6 7 0 0 0 ANT 63 8 8 1 1 0 ANT 64 2 2 2 2 0 ANT 65 7 9 10 10 0 ANT 66 3 4 3 4 1 ANT 67 6 11 4 5 0 ANT 68 5 6 5 5 2 ANT 69 6 6 0 0 0 ANT 70 11 14 7 7 1 ANT 71 8 8 3 3 0 ANT 72 3 6 5 6 2 ANT 73 3 4 1 2 1 ANT 74 10 11 3 3 0 Total: 184 214 92 103 18

PAGE 41

41 Table A-5. Antelope metrics, test case 3 TYPE ID #suc chase #total chas e #suc run #total run # target ANT 45 8 8 0 0 0 ANT 46 4 4 6 6 1 ANT 47 8 8 0 0 0 ANT 48 3 6 7 8 2 ANT 49 5 5 2 2 0 ANT 50 7 7 0 1 1 ANT 51 3 3 4 4 0 ANT 52 9 10 2 2 0 ANT 53 7 7 3 3 0 ANT 54 5 8 4 5 2 ANT 55 2 6 6 7 1 ANT 56 10 11 1 2 1 ANT 57 7 8 0 0 0 ANT 58 7 7 2 2 0 ANT 59 3 5 3 3 0 ANT 60 8 9 0 0 0 ANT 61 7 8 3 3 0 ANT 62 6 6 0 0 0 ANT 63 6 6 1 1 0 ANT 64 4 6 7 7 0 ANT 65 7 8 0 0 0 ANT 66 7 7 0 0 0 ANT 67 5 6 0 0 0 ANT 68 2 6 6 7 1 ANT 69 3 6 6 6 1 ANT 70 2 3 0 0 0 ANT 71 5 5 1 2 1 ANT 72 6 6 0 0 0 ANT 73 4 6 3 5 3 ANT 74 2 4 3 3 0 Total: 162 195 70 79 14

PAGE 42

42 Table A-6. Lion metrics, test case 1 TYPE ID #suc chase #total chas e #suc run #total run # target LN 175 3 5 0 0 0 LN 176 3 5 0 0 0 LN 177 3 5 0 0 0 LN 178 3 5 0 0 0 LN 279 2 5 0 0 0 LN 280 3 5 0 0 0 LN 281 2 5 0 0 0 LN 282 2 5 0 0 0 LN 383 1 3 0 0 0 LN 384 1 3 0 0 0 LN 385 1 3 0 0 0 LN 386 1 3 0 0 0 Total: 25 52 0 0 0 Table A-7. Lion metrics, test case 2 TYPE ID #suc chase #total chas e #suc run #total run # target LN 175 5 6 0 0 0 LN 176 5 6 0 0 0 LN 177 5 6 0 0 0 LN 178 5 6 0 0 0 LN 279 3 4 0 0 0 LN 280 3 4 0 0 0 LN 281 3 4 0 0 0 LN 282 3 4 0 0 0 LN 383 1 8 0 0 0 LN 384 1 8 0 0 0 LN 385 1 8 0 0 0 LN 386 1 8 0 0 0 Total: 36 72 0 0 0

PAGE 43

43 Table A-8. Lion metrics, test case 3 TYPE ID #suc chase #total chas e #suc run #total run # target LN 175 3 5 0 0 0 LN 176 3 5 0 0 0 LN 177 3 5 0 0 0 LN 178 3 5 0 0 0 LN 279 3 5 0 0 0 LN 280 2 5 0 0 0 LN 281 2 5 0 0 0 LN 282 2 5 0 0 0 LN 383 3 4 0 0 0 LN 384 3 4 0 0 0 LN 385 3 4 0 0 0 LN 386 3 4 0 0 0 Total: 33 56 0 0 0

PAGE 44

44 LIST OF REFERENCES DAWSON, B. 2006. Coding for Multiple Core s on Xbox 360 and Microsoft W indows. In Proceedings of Game Developers Conference 2006. Gamasutra, San Francisco, CA, 25-28. DOBSON, J. AND BRACE, P. 2003. Porting a PS2 centric Game to Xbox: A Case Study of State of Emergency. In Proceedings of Game Developers Conference 2003 Gamasutra, San Fransisco, CA, 51-55. LAMOTHE, A. 1999. Journey into the Abyss. In Tricks of the Windows Game Programming Gurus Ed. Sams, Chapter 2, 17-46. MNKKNEN, V. (2006, September 6). Multithreaded Game Engine Architectures Retrieved October 15, 2008, from http://www.gamasutra.com/features/20060906/monkkonen_01.shtml ORKIN, J. 2005. Agent Architecture Considerat ion for Real-Tim e Planning in Games. In Proceedings of AIIDE 2005 AAAI, Marina Del Rey, CA, 213-243. SCHILDT, H. 2004. Multithreading in C++. In The Art of C++ Ed. McGraw-Hill, Chapter 3, 67-118. STOKES, J. (2005, June 1). Inside the Xbox 360, Part II: the Xenon CPU Retrieved October 15, 2008, from http://arstechnica.com/ar ticles/paedia/cpu/xbox360-2.ars

PAGE 45

45 BIOGRAPHICAL SKETCH After graduating high school, Thien Nguyen attended undergraduate school at the University of Florida. He m ajored in comput er and information science with the dream of making video games for a living. During his time at UF as an undergrad, he participated in a number of engineering activ ities for his college. He participated in the ACM programming competition, representing UF at the IBM sponsored event in 2000. Working with Dr. Sumi He lal, he also led a cross-discipline team in developing a system for portable site surveying (2000-2001). This had many applications in the telecommunication and intelligence gathering comm unity. This project was documented as part of Thiens honors thesis. Undergraduate degree in hand, he graduated and accepted a position at defense contractor Harris Corporation. At Harris, he worked on many Harris R&D projects as well as applications for the United States government; the most significant being so ftware used by the FAA for flight navigation and weather tracking. Thien left Harris in 2005 to purse an oppor tunity to develop video games at EA. He led the audio development for EAs new Superman IP, which was a first-generation game for the Xbox 360. Since shipping the Superman title, Thien has worked on a number of football titles, wearing many engi neering hats and working on ever y engineering area involved in making a game. Thien has an undergraduate degree from the Univ ersity of Florida (2001) and a masters degree in computer engineering ( 2008) from the University of Florida. He is currently an engineer at EA, specializing in game deve lopment for the Xbox 360 and Playstation 3.