Simple Computer Games Using Java Dr. Brian C. Ladd Dr.

Jam JenkinsSimple Computer Games Using Java Dr. Brian C. Ladd Dr. Jam Jenkins Contents Contents i 1 Getting Started: What s in a Game? 1 1.1 Learning From Simple Computer Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 What s In a Game? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Active and Passive: Rules Followers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4 Running a Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.5 Strategies: Winning a Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.6 What is in a Computer Program? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2 Designing Your First Program 25 2.1 BasketBall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.2 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.3 Creating Executable Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.4 FANG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.5 Finishing Up BasketBall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3 FANG: A Survey of Classes 53 3.1 How Computers Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.2 FANG Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.3 Examining a Public Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4 Deciding What Happens: if 93 4.1 A Simplest Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 4.2 Computer Program (Game) Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 4.3 Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.4 Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 4.5 Finishing NewtonsApple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 4.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

5 Components: Names, Types, Expressions 121 5.1 Randomness in a Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 5.2 One More Sprite: CompositeSprite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 5.3 Java Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 5.4 Finishing EasyDice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 i ii CONTENTS 6 Rules: Methods, Parameters, and Design 159 6.1 A Simple Arcade Game: SoloPong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 6.2 Top-down Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 6.3 Delegation: Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 6.4 Expressions Redux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 6.5 Finishing Up SoloPong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 6.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 7 Components Meet Rules: Classes 187 7.1 Playing Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 7.2 Network Programming with FANG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 7.3 Abstraction: Defining New Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 7.4 Finishing the Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 7.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 8 Collections: ArrayLists and Iteration 207 8.1 Flu Pandemic Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 8.2 Console I/O: The System Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 8.3 Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 8.4 Collections: One and Many . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 8.5 ArrayList is an Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 8.6 Finishing the Flu Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 8.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 9 Multidimensional Data Structures 241 9.1 Rescue Mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 9.2 Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 9.3 Multidimensional Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 9.4 Animation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . 256 9.5 Finishing Rescue Mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 9.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 10 Scanner and String: Character Input 269 10.1 Designing Hangman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 10.2 Starting Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 10.3 Different Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 10.4 String Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 10.5 Reading Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 10.6 Finishing Hangman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 10.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 11 Console I/O: Games without FANG 303 11.1 Another Dice Game: Pig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 11.2 Pure Console I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 11.3 Sorting a Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 11.4 Finishing Pig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 11.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 12 More Streams: Separating Programs and Data 327 12.1 Outsmarting the Player: 20 Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 12.2 Reading and Writing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 iii 12.3 Data-Driven Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 12.4 Encoding Objects to Read or Write Them . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 12.5 Finishing the Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 12.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 13 Lists of Lists and Collision Detection 353 13.1 Designing BlockDrop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 13.2 Software Engineering: Managing Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 13.3 When It s Safe to Move: Collision Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 13.4 Finishing BlockDrop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 13.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 14 String Processing: Interactive Fiction 381 14.1 Back to the Future: Interactive Fiction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 14.2 Escape from T-Hall . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . 386 14.3 Reading The Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 14.4 Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 14.5 Incremental Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 14.6 Finding a Match . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 14.7 Making it a Real Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 14.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 A Java Language Keywords 427 B References 429 C Java Templates 433 D FANG Color Names 435 Index 437 iv CONTENTS Dr. John B. Smith at UNC Chapel Hill for helping me realize that the random idea s I had about introductory programming texts were aspects of an event-driven introduction to programming. A lso for being my academic and thesis advisor. Lynn Andrea Stein s Rethinking CS101 project for starting a discussion (in my head ) about what expectations in introductory programming books should be. Kim B. Bruce and the Java: An eventful approach gang at Williams College for rev iving my interest in an event-driven introduction to computer programming. Game names, game company names, and video game program names are the property of their respective trademark or copyright holders. Preface Motivation Mining the Past for the Future How to Read Syntax Templates Computer languages are artificial languages designed to eliminate as much ambigu ity as possible. Because they are designed to be processed by computers, the structure of the language ca n be formally expressed. The Extended Backus-Naur Form (EBNF) is a mathematically formal way of expressin g the syntax (structure) of a programming language. The notation was developed by John Backus and enhance d by Peter Naur more than forty years ago. We will use an EBNF notation to describe templates for various language construc ts. The notation will use <somename> to indicated named non-terminal symbols, that is, symbols which stand for other templates defined somewhere else. Symbols outside of the angle brackets, except for those special characters defined here, stand for themselves. The special symbols are: := Defined as: the symbol to the left of this symbol is defined by the template on the right of the symbol. [...] Group the elements between into one expression for application of the various repeat and optional markers. Selection between the prior and following expressions. One or the other can appear.

? Optional: the item this follows can appear zero or one time. + Optional repeat: the item this follows can appear one or more times. * Repeat: the item this follows can appear zero or more times. So, as an example, a floating point number, a number with an optional decimal pa rt, could be written with the rules: <floatingPoint> := -? <digit>+ [. <digit>+]? <digit> := 0 1 2 3 4 5 6 7 8 9 This says that a floating point number has at least one digit to the left of the decimal point (thus .1 is not valid according to this template) and if there is a decimal point, there must be at least one digit to the right of the decimal point. The decimal point (and any following digits) are optional. The negative sign is optional and, by this definition, a leading plus sign is not valid. The point of using these templates is that they are unambiguous and show exactly what is valid when declaring some particular Java language structure. One note is that we will use simplified templates early in the book, templates w hich do not include all of the complexities permitted in a given structure. As we make use of the complex f eatures we will repeat the template with the more complex parts. Thus the last template presented in the bo ok is the most complete. To aid in studying, the templates presented in each chapter are repeated at the end of the chapter in the summary and the most complete templates are all collected in Appendix C. v C h a p t e r 1 Getting Started: What s in a Game? While some computer scientists are sometimes loathe to hear it, creating a compu ter program is as much art as it is science. Converting an idea for a computer program into a programmable description of that idea is a design task; in fact, that phase of development is called the design phase by developers. Designers of all types have rules that they apply yet there remains an aesthetic dimension which cannot be learned from a book; it is learned only through practice. This is actually a very wonderful thing: computer programming, from scratch to r unning code, involves both creative and analytic capabilities. It uses all the parts of the programmer s brain that can be brought to bear. Learning the aesthetic component of a design skill requires practice and evaluat ion of the results. One of the most important parts of the practice is to play with the elements, trying di fferent combinations and trying for different effects. This book uses computer games as a programming area to te ach general computer programming. The preface discusses the approach in detail, but there are two primary reasons for this: computer games encompass all the hard problems in computer science and making computer ga mes will trick you into playing with the computer programs. Playing the computer games in this book will motivate you to improve them; some improvements are suggested in the text or exercises but you are sure to come up with other, bette

r, changes on your own. To tweak what happens in the computer game you will have to tweak what happens in t he computer program. This chapter begins with an overview of how this book is designed. It then exami nes the parallels between a game and a computer program, starting by looking for a usable definition of a game. The following chapters begin giving you the tools to build your own game using the Freely Available Net worked Game Engine (FANG) and the Java programming language. 1.1 Learning From Simple Computer Games This book is about computer programming. Specifically, it is an introduction to computer programming for students with little or no experience with computer programming. It is important to keep that in mind as you read the book because there is a lot of talk about games. It might seem, superfi cially, that the book is about games; this section will explain how that is not the case. 1 2 CHAPTER 1. GETTING STARTED: WHAT S IN A GAME? Structure The book begins with a definition of what a game is; that is what the next secti on of this chapter is all about. It then ties that definition to a definition of a computer program. Just before the chapter ends, you are given the source code for a game, Meteors, an Asteroids clone. You are given the game and a brief explanation so that you can modify the code. The point of this book is that you only learn design sk ills and programming skills by practicing them. The program given in this chapter is also an example of the spiral approach take n by the text. You will be shown new features of the programming language, the game engine, computer scienc e, as soon as you could possibly use them. In later sections and chapters, the same topics will be revis ited so that you learn why they work the way they do and, more importantly, how to design and build them yoursel f. So, in this chapter you see a Java program and receive a recipe for compiling an d running the program. The terms compile and run are both given about a sentence of definition and the stru cture of the program is presented in two or three paragraphs. It is obvious that for someone without computer programming experience, they will not understand what is going on. They will, hopefully, be able to compile and run the program, however. And then, with some guidance in the end-of-section questions, modify it. At this point, if anything goes wrong, students will not know enough to fix it. Chapter 2 again presents the overall structure of a Java program, this time with three to five times as much explanation. Now some of the magic incantations which you used in making the progr am run will be clearer. The book uses a game engine/learning library called FANG (the Freely Available N etwork Game engine). FANG provides a lot of support for beginning students for writing games. It is, initially, another collection of magic incantations, protecting the student from the sharp corners inside of J ava. As you gain familiarity with Java concepts while using FANG, some of the pieces of FANG will be peeled b

ack. Three of the last four chapters of the book involve writing game programs that do not use FANG at all. The first two chapters are atypical: they present new concepts in a very broad c ontext. This is because you need to learn a little bit about how computers work in order to understand t he commands you type in to the machine. The remaining chapters begin by setting a much more limited context: they begin by describing a particular game. The game in each chapter requires some new aspect of programming. You begi n using objects defined in FANG controlled by rules defined in FANG. One game requires defining your own rules for FANG objects. Another has a large number of similar objects, motivating the developme nt of object containers. In each case, the game design discussion at the beginning of the chapter leads to a program design discussion and a realization of what we have not yet learned to do. This gives you a place to hang the new programming concepts and Java techniques. This book is about the programming concepts first, about Java programming skills second, and finally about simple computer games. The simple is there so that you can focus on the underlyi ng structure, the introductory computer science, that makes the games possible. The computer games are there to give you feedback as you learn the computer science concepts. 1.2 What s In a Game? Consider for a moment the seemingly simple question: What is a game? Do you know what a game is? Everyone I have ever asked that question answers, Yes, yet almost everyone balks when I fol low up with the obvious, Well, what is it? Before we can compare games and programs, we need working defini tions of both. Definitions Before proceeding, we should examine that last statement above: Do we need a def inition of a game? In The Art of Game Design [Sch08], Jesse Schell spends almost two pages talking about a cademics, game researchers, demanding detailed game definitions, definitions which do not interest practicin g game designers. 1.2. WHAT S IN A GAME? 3 The rant stung as the authors are both academics who study and teach with games. As Schell worked through the next dozen pages, he found some merit in the struggle to define game s: a definition provides a mental framework for holding the pieces we learn about game design and programmi ng. Having a working definition of a game also makes it easier to exploit parallels between game and program design and implementation; it lets us analogize from one field to the other. Dictionary Definitions When getting started with a definition, the dictionary is often a rewarding plac e to start. The Oxford English Dictionary provides an interesting starting place with 4. a. a diversion of the nature of a contest, played according to rules, and displaying in the result the superi ority either in skill, strength, or good fortune of the winner or winners. [OED71] Alternatively, 8. c. the apparatu s for playing particular

games. [OED89] Each of these definitions provide useful pieces: a game has rules a nd is played with apparatus of some sort. If you think about a simple computer game, the game has virtual ap paratus of some kind and some sort of rules. Other dictionaries have the same general definition though the American Heritage Dictionary is one nonspecialized dictionary providing a mathematical definition: A model of a competitive situatio n that identifies interested parties and stipulates rules governing all aspects of the competition , used in game theory to determine the optimal course of action for an interested party [AHD00]. Again we see rules but these rules apply to the party playing the game rather than to the apparatus in the game. Th is definition might be useful when developing strategies, ways of playing games, particularly when constructin g computer opponents. The current popularity of game design in general and the study of video games in particular means that there is a considerable specialized literature on games and play. Perhaps their definitions are better suited to our need. Literature Definitions Salen and Zimmerman, in Rule of Play, relate play and game by noting that not al l languages have two different words for the two concepts. Further, they note that, Games are a subset of play, a nd Play is a component of games. [SZ04] Of all the play we do, only some of it is games (the first state ment) yet when we use a game, we play it (the second statement). This permits us to look at definitions of pla y as well as games. Johan Huizinga, a Dutch anthropologist, published his Homo Ludens ( Man the Game P layer ) in 1938, offering one of the first and broadest academic definitions of play: [Play is] a free activity standing quite consciously outside ordinary life as bein g not serious, but at the same time absorbing the player intensely and utterly. It is an activi ty connected with no material interest, and no profit can be gained by it. It proceeds within its own proper boundaries of time and space according to fixed rules and in an orderly manner. It promotes the formation of social groupings, which tend to surround themselves with secrecy and to stress t heir difference from the common world by disguise or other means. [Hui55] What does this have that our dictionary definitions lack? It talks about play as being outside of ordinary life, bounded in time and space; he goes on to talk about the magic circle which p eople enter when they begin a game, the magic circle containing the rules which apply while the player s are in it. The magic is further reflected in the total absorption of players while the game lacks seriousness or real world consequences. David Parlett, a game historian, offers a definition of formal games in the The Oxford History of Board Games: A formal game has a twofold structure based on ends and means: Ends. It is a contest to achieve an objective. (The Greek for game is agn, meanin g contest.) Only one of the contenders, be they individuals or teams, can achieve it, since achie ving it ends the

4 CHAPTER 1. GETTING STARTED: WHAT S IN A GAME? game. To achieve that object is to win. Hence a formal game, by definition, has a winner; and winning is the end of the game in both senses of the word, as termination and as o bject. Means. It has an agreed set of equipment and of procedural rules by which the equi pment is manipulated to produce a winning situation. [Par99] This definition captures the idea of challenge or competition in a game as well as explicitly mentioning both the game rules and the game equipment. There are literally dozens of attempts to define game and play in the emerging g ame studies literature as well as in game design guides, books that are less academic but more focused on helping budding game designers learn the skill of game design. Jesse Schell, in The Art of Game Design examines a number of definitions before settling on our final and shortest definition of play and games: Play is manipulation that satisfies curiosity.... A game is a problem-solving ac tivity, approached with a playful attitude. [Sch08] This is of particular resonance for a computer programmer because computer scien ce is, fundamentally, problem solving. All a computer program is is a formal description of how to sol ve a problem. This definition does not go into detail about the rules and equipment but that is what the rest of Schell s book is about. Game Studies Game studies is a fairly young field of academic study having grown up in parall el with the rise of the video game industry. Prior to the 1980s, only a handful of historians and anthro pologists studied games and play and their definition. Johan Huizinga, in his 1938 Homo Ludens (quoted i n the chapter), offered a book length examination of games across cultures and across history. Several different approaches to the study of games have emerged. Anthropologists remain interested in the meaning of games to the people who play them. Sociologists and economists study how people interact with games as systems. New media scholars study games as artistic constructs, ex amining how they communicate their different messages. Computer scientists, game designers, and other technologists focus on how games are made and the industry that makes them. In the following d escriptions of specific research, notice how interconnected the different approaches are. Study of the meaning and impact of games on players includes looking at games as learning tools, games as simulations, and how games change their players. The military has been interested in games in the first two senses here since before World War II with the use of flight simul ators. As early as the 1940s analog computers were used to calculate the outcomes of the settings of flight c ontrols. Learning with games has begun moving into the mainstream with Gee s What Videogame s Have to Teach Us About Learning and Literacy[Gee03] being a recent attempt to look at what pla yers learn from the games they play and how that experience can be used to reach modern students. The nega

tive impact of games is also a focus of this approach. Grand Theft Childhood: The Surprising Truth Ab out Violent Video Games[KO08] by Kutner and Olson is a popular press book surveying this research. This resear ch impacted the games presented in this book in that there is a conscious effort to limit the amount o f violence in any of the game designs. This is a personal, designer-specific decision, but the book attem pts to create games with playable mechanics without a violent veneer. Sociologists look at the social constructs surrounding games. Some study massive ly-multiplayer online games (MMOs) and the societies that arise within them. Others look at the mod com munities , the groups that form around different games to modify and extend them. Mia Consalvo s Cheating: Gaining Advantage in Videogames[Con07] looks at players who subvert the social contract in multiplayer games. Another interesting approach to examining MMOs is taken by economist Edward Cast ranova in Synthetic 1.2. WHAT S IN A GAME? 5 Game Studies (contd.) Worlds: The Business and Culture of Online Games[Cas05] which looks at on-line g ames internal economies as models of the real world. Media studies looks at the message being sent by the game designer. This is clos ely related to what/how games teach their players. Many in this field, like Ian Bogost (Persuas ive Games[Bog07]) look at the accidental messages contained in some early and commercial video games and loo k for ways to use the same methods to actively communicate a message. The book in your hands is a result of the computer science approach to game stud ies: looking at how games are made exposed the deep computer science problems in video games and tha t was then brought back to the introductory classroom. Others, including Rudy Rucker in Software En gineering and Computer Games have had similar insights. This approach also includes the massive number of game design books. Chris Crawf ord s The Art Of Computer Game Design: Reflections Of A Master Game Designer[Cra84] is a seminal work in this field. Salen and Zimmerman s Rules of Play: Game Design Fundamentals[SZ04] is a more recent, incred ibly comprehensive take on game, and in particular, video game design. A recent, readable overview of the state of video game studies as a whole is Jam es Newman s Videogames[New04]. The fledgling field of game studies has only recently begun h aving its own academic journals and conferences; the continuing popularity of video games indicates tha t the field will continue to grow apace. A Working Definition Looking at these sample definitions, we can extract our own more general and mor e detailed definition: A game is a collection of components that interact according to a set of rules p resenting the player with a meaningful choices to make in determining the outcome of a struggle with the environment

or another player.1 The meaningful choices is an attempt to capture the problem solving in Schell s defi nition; these are also where the absorption of Huizinga s definition emerges. The outcome of the game reflects the contest elements in Parlett s definition and implies we will want to have ways of keeping score. This definition gives us names for the parts of a game, a way to talk about how a game is built. It also gives us names for the parts of a computer game. The remainder of this section explores components and rules as they appear in ga mes. Following sections explore how they apply to computer programs and computer games. This chapter talks about computer programs but it does not include any; do not u se that as an excuse to skip it. It is not that long and the insight you gain from this parallel present ation will help you explore the computer programs presented in all of the following chapters. Things: Components Components are the things used to play a game. A traditional game of checkers, f or example, has sixty-four squares in two colors arranged in an 8 # 8 alternating square, a checkerboard, a nd twenty-four checkers, also in two colors. There are two flavors of components: passive components (like those in checkers) and active components which move on their own (due to physics) or add something new to an ongoing game . 1This definition fails to address the entertaining and amusing portions of the dicti onary definitions; these dimensions are subjective and difficult to quantify. This book uses games to teach software design and dev elopment; while some mention will be made of fun , the player experience is more properly the domain of game design. Interested students are referred to the references at the end of the book. 6 CHAPTER 1. GETTING STARTED: WHAT S IN A GAME? Figure 1.1: Components of Checkers Passive Components Passive components are place holders, used to keep track of the game s progress. T he checkers and board illustrated above, the playing cards in bridge or poker, or the peg board in cri bbage are all examples of passive components. The players of the game manipulate the passive components according to the rules of the game. Active Components Active components are components which make decisions about how to contribute to t he game. The decision maker differs for different components: dice and marbles move according to the la ws of physics (interacting with the table, gravity, one another, and friction); collectible cards have thei r automatic actions enumerated on them or listed in the rules for the game. Cubic dice, when rolled, bounce and rub on the surface to provide the players wi th a random number, something which was not there before. Other games active components include the m arbles in Milton Bradley s Hungry Hungry Hippos or the creature cards in the various collectible card games (Wizards of the Coast s Magic: The Gathering or Nintendo s Pokmon ). Actions: Rules