This November 16-18, I'll be attending the inaugural Pittsburgh Game Jam. If any readers of this blog happen to be in the area, drop by and say hi!
This is exciting on multiple levels for me. For one, I haven't been back to my alma mater since I graduated (the ETC didn't even exist last time I was on campus, and I hear we eventually got a new Student Union too). Also, for all the talk of how great Game Jam events are, and even though I've coordinated one of them, I've never actually been a participant... and I'm looking forward to seeing what I'm capable of under extreme duress. Lastly, this particular Game Jam requires making games for young children -- a demographic I haven't had much experience with to date, so it will be nice to gain some additional understanding of the design constraints for this market.
Strangely, I'm signed up as a Programmer, not as a Game Designer. An event coordinator told me that they have a shortage of Programmers, which surprised me -- back when I was an undergrad, even the English and Humanities majors knew some programming (not typical of most college campuses, but CMU is a haven for computer geeks of all stripes). This is a school where they gave out free floppy disks to boost attendance at football games. And there's a programmer shortage? Well, it gives me an excuse to learn Python, which I've been putting off for a couple of years now, so I can't complain about the hand I'm dealt.
Monday, October 29, 2007
Wednesday, October 24, 2007
Textbook Review: Break into the Game Industry
This is part of the series on book reviews.
"Break into the Game Industry: How to get a job making video games" (Ernest Adams)
I almost didn't want to review this book. After all, it's obviously a vocationally-oriented book that has no place in the classroom as a text, right? While there is certainly a strong focus on the "breaking in" aspect, it turns out this book has a surprising amount of overlap with my Game Industry Survey course topics, suggesting that it may have more use than the title suggests.
This book starts with a reasonable (if brief) look at the history of the industry and then goes right into the bits of how the industry is structured today: platforms, game genres, business models, job roles and responsibilities within a developer. This is important stuff for any aspiring developer to know, and it takes up about half of the book.
About a third of the book is devoted to what the title implies: what kind of education and experience to give yourself, and the actual process of applying for a job. This strikes me as the kind of thing that students should read on their own, rather than something that's part of any course material.
Lastly, the book ends with a short section on the minimum everyone should know about legal issues (IP, NDAs, and how to read an employment contract) and a final wild guess on the probable future direction of the industry.
It should be noted that this book was published in 2003. This has the obvious implications: some of the information is woefully out of date. Notably, this was written before the downsizing of E3 and before the ea_spouse letter. Some of the companies mentioned are no longer making games. That said, a surprising amount of the practical information in this book is still valid, although it is definitely living on borrowed time -- I'm not sure how many more years it will be useful before the obsolete material outweighs the usefulness of the rest.
Students: If you are interested in getting into the game industry or you'd just like to know a bit more about what it's like behind-the-scenes, this is a great book to read. I can't say that it's fun to read exactly, but the information contained within is obviously practical and useful which might give you the incentive to keep reading anyway. At least for now, most of the obsolete material involves things that can easily be checked online, so for any specific piece of information you'd do well to confirm it by firing up your browser.
Instructors: It doesn't have any end-of-chapter exercises so you'll have to make your own, and you'll have to supplement it with modern history (the current generation of consoles, the effect of World of Warcraft, etc.), and it has a title that will make other academics glare at you if you use it as a required text in a class. But it still has a lot of useful information about the industry, so if you teach a class about the game industry you might at least consider making it an optional text in your syllabus. And if you have no industry experience, you could do with reading it yourself to supplement your existing course materials.
Professionals: If you already have a job in the game industry, then you probably know most of this stuff already, so it's not really worth your time to read the whole thing. That said, if there are aspects of game development that you don't know much about, this is as good a primer as any to show you what the heck it is that those people in that other department are doing all day; I learned tons about art and game audio, which were always something of a mystery to me.
Tuesday, October 23, 2007
Emergent Design: Freedom is constant?
Had an interesting discussion awhile ago with a student where we came up with a theory that has probably been discussed elsewhere, though I'm not immediately aware if it has (the subject came up recently in another class I'm taking, and it reminded me of this):
The sum total of the freedom of a game designer to create the world, plus the freedom of the player to alter that world, is a constant.
An RPG like Final Fantasy that has more or less a linear, established plot gives the player relatively few choices in terms of affecting the game world; the player may have different strategies for beating monsters over the head with sticks as efficiently as possible, but at the end of the day they're going to save the world, rescue the princess and kill the evil wizard all the same.
Compare to Fallout or the Elder Scrolls games where the player has more control over the game world, but now the game designer is constrained: it's easier to create a world, but harder to tell a compelling story within that world.
I think this is, by and large, the difference between Eastern and Western RPGs.
The sum total of the freedom of a game designer to create the world, plus the freedom of the player to alter that world, is a constant.
An RPG like Final Fantasy that has more or less a linear, established plot gives the player relatively few choices in terms of affecting the game world; the player may have different strategies for beating monsters over the head with sticks as efficiently as possible, but at the end of the day they're going to save the world, rescue the princess and kill the evil wizard all the same.
Compare to Fallout or the Elder Scrolls games where the player has more control over the game world, but now the game designer is constrained: it's easier to create a world, but harder to tell a compelling story within that world.
I think this is, by and large, the difference between Eastern and Western RPGs.
Saturday, October 20, 2007
Textbook Review: Chris Crawford on Game Design
This is part of the series on book reviews.
"Chris Crawford on Game Design" (Chris Crawford)
Chris Crawford is an interesting character of the industry. He's been in the industry since its very beginnings. He is so animated as a public speaker that it is physically impossible to be bored while listening. He is outspoken, highly opinionated and quite curmudgeonly. He can be egotistical at times; some would say he's earned the right. The industry owes him a debt of gratitude for starting the first incarnation of GDC in his living room. (Personally, I considered this debt paid in full when, at GDC 2006, he told a room full of game developers that games were dead as an artistic medium. Which left me to wonder what he was doing in the Game Developers Conference if he no longer wishes to be a game developer. But I digress.)
It is important to understand at least a little bit of the man when reading this book, because the author projects a lot of his personality into it. This is not a stuffy, academic textbook by any means; this is 100% pure Chris Crawford opinionated ranting. In short, the book is exactly what the title says -- no more, no less. This makes it worthy of study, but also of limited use.
So, what is in this book? Roughly the first half talks about general game design concepts: the nature of play, challenge, interactivity and so on. The second half includes a chapter on every game that Crawford ever designed, and the lessons he feels he learned as a designer. Somewhere in the middle there's a chapter devoted to recommended books to read, and another on games to play, for the aspiring designer -- which both include an overly-biased dose of Crawford's own work. The book ends with a wonderfully entertaining (if not necessarily educational) chapter called "Old Fart Stories".
Anyone who reads this book needs to keep a box of salt at the ready, to take one grain at a time with each sentence. Some of Crawford's assertions are bathed in wisdom. Some are a bit off the mark. Some appear to be the ravings of a madman. It is not immediately clear which are which; readers must make up their own minds. As such, it helps to have a solid academic foundation (if not outright experience) in the field before reading this book; you'll need it to make your own informed opinion.
All that said, it's an easy read, so it's probably worth the weekend that it takes to skim through it. Different people will get different things out of it, but it's worth at least taking a look at so you can decide for yourself what nuggets of brilliance (if any) are embedded in the book. Unless you have absolutely no respect for Chris Crawford, in which case you're not going to buy this book anyway. (I've met developers who worship Crawford, others who despise him, and a few who are in between. Hmm. Maybe you should try meeting him in person before deciding whether to read his book?)
Students: Do not read this until you've already done a lot of other study and practice; otherwise you're likely to just get confused when the things that he says start contradicting what you'll learn in later classes. When you think you're ready, go ahead and read it, being prepared to have your own debates with him in your head.
Instructors: Since this is not a comprehensive text (nor even a particularly focused one), I can't see it being used as the basis for an entire course. As part of a higher-level theory course where students are expected to compare and contrast various designers and their rhetoric, this could be one of several books... although depending on the length of the course, again, it may not be practical to have students read more than an occasional excerpt (and forcing them to purchase five or ten books just to read one chapter from each is just cruel).
Professionals: If you work in the industry you probably know the author, by reputation if nothing else. If you've seen him speak at GDC, imagine all of that dropped into a book and you know what you're in for. You'll probably read about some obscure games that you've never even heard of (mostly Crawford's own) which I suppose has value in itself, and debating the finer points of this book with other designers could be an interesting exercise if you can convince them to read it at the same time. But due to the large amounts of questionable material in this book, I'd leave it until after you've covered the more important works.
"Chris Crawford on Game Design" (Chris Crawford)
Chris Crawford is an interesting character of the industry. He's been in the industry since its very beginnings. He is so animated as a public speaker that it is physically impossible to be bored while listening. He is outspoken, highly opinionated and quite curmudgeonly. He can be egotistical at times; some would say he's earned the right. The industry owes him a debt of gratitude for starting the first incarnation of GDC in his living room. (Personally, I considered this debt paid in full when, at GDC 2006, he told a room full of game developers that games were dead as an artistic medium. Which left me to wonder what he was doing in the Game Developers Conference if he no longer wishes to be a game developer. But I digress.)
It is important to understand at least a little bit of the man when reading this book, because the author projects a lot of his personality into it. This is not a stuffy, academic textbook by any means; this is 100% pure Chris Crawford opinionated ranting. In short, the book is exactly what the title says -- no more, no less. This makes it worthy of study, but also of limited use.
So, what is in this book? Roughly the first half talks about general game design concepts: the nature of play, challenge, interactivity and so on. The second half includes a chapter on every game that Crawford ever designed, and the lessons he feels he learned as a designer. Somewhere in the middle there's a chapter devoted to recommended books to read, and another on games to play, for the aspiring designer -- which both include an overly-biased dose of Crawford's own work. The book ends with a wonderfully entertaining (if not necessarily educational) chapter called "Old Fart Stories".
Anyone who reads this book needs to keep a box of salt at the ready, to take one grain at a time with each sentence. Some of Crawford's assertions are bathed in wisdom. Some are a bit off the mark. Some appear to be the ravings of a madman. It is not immediately clear which are which; readers must make up their own minds. As such, it helps to have a solid academic foundation (if not outright experience) in the field before reading this book; you'll need it to make your own informed opinion.
All that said, it's an easy read, so it's probably worth the weekend that it takes to skim through it. Different people will get different things out of it, but it's worth at least taking a look at so you can decide for yourself what nuggets of brilliance (if any) are embedded in the book. Unless you have absolutely no respect for Chris Crawford, in which case you're not going to buy this book anyway. (I've met developers who worship Crawford, others who despise him, and a few who are in between. Hmm. Maybe you should try meeting him in person before deciding whether to read his book?)
Students: Do not read this until you've already done a lot of other study and practice; otherwise you're likely to just get confused when the things that he says start contradicting what you'll learn in later classes. When you think you're ready, go ahead and read it, being prepared to have your own debates with him in your head.
Instructors: Since this is not a comprehensive text (nor even a particularly focused one), I can't see it being used as the basis for an entire course. As part of a higher-level theory course where students are expected to compare and contrast various designers and their rhetoric, this could be one of several books... although depending on the length of the course, again, it may not be practical to have students read more than an occasional excerpt (and forcing them to purchase five or ten books just to read one chapter from each is just cruel).
Professionals: If you work in the industry you probably know the author, by reputation if nothing else. If you've seen him speak at GDC, imagine all of that dropped into a book and you know what you're in for. You'll probably read about some obscure games that you've never even heard of (mostly Crawford's own) which I suppose has value in itself, and debating the finer points of this book with other designers could be an interesting exercise if you can convince them to read it at the same time. But due to the large amounts of questionable material in this book, I'd leave it until after you've covered the more important works.
Tuesday, October 16, 2007
Evaluating textbooks is easier than game engines
It just occurred to me why I've had no problem reviewing dozens of texts for my classes but I haven't gotten around to evaluating even a single game engine for classroom use (even though I have about five on my to-do list).
Evaluating a textbook is easy. I'm already familiar with most of the content I'd be looking for, so I can skim chapters. I'll typically read a few key areas closely (those that I plan to emphasize the most in class), which gives me a good idea of the author's general approach. I can usually get through a textbook this way in an afternoon or two. If I'm assigning readings in a course, I can read the passage myself the night before we talk about it in class, so the details can be spaced out.
A game engine, by contrast, demands that I learn something that I'm unfamiliar with (the particular capabilities and syntax for that engine) and then create a couple sample projects with it in order to get a feel for how easy it is to develop with. It takes me an afternoon or two just to read the documentation, and then another couple weeks or so to get used to developing games with this particular tool. And if I'm going to demand (or even suggest) the use of a game engine in a course, I should be proficient from the beginning since students will likely have some advanced questions as soon as they start. So, the time commitment is much larger and also must be given up front -- two things that are the bane of a full-time teacher.
I haven't yet found a way around this. I'm not sure there is a way around it; I (and the other teachers I've talked to) use the tools in class that we're familiar with.
Evaluating a textbook is easy. I'm already familiar with most of the content I'd be looking for, so I can skim chapters. I'll typically read a few key areas closely (those that I plan to emphasize the most in class), which gives me a good idea of the author's general approach. I can usually get through a textbook this way in an afternoon or two. If I'm assigning readings in a course, I can read the passage myself the night before we talk about it in class, so the details can be spaced out.
A game engine, by contrast, demands that I learn something that I'm unfamiliar with (the particular capabilities and syntax for that engine) and then create a couple sample projects with it in order to get a feel for how easy it is to develop with. It takes me an afternoon or two just to read the documentation, and then another couple weeks or so to get used to developing games with this particular tool. And if I'm going to demand (or even suggest) the use of a game engine in a course, I should be proficient from the beginning since students will likely have some advanced questions as soon as they start. So, the time commitment is much larger and also must be given up front -- two things that are the bane of a full-time teacher.
I haven't yet found a way around this. I'm not sure there is a way around it; I (and the other teachers I've talked to) use the tools in class that we're familiar with.
Thursday, October 11, 2007
Textbook Review: Introduction to the Game Industry
This is part of the series on book reviews.
"Introduction to the Game Industry" (Michael Moore)
(No, this wasn't written by that Michael Moore. I think he's generally too busy making movies to do much game development. Not that there's anything wrong with a documentary filmmaker creating a video game.)
Now, with that out of the way...
From the title of this book, I would have assumed it would be looking at the past, present and future of the game industry (without getting into the gory details of actual game development). But it turns out this book is more like a "lite" version of Rabin's "Intro" tome... with a stronger focus on game design, production and business. There is some history of gaming, but it is more of a sidebar to the rest of the book.
The timing on this book's publication was unfortunate. It was finished in late 2006 and published in early 2007, at a transition point in the industry (with the upcoming release of the Wii and PS3 and downsizing of E3, among other things). This means that any modern examples in the book already appear dated, and the poor book hasn't even been out for a year yet.
Maybe I'm a stickler for details, but I was disappointed at the editing of the book. There were a number of embarrassing mistakes; in the first few chapters I saw a comment on the steady decline of the physical boardgame industry in the 1990's, without any mention of the Eurogame resurgence; "A game is a series of interesting decisions" was attributed to Sid Meiers; and the heroine of Tomb Raider is apparently named Laura Croft. These may be little things, but they're exactly the things that end a conversation between a student and some professionals. I could understand sloppiness from an author with no experience who just wanted to cash in on the whole games-in-education trend; I would expect better from an industry veteran who teaches at DigiPen.
Perhaps more dangerous is that in 2007, this textbook largely teaches that games are created through the Waterfall model. It does acknowledge rapid prototyping very briefly, but makes no mention of Agile development that was all the rage as of the time of printing (and still is, to my knowledge).
On the bright side, there are a variety of exercises at the end of each chapter that range from basic multiple-choice regurgitation of the chapter content to some nice design exercises and thought-provoking questions. Also, this book introduces a fairly complete set of industry jargon, which is important to a student who wants to hold a conversation with a professional; however, the terminology is scattered throughout the book and has no unifying quick-reference table or glossary as a reminder.
Students: If you're looking for a basic, high-level overview of game design or production with a little understanding of what those strange artists and programmers are doing (without having to actually learn art or programming), this book will give you a reasonable starting place. As you read, make sure to not take anything as gospel; this book has equal parts good and questionable advice. I'd recommend reading this only as a supplement to other texts, either to fill in some blanks or as a second opinion.
Instructors: Use of this book in the classroom has similar problems to Rabin's book: by covering all disciplines of game development it can't really fit in any of them. Added to the other problems above, I can't see this being useful as a textbook for any course. However, I would definitely recommend picking up an evaluation copy for yourself and taking a look at the end-of-chapter exercises for the chapters that apply to your classes; you may find a few good questions and activities for class discussions, exams and homeworks.
Professionals: As this book explains the game industry to the uninitiated, you are really not the target audience. If you're a programmer or artist who wants to know more about production or game design you might give those sections a read, but you're probably better off finding other books that go more in depth into those respective fields.
"Introduction to the Game Industry" (Michael Moore)
(No, this wasn't written by that Michael Moore. I think he's generally too busy making movies to do much game development. Not that there's anything wrong with a documentary filmmaker creating a video game.)
Now, with that out of the way...
From the title of this book, I would have assumed it would be looking at the past, present and future of the game industry (without getting into the gory details of actual game development). But it turns out this book is more like a "lite" version of Rabin's "Intro" tome... with a stronger focus on game design, production and business. There is some history of gaming, but it is more of a sidebar to the rest of the book.
The timing on this book's publication was unfortunate. It was finished in late 2006 and published in early 2007, at a transition point in the industry (with the upcoming release of the Wii and PS3 and downsizing of E3, among other things). This means that any modern examples in the book already appear dated, and the poor book hasn't even been out for a year yet.
Maybe I'm a stickler for details, but I was disappointed at the editing of the book. There were a number of embarrassing mistakes; in the first few chapters I saw a comment on the steady decline of the physical boardgame industry in the 1990's, without any mention of the Eurogame resurgence; "A game is a series of interesting decisions" was attributed to Sid Meiers; and the heroine of Tomb Raider is apparently named Laura Croft. These may be little things, but they're exactly the things that end a conversation between a student and some professionals. I could understand sloppiness from an author with no experience who just wanted to cash in on the whole games-in-education trend; I would expect better from an industry veteran who teaches at DigiPen.
Perhaps more dangerous is that in 2007, this textbook largely teaches that games are created through the Waterfall model. It does acknowledge rapid prototyping very briefly, but makes no mention of Agile development that was all the rage as of the time of printing (and still is, to my knowledge).
On the bright side, there are a variety of exercises at the end of each chapter that range from basic multiple-choice regurgitation of the chapter content to some nice design exercises and thought-provoking questions. Also, this book introduces a fairly complete set of industry jargon, which is important to a student who wants to hold a conversation with a professional; however, the terminology is scattered throughout the book and has no unifying quick-reference table or glossary as a reminder.
Students: If you're looking for a basic, high-level overview of game design or production with a little understanding of what those strange artists and programmers are doing (without having to actually learn art or programming), this book will give you a reasonable starting place. As you read, make sure to not take anything as gospel; this book has equal parts good and questionable advice. I'd recommend reading this only as a supplement to other texts, either to fill in some blanks or as a second opinion.
Instructors: Use of this book in the classroom has similar problems to Rabin's book: by covering all disciplines of game development it can't really fit in any of them. Added to the other problems above, I can't see this being useful as a textbook for any course. However, I would definitely recommend picking up an evaluation copy for yourself and taking a look at the end-of-chapter exercises for the chapters that apply to your classes; you may find a few good questions and activities for class discussions, exams and homeworks.
Professionals: As this book explains the game industry to the uninitiated, you are really not the target audience. If you're a programmer or artist who wants to know more about production or game design you might give those sections a read, but you're probably better off finding other books that go more in depth into those respective fields.
Thursday, October 04, 2007
Textbook Review: High Score!
This is part of the series on book reviews.
"High Score! the illustrated history of electronic games (2nd Edition)" (Rusel Demaria & Johnny Wilson)
I've used this book in my Game Industry Survey class, but it's not a textbook. It even says on the cover that it's a coffee table book for game geeks, and that's exactly what it is: a trip down the memory lane of the game industry, in full color, featuring much box art, screenshots and developer photos. The authors give a very candid look at the industry, talking not just about the games but also the developers: what it was like to work at Atari in the early days, for example. The writing style is conversational, not academic, making it an easy read (not to mention that the subject material will be interesting to most student game developers).
This book has two glaring weaknesses, and neither is the fault of the authors. The first is that it was published in 2004; the current generation of consoles did not exist yet, nor did World of Warcraft, so there is a period where the information just stops. Second, the book is unfortunately out of print, which makes it impossible to use as a required text. (Luckily, it can still be found used on Amazon and the like, as of the time of this posting.)
Students: If you're a game geek, you'll probably enjoy reading this book anyway. The fact that you'll actually get a great sense of the history of the industry (which will help you appear serious when you start applying for jobs) is purely accidental.
Instructors: If you teach a course about the history of the game industry, this is a great supplement. Being out of print means it's not required, but you might at least pick up a copy for yourself to supplement your lecture material, and suggest that interested students find their own copy for out-of-class pleasure reading.
Professionals: This is more of a game geek book, so it won't exactly help you make better games. You might like to pick it up for fun, or not, depending on your personal taste in books.
"High Score! the illustrated history of electronic games (2nd Edition)" (Rusel Demaria & Johnny Wilson)
I've used this book in my Game Industry Survey class, but it's not a textbook. It even says on the cover that it's a coffee table book for game geeks, and that's exactly what it is: a trip down the memory lane of the game industry, in full color, featuring much box art, screenshots and developer photos. The authors give a very candid look at the industry, talking not just about the games but also the developers: what it was like to work at Atari in the early days, for example. The writing style is conversational, not academic, making it an easy read (not to mention that the subject material will be interesting to most student game developers).
This book has two glaring weaknesses, and neither is the fault of the authors. The first is that it was published in 2004; the current generation of consoles did not exist yet, nor did World of Warcraft, so there is a period where the information just stops. Second, the book is unfortunately out of print, which makes it impossible to use as a required text. (Luckily, it can still be found used on Amazon and the like, as of the time of this posting.)
Students: If you're a game geek, you'll probably enjoy reading this book anyway. The fact that you'll actually get a great sense of the history of the industry (which will help you appear serious when you start applying for jobs) is purely accidental.
Instructors: If you teach a course about the history of the game industry, this is a great supplement. Being out of print means it's not required, but you might at least pick up a copy for yourself to supplement your lecture material, and suggest that interested students find their own copy for out-of-class pleasure reading.
Professionals: This is more of a game geek book, so it won't exactly help you make better games. You might like to pick it up for fun, or not, depending on your personal taste in books.
Subscribe to:
Posts (Atom)