Textbook Review: Teaching Videogames

It's been awhile since I did one of these. I just got a new shipment in, but I chose this one first because it was short.

"Teaching Videogames" (Barney Oram & James Newman)

It may seem strange to call this a "textbook" since it's targeted at teachers and not students, but it's a book on teaching and games so of course I had to take a look. It's written by two people with no game industry credits that I could see, it's barely large enough at 88 pages to qualify as a book (at that size it's more like an oversized pamphlet), and they're charging $42.95 for it, so I wasn't in a particularly generous mood when I started reading.

To be clear, this is not a book on game development. It's a book on game studies. This wasn't clear to me from the title, although I suppose being part of the "Teaching Film and Media Studies" series of books (as shown on the cover) should have been a big hint.

What exactly is this book about? It appears to be a primer on games (in the context of media studies) for those unfortunate souls who teach media studies courses, somehow found themselves tasked with teaching a class on video game studies, and feel completely lost because they don't know the first thing about video games. For those people, this book offers an overview of games and the game industry: a brief history of the industry, important types of businesses (developers, publishers, retailers, etc.), ludology and narratology, women in games, and violence in games and its effect on society. It offers workable syllabi for a pair of six-week classes, one on the study of games and one on the study of play, and includes some worksheets that can be given as class assignments (printed in such a tiny font that I had to squint to read it, but thankfully including a link to a soft copy online).

I didn't see any blatant errors; the content is pretty solid for what it is. In fact, my lesson plans for my Game Industry Survey course already contain a lot of this information, so I may not be as hopeless at game studies as I used to think I was. And the book is a fast read, so if you know nothing about video games and need to get up to speed pronto, this is a pretty decent bet. It starts off with a bit of academic jargon in the first few pages, but quickly lapses into a more readable, conversational tone.

That said, the book has what I see as a major conceptual flaw, and it's something that has probably been bugging some of you since a couple of paragraphs ago: this is written to assist those who are teaching a game studies class, but don't know the first thing about it. So I have to ask... for those who don't know anything about a subject, why are they teaching it in the first place? This book doesn't qualify someone to teach a class in game studies, any more than reading the Cliffs Notes version of Hamlet would qualify me to teach a class on Shakespeare in the English department. A teacher who knows nothing about a subject should not teach a course in that subject. Period. Am I the only one who thinks this? Am I oversimplifying? At any rate, it seems to me that if someone needs this book, then really they don't need the book, they need to not teach the class. So I'm suddenly not seeing the point of this book existing in the first place.

For those who teach game studies and are fully qualified, most of the content in this book is a waste of time, because you know it already. You won't see anything new. About the only thing that might be of use is the worksheets and lesson plans, which amount to maybe a tenth of the total book, and you can probably find more and better content in the IGDA Edu Curriculum Knowledge Base. The best reason to buy this book, then, appears to be the picture of Lara Croft wearing glasses and looking all educated on the front cover.

Students: Ironically, I think the people who would get the most use out of this book are students who are contemplating a Game Studies or Media Studies major. The book is short, it's easy to read, you can skip over the academic parts, and it'll give you a head start for your Game Studies 101 class (and give you some idea of the kinds of things you'll be studying). Just be aware that neither this book nor any related course of study will actually help you to make games, it will only let you study them.

Instructors: As mentioned above, either you don't need this book (in which case, buying it is a problem), or you do need this book (which is itself a problem). I did think of one edge case where the book might be useful: if you're teaching a more general Media Studies class (comparing and contrasting various media and how to study them) and you want to include a week or two on games but you're unfamiliar with this medium, then this book would be suitable for you to build that content into an existing class.

Professionals: If you're a practicing professional who knows all about making games but you never actually got to take any game studies courses in college (because you were too busy learning game development), and you'd like to read the books out there like Rules of Play except they're too big and intimidating to fit into your busy schedule, this will give you the quick-and-dirty introduction you're looking for.

Culture Shock: Deans and Heads and Chairs, Oh My!

When I was a student, my only real faculty contact came from my professors. Sure, there were all these other people out there with titles like "dean" and "department chair" and "provost" but I never had any dealings with them, nor did I have any idea what they did. I had no concept of departmental politics or inter-departmental territorial disputes; I couldn't see beyond the exam next week.

Now, as a faculty, I see all this stuff (even though I sometimes wish I didn't... sort of like if you enjoy eating sausage and then see how it gets made). But it occurs to me that it's still off the radar of most students (and, indeed, most industry professionals who have some dealings with educators).

I'm not sure what, if anything, to do about it. Part of me feels like students should probably at least know who the dean of their department is and why that matters. Maybe the non-teaching faculty should do more to have contact with students in informal settings (not that they would necessarily have the time, with their overloaded schedules)? Or maybe the teachers who have a lot of student contact should speak a little bit about departmental issues in their classes so that the whole thing is a little more transparent?

Difficult Assignments

As a student, whenever I received an obviously challenging assignment, my first assumption was that the professor was a sadist who just enjoyed seeing students fail. (Apparently I'm not the only one; typing "sadistic professor" into Google gives 755,000 hits.)

Being on the other side, I do give challenging assignments in my classes, and even difficult questions on quizzes and exams. But I do it for the opposite reason: it doesn't give me any joy to see a student fail (quite the contrary), but it does give me great pleasure to see a student encounter a really tough problem... and then they succeed.

Culture Shock: Student Passion (or lack thereof)

I've recently mentioned the lack of passion I've seen in teachers, compared to that of game developers. It occurs to me that the same complaint can be made of students.

Admittedly, this is largely the teachers' fault. How hard is it to get excited about something when you're learning from someone in the field who just isn't excited about their own work? Still, it's a bit of a surprise for me, coming from a job where everyone is working together as a team to make games... and seeing students working in a totally different way.

In the game industry, at least on the projects I've worked on, most people care about the project. Sure, if you work really hard to finish the work on your plate, your "reward" is to get even more work piled on you. So if you're cynical, you could say that the best "strategy" is to just do the bare minimum you need to not get fired. After all, you're salaried, so it's not like working harder actually means more money or rewards or anything. And yet... that almost never happens in practice, because the real reward is that your game is better. And if you care about the game, and you want it to be a good game, then you'll do whatever you can to make it the best game you possibly can. If you don't care about the game... well, there's a whole big software development industry out there that has nothing to do with games, which will pay you more money for less work. So people don't tend to become game developers unless they have this drive to make great games.

You'd think that the same would be true of game dev students, wouldn't you? Put a group of students together to make a game, and you'd expect them to all work insane hours and do everything they can to make it the best student project ever. After all, it's not like students can't do amazing work.

But in practice, you don't always see this. Sometimes you get an outstanding student team (usually the result of a single outstanding student leader who pulls the team together, and if you removed that one student the whole thing would collapse). But I'm seeing a lot of cases where this isn't happening at all. Some students don't show up for meetings and don't do any work at all -- as if they wanted a free ride, just a grade, and they don't care that this project is something that could go in their portfolio and get them a job (among other things). Students make excuses about why their work is late, when I know full well it's because they were just goofing off and procrastinating, a sign that they don't really care much about their project (they just see it as classwork, not an original project).

I'm still trying to find ways to make sure students get it, that game projects are an opportunity to create something experimental and new and different and original and really really cool (possibly the last opportunity they'll have for the next ten years of their career), and that they should really care about it. But I feel like it's an uphill battle sometimes, like I'm fighting against a dozen years of "education" that teaches students to jump through hoops for a piece of paper with the attitude that the real stuff comes later after graduation.

And it's a bit of a shock for me, even now, because I don't have to deal with this in the industry. I don't have to ask the programmers on a big-budget game to show up to work and give their best effort, because they already do.

Random Teaching Bits

I recently attended a teaching workshop. (Irony: during the day, as I was learning to become a better teacher, I totally blew off the online class I'm teaching.)

Here are some takeaways I got from the session:

• Normally at the beginning of a course, I ask students what their expectations are. This is good; it gives them ownership over the contents, and ensures that everyone's taking the right course for them. However, there's a problem: most of the time, my students don't know to expect, so they say nothing. Possible solution: ask where they see themselves ten years from now if they continue in this field. What skills do they expect they'll need and use? This lets me deal with student expectations about the course and the industry at the same time, and a greater number of them will have something to say in response since they all probably have some image in their head (no matter how inaccurate) about What It's Like Out There.
• Another problem I run into occasionally is a student who is having issues outside of class and it makes their coursework suffer, but I don't hear about it until after the fact. Solution: address this on the first day of class as a matter of policy. I particularly liked how one professor put it: "my job (as a teacher) is to help my students succeed, and I can't do that if I'm not kept in the loop."
• Lastly, part of the process of mastery and learning is feeling really stupid at times, and this is something that I don't think occurs to a lot of students (especially if they've excelled at all of their classes before). Really, the more you know in a field, the more you realize that you don't know. Once you master the basics, that's when it starts occurring to you that there are all these unsolved problems, and all these new ways to put things together. As a result, the smarter you get, the more ignorant you feel. Corollary: if you feel like a total moron, it probably means you're learning something!

The Importance of Keeping in Touch

I recently had a conversation with Alex, a former student of mine who made it in the industry (and totally deserves it, and I mean that in a good way). He's just finishing up his first project, so I took the time to get in touch with him and -- without having him break any NDAs -- did something of a post-mortem on his college education.

It occurred to me afterwards how useful our conversation was. As a teacher, I get some feedback during the education process but I get precious little after the students leave campus, so how am I to evaluate if my teaching is useful? An hour on the phone was worth a hundred end-of-course evaluations.


The biggest takeaways I wanted from the conversation:

• Did he enjoy the job? What were the best and worst parts? (This gives me additional content for my classes, either with a real-life horror story or success story, and some people might actually know him so the stories are more credible.)
• What was it like working on the project? (This tells me how obsolete I am. For now, at least, his experiences were similar to mine... so my descriptions of what it's like out there as a newbie are still valid for now. Whew!)
• What were some challenges they ran into in the project? (This is also an obsolescence gauge, and it tells me if I'm teaching the right skills based on whether I have course assignments that mimic real-world challenges.)
• What were some things that he encountered in the industry that I just totally failed to prepare him for? (The scariest question to ask but the most important.)

Anyway, I would encourage other professors and recently-graduated students to do something like this, especially at the time when the ex-students are just finishing their first project and have some time to reflect. Professors: initiate the conversation, as some students may be too busy or intimidated to just open up and start criticizing you after they're gone. Students: initiate the conversation, as professors tend to keep busy and have lots of things going on at once, and it'll be much easier for them to have this feedback if you open the door.

For what it's worth, my two big takeaways from this for myself:

• What went right: the importance of learning a new genre. Alex had never even heard of the genre they were creating before (tower defense games) and he had to learn really fast! This is a common thing in the industry for new designers, and being able to research a type of game they've never played before is a great skill to have. I had my students create a user interface for a modern football game, given the (correct) assumption that most of them weren't that familiar with sports games... or sports, for that matter. There's even an entire chapter in my book on how to work with an unfamiliar genre (Chapter 12).
• What went wrong: I didn't place enough emphasis on Excel in my classes. Sure, I said plenty of times that Excel is to game designers what Microsoft Visual Studio is to programmers and that students should do everything from keeping game stats to their checkbook and grocery list in Excel just to get familiarity with it... but how often did I actually give a game design assignment that required the use of Excel? Almost never. And I never gave any lectures on advanced features of Excel that are useful for game designers (like the use of RAND, RANK and VLOOKUP to create a randomly-shuffled deck of cards). I could probably offer an entire course in "Excel for Game Designers" but failing that I should at least have a few homework assignments that require it.

Updated Labels

As long as I'm on a blog-housekeeping kick, I've just bitten the bullet and added labels to all old posts, so if there's a particular post of interest you should hopefully be able to find similar posts this way. Enjoy!

I have a feed

Several people have asked me in the past if I have some kind of newsfeed for this blog. I had no idea. It's kind of like when someone asks you for your phone number, and you can't remember because you never call yourself.

Brenda kindly pointed out to me that I do indeed have one, and it's here: http://teachingdesign.blogspot.com/feeds/posts/default

So, for anyone wondering how to subscribe, there you are.

Bloom's Taxonomy

In the past, I've said that there's a direct link between education and game design. Mostly, I think about things that teachers can learn from the field of game design (because in my experience, a lot of teachers have trouble with something that games do really well: actively engaging the players/students). But this is my bias, because I have a lot more experience designing games than I do teaching. I'm just now realizing that game designers should be paying more attention to the field of education as well.

Case in point: Bloom's Taxonomy. Most game designers have never heard of this. I've heard it referenced often when teachers are talking to other teachers about their field, so presumably it is to education what the MDA Framework is to game design.

What is Bloom's Taxonomy? Long story short, it's a model for how we learn. First, we memorize a bunch of facts without really understanding them; then we start to understand what these things all mean, and we begin to actually use them to solve known problems; eventually, we learn to analyze new problems and solve them too, and if we stick around in a field long enough we learn to put existing tools, models and techniques together in new ways so that we can solve some problems that couldn't be solved before; finally, we get to the point where we can not only solve our own problems, but also evaluate other people's work in a competent way (which is something that, ideally, all teachers are capable of... but I digress).

Bloom's Taxonomy is important in teaching because it helps you to think of appropriate ways to design your courses based on learning goals. If you want your students to emerge from your course with the ability to analyze problems in your field, you're not gonna get there if all of your assignments and tests simply require rote memorization. On the flip side, if your goal is for your students to be able to apply knowledge to solve specific types of problems, then asking them to make abstract value judgments on other people's work is probably too advanced for the level you're teaching.

But enough about teaching -- think about this in terms of game design. Bloom's Taxonomy describes any kind of mastery... such as the act of a player mastering a game:

• Knowledge = learning the basic controls and mechanics of the game
• Comprehension = learning to use the controls without looking at the manual every 5 seconds; understanding the challenges that the game is throwing at you, and the general nature of what you must do to overcome them (whether you're capable of doing so or not)
• Application = advancing in the game, using your skills to "beat" an enemy, boss, level, etc.
• Analysis = optimizing your gameplay, e.g. choosing the best combination of skills, items and equipment for your party in an RPG. In other words, powergaming.
• Synthesis = finding new methods to optimize your gameplay with. The player innovation in MMORPGs of calculating "damage per second" as the ultimate measure of strength is an example of this. Anyone can use damage-per-second, but to come up with the idea in the first place required a pretty deep understanding of the game.
• Evaluation = at this point, I think we see a solid division between your average gamer and someone who has crossed the line to being either a game reviewer, critic, or designer. This would be the ability to look at several similar games and decide which one is "better" in some way (more fun, more balanced), while being able to back it up with solid reasons.

As a game designer, this has clear applications. Most games do not make use of all of these steps; a simple retro-arcade twitch game never goes beyond application, while only the most open-ended experiences lend themselves to any synthesis tasks. And this is fine, but it helps to explain why, say, a retro-arcade twitch game with an inventory/equipment system, multiple character classes, multi-level tech trees and such would probably not work.

This also explains what you need to do if you want to create an open-ended game where you expect players to find their own unique solutions to your puzzles (as in Thief or Portal). You have to work up to it, first taking your players through the knowledge, comprehension and application steps and making sure they're comfortable with those (perhaps by forcing them to: making it so that they cannot progress until they have mastered the basics). Only then can your players impress themselves with their own ingenuity at putting two mechanics together in creative and unexpected ways. Just giving the players all the tools up front and letting them play won't work, any more than giving your players a stack of equations on the first day of Physics 101 and then expecting them to "put it all together" and build a working rocket.