Sunday, May 24, 2009

Academic Program as MMO

On the IGDA Education list, fellow industry-vet-turned-educator Kevin O'Gorman made a great comment that I wish I'd thought of first:

There's the curriculum you roll the program out with (fingers crossed the people that pulled it together were at least aware of the Ed SIG Curriculum Framework) and then the tinkering and fine tuning that goes on from that point on. It's like an MMO -- the launch is the beginning, not the end of the process.

How far can we take this analogy? Pretty far, actually...
  • Both academic programs and MMOs need hefty amounts of resources to initially develop, before either one of them sees a single paid player/student.
  • Both are based on a similar pay model: pay-per-month or pay-per-semester, regardless of how many classes you take or how often you're logged in.
  • Multiple sections of a course are the academic equivalent of instanced dungeons.
  • Character classes are the MMO equivalent of an academic major.
  • Look at a skill/tech tree for a class in a typical MMO. Looks suspiciously like a list of classes and prereqs, doesn't it? (Hint to game schools: try adding a "tech tree" diagram to your course catalog and see if it doesn't remove half the pain from your academic advising.)
  • In theory, an MMO wants its players to stick around forever; in practice, it's recognized that there is regular churn (you could call this the game equivalent of "graduation"), and so the developer/school must be concerned with attracting new customers/students as well as retaining existing ones.

The analogy does break down eventually. I don't think I've ever sent my students on a "fedex quest" in exchange for grades, nor can my students buy better equipment in my classes in exchange for cash. Students could theoretically sell their work to others at an online "auction house" but it's against the TOS/EULA of a class to turn in work that isn't yours (unlike many MMOs). You can buy "pre-leveled" characters but not a "pre-completed" degree.

Still, perhaps schools could be improved in some aspects if administrators took some cues from WoW.

Posted by at 6 comments:

Monday, May 18, 2009

Career Advice for Teachers and Designers: Do, Don't Show, Don't Tell

There is something that has taken me many years to learn, after observing a number of other game designers and the systems that affect their careers. It boils down to something like this:


If you have to tell everyone how great you are, then you're not.



The best designers do not have to "self-promote" within the industry, because they have worked with other people who respect them enough to be their willing evangelists. As soon as you spend too much effort trying to build yourself up, that is precisely when the rest of the industry will gleefully tear you down. If you feel unappreciated, like you're just not getting a fair shake and you're not getting the attention and appreciation you deserve, it is because there are so many talented people out there competing for that same attention. Best move is to be patient and not overreach; yes, you will feel underappreciated for awhile, but in time your good work will come back to you.


If, by contrast, you spend a lot of time and effort convincing people that you're God's gift to game design, the worst possible outcome is that you succeed in your efforts. And then you're given a project that is beyond what you can handle. But you won't realize it, and you'll take the entire project down with you, and your co-workers will not thank you for their pink slips when the studio closes.

The same rule applies to teachers, but in a different way.

There is a temptation as a teacher to drum up attention for your classes. You want students to know that you're teaching all these cool classes about video games. You want enough students taking your classes that it proves to the higher-ups that there is demand and that they need to throw more resources at your program. You (and probably your boss and boss's boss) want "butts in the seats" under the assumption that if only enough people take these classes, they'll see how awesome they are and spread the word.

This leads to a similar problem as with the industry. If you promote your classes, you will get some students who either feel compelled to take them by your high-pressure tactics, or you will get students who are largely unmotivated and assume that "game class" equals an easy A. Neither of these students really wants to be in your class, nor will they try particularly hard.

In the long term, I'm thinking that the best way to promote your classes is to spend all your time making your classes a great experience. If the classes are that awesome, your students will evangelize for you, and they'll do it better than you can. Your initial class population might be lower, but it will also be more motivated and energetic because those students had to do some work just to take the class -- they had to find out that it was there, and they had to read the course description and probably talk to their advisor to see if this was for real, and they had to sign up on a leap of faith without encouragement from you. These are the students you want in your class.

In both industry and academia, this is the advice I would give:

Spend your time doing great things. Don't spend as much time showing or telling about your work. Let others discover it for themselves.
Posted by at 4 comments:

Friday, May 15, 2009

Back to basics...

A student is admiring my Ra board.
"Is that signed by Reiner Knizia?" he asks. It is. He even pronounces the name correctly.

I mention that at home, I also have a chessboard signed by Garry Kasparov.
The student asks, "who's that?"

Sigh.

Just when I think I've got this education thing down, I find out that there's more work to do.
Posted by at 1 comment:
Labels:

Thursday, May 07, 2009

Types of Student/Beginner Design Projects

There are many kinds of project that help someone to learn design. Some are more or less appropriate in the different stages of a student's educational experience.

Non-digital games (i.e. Eurogames). Design a complete non-digital game (such as a board game, card game, or tile-laying game) from scratch.

Advantages of Eurogames:
  • These kinds of games represent game design in its purest form. The design is laid bare, and cannot be concealed by high-poly-count art or impressive technology.
  • These games can be built very quickly and cheaply. To make a "first playable" version takes only a few minutes, typically using only simple components like index cards and notebook paper.
  • They tend to play quickly, which gives a lot of opportunity for playtesting, iteration, and polish if extended to a longer project (1 or 2 month time frame).

Disadvantages of Eurogames:

  • Does not often meet student expectations. Students starting out in a video game development curriculum may be confused or frustrated that they are not working on video games. Extra care must be taken to justify the concept.
  • In America, board games have a poor reputation from our culturally-accepted "family game" fare of Monopoly, Chutes & Ladders, the Game of Life, and other children's games. Initial exposure to Settlers of Catan, Carcassonne, Puerto Rico, Bohnanza, and the like requires a massive paradigm shift on the part of most people.
  • Because students have little experience with board games, many "original" ideas are actually things that have been done before, but the student is not aware. In my classes there's always at least one student who sponteneously and unintentionally re-invents some classic game that they've never heard of. These projects require a lot of guidance and game-literacy on the part of the teacher.
  • Some aspects of Eurogame design do not directly apply to video games. For example, it's hard to simulate the satisfying feel of pressing a button to make Mario jump in a board game.

Recommended for:

  • A student's first experience to the world of game design.

Tabletop RPGs. Design the system for an RPG, playable by one mediator ("GM") and a small group of players. I would also include LARPs and, to a lesser extent, ARGs in this category.

Advantages of RPGs:

  • Most students are at least familiar with Dungeons & Dragons, so prior experience is not a problem. A fair number are enthusiasts of the form, so this will generate a fair amount of excitement.
  • Most RPGs require a strong integration between gameplay and story, making them ideal for the study of both game-based storytelling and core systems design.
  • As with Eurogames, the system is laid bare in the rules, making RPGs a very pure form of design (even moreso than Eurogames, as most RPGs only have a handbook and not even any board or game bits).

Disadvantages of RPGs:

  • RPGs are a very specialized form of design that may not immediately carry over into some other game media or genres.
  • The enjoyment of an RPG relies largely on having a good GM and a good set of players. Good play can salvage bad design (and poor play can wreck a great design), making it difficult to evaluate a game purely on its own merits.
  • RPGs take a long time to play. Typical play sessions last several hours, played regularly over the course of months or years. This greatly slows the number of playtests and iterations allowed in the space of a single course.
  • Take a look at a professionally-printed RPG rulebook some time. Many are in the hundreds of pages, and are too large in scope for a student project. Even if you remove a lot of the fluff and filler, something as "small" as a 15-page rule set will still seem large to a typical undergrad student.
  • Since RPGs integrate story and gameplay, it's important to have a solid understanding of both before taking on this kind of project. Learning how to tell good stories is hard. Learning how to design a solid and balanced rule set is also hard. Doing both together at the same time is too hard.

Recommended for:

  • A mid-level elective course, with an intro game design course and an intro storytelling course as prerequisites.

Video games. Of course, when most students are thinking of "making games" they are thinking of video games. Generally, at the student level, I would subdivide this into two types of video game projects: very small and short individual projects, and mid-sized group projects. Most students would prefer to make large AAA video games, the kind that take several years with a team of hundreds of professionals, but of course the scope is too large for a college course.

Advantages of individual video games:

  • Students really get to take ownership of their project, and it is usually very exciting for them to be making their own original video game.
  • A truly outstanding student project has the possibility of winning an IGF award, which is a big deal.
  • This is the most practical form of experience for students who want to make video games as a career.

Disadvantages of individual video games:

  • Most individuals do not have art, sound, programming, and game design expertise, so some students will be disappointed and frustrated at their inability to do certain things in their project.
  • Scope control is a problem with inexperienced students, who tend to design more than they can reasonably implement in a length of time. It requires a sharp eye and quick response from the professor to get students to keep their projects manageable.
  • Because it is not going to be a AAA game, some students will take a small project less seriously than they should.
  • At the very least, an individual game requires both programming and game design skill (art and sound can be fudged more easily). Learning programming is hard. Learning game design is also hard. Trying to learn both at the same time is too hard, and is the reason why so many people fail when they start out trying to program their own game from scratch as their first hobby project.

Recommended for:

  • High-level class with a lot of prerequisites. Concentrates on showing students how to assemble all these various component parts in order to make a complete video game.
  • High-level class with several game design and programming prerequisites. Concentrates on rapid prototyping, and making games that are ugly but functional as a way to test out certain mechanics or ideas. (A lot of prototyping can be done on paper, but some things like User Interface are best done digitally.)
  • Intermediate programming class, with a game design class as prerequisite. Students learn programming while applying what they already know about game design.
  • Introductory programming class, where the game design is done by the professor ahead of time and students can concentrate solely on implementation.

Advantages of group video games:

  • Most directly simulates the interdisciplinary team environment found in the industry.
  • Students can specialize; each individual does not have to be good at everything, as long as they are very good with at least one thing.
  • Allows for larger scope than individual projects (although still not as large as AAA games).
  • Like individual projects, an outstanding group project is potentially IGF material.

Disadvantages of group video games:

  • Most students do not have a lot of experience working in teams. Lots of things can go wrong: an individual unmotivated student that drags down the team, communication lapses between students that make integration difficult, the design team overscoping the project, personal conflicts between team members, and all of the other general chaos that happens when people try to work together.
  • Since this requires students from several disciplines, you usually have to recruit from multiple departments. Setting up a cross-listed class and getting the go-ahead from outside your home department is a bureaucratic nightmare. Getting a good mix of students with varied abilities is likewise difficult.
  • Students will tend to bite off more than they can chew, especially once they realize that they have so many people working on a project. Getting them to start small and add (rather than starting big and cutting) is always a challenge.

Recommended for:

  • A senior-level "capstone" course, after students have already taken all of the core courses in their respective majors.
Posted by at 3 comments:

Sunday, May 03, 2009

Culture Shock: Academic Freedom vs. Industry Constraints

When reading about Brenda Brathwaite's series of non-digital games (this includes games about such heavy topics as the Middle Passage, the Trail of Tears, and the Holocaust), it struck me that this kind of project would never happen in the game industry.

I don't mean that it would never get publisher funding. I mean, it wouldn't, but that's not my point. My point is, even if it were on her own time with her own money outside of work, this would never be allowed to happen.

Think about it. Suppose you were a working game developer and you casually mentioned to some co-workers that you were thinking of making an art piece and showing it at galleries, and that the topic was highly controversial and this was sure to have a lot of people cheering, and a lot of other people up in arms. How many nanoseconds would it take before your producer found you at your desk and asked you very nicely not to do this, out of fear that the Company would receive negative media backlash, and this is the last thing we need when we're courting three publishers for our next contract, so if you're interested on working on non-digital games maybe you could make something about fluffy bunnies instead? (I suppose some companies make controversy part of their business plan, but I'm talking about everyone else.)

This is a completely different paradigm than academia, where the whole concept of tenure is (at least in theory) supposed to be about the freedom to do anything, no matter how controversial. As an academic, you actually get support for things like this. You can sometimes get funding for things like this. Not everywhere, I'm sure, but it seems more likely that a random school will at least not get in your way if you want to take on a controversial product, compared to a random game company. One more point to consider if you're considering a career in either and you prefer to have total creative freedom.
Posted by at 3 comments:

Saturday, April 25, 2009

Back on regular posting schedule

I've been out of commission for a while, due to GDC and then GDX. I'm just about caught up.

For what it's worth, there are video recordings of some great GDX sessions online. Mine isn't on there (maybe I used too many swear words?), but the ones posted are excellent. Highly recommend Jason Arnone's and Jon Jones's talks for any aspiring visual artists, Mark Nelson's talk for anyone interested in open-world games, and Andrew Baines for any aspiring FPS level designers out there. Jason Rohrer's talk was more conceptual than practical (as keynotes tend to be) and focuses on why games don't have the cultural legitimacy of other established media -- something that anyone in game studies would do well to consider.

And if you're ever down in the Savannah area during GDX in the future, I'd highly recommend attending. Great speakers, small and intimate/casual atmosphere, lots of great talks and great people all around.
Posted by at No comments:
Labels:

Tuesday, March 31, 2009

Game Design Concepts: an Experiment

For those of you who I met at GDC and found their way here, welcome!

One thing I talked to a lot of people about is an experiment I'm doing this Summer, called "Game Design Concepts."

This is a free online class that I'm going to teach. It is not affiliated with any college or university, and not for credit. It will be taught through a combination of blog, email and wiki. It contains all of the information (and then some) in one of the game design classes that I normally teach in a classroom in exchange for tuition money. But I'm releasing it for free this Summer.

The subject of the course is, as you might expect, game design. The intended audience is:
  • Students who are interested in game design, and either are at a school that doesn't teach it well or doesn't teach it at all (or maybe you just want a second opinion).

  • Teachers, especially those who teach game design. You can compare my material with that of your own class. Maybe you'll find some useful resources that you didn't know about, and maybe you'll be able to offer me some hints in return.

  • Game developers who aren't designers. In a lot of companies, game design is still considered something of a "dark art" and those who aren't designers are often curious about how game design is done. In a few hours a week, this whole other field can (hopefully) be demystified.

  • Game designers. Do you have an interest in contributing to education? Do you want to know what it is that the next generation of designers -- the ones who are likely to report to you in 4 to 6 years -- are being taught in the classroom? This is a way to find out, and contribute your own experience in the process.

  • Anyone else with an interest in learning more about game design. For example, parents or grandparents of game designers who are curious about what these kids are doing; or hardcore gamers who want greater insight into the design decisions that make their favorite games so great.

If I've got your attention and interest, the blog is at gamedesignconcepts.wordpress.com and all updates (including instructions to register) will be posted there.

Tuesday, March 17, 2009

Gearing up for GDC

It's that time of year again. I can't believe it starts in less than a week.

If you're going to GDC this year for the first time, here's a link to my advice for what to bring with you. And here's another link to Darius's store of GDC advice. Be prepared!

If anyone wants to meet up, there are three easy places to find me. First, I'm speaking at the Game Education Summit on Monday. Second, I'll definitely be at the blogger group gathering on Thursday. Third, it's tradition by now that I'll be up early for breakfast on 3rd floor of Moscone West each morning, at the tables right near where the escalators dump you out. Look for the guy who has board and card games.
Posted by at 3 comments:

Sunday, March 15, 2009

Culture Shock: Learning Disabilities

Autism. Aspberger. OCD. ADD. ADHD. Tourette's. Bipolar. You name it, someone in the game industry has it. Probably several someones, and probably at least one someone who is incredibly successful.

For this reason, it's hard for me to even call these "disabilities" -- given that the word "disabled" literally means that the person is not able to do something, and clearly it is possible to make games regardless of what psychological label might be applied to someone. But then, I'm not a psychologist.

For the most part, people in the game industry don't care if you've been diagnosed with anything, as long as you can help them make great games. You could be criminally psychotic for all we care, as long as it doesn't impact the development schedule. (Okay, I exaggerate. But only slightly.)

So, it took me by surprise the first time a student gave me this little slip of paper from the campus office of disabilities, several years ago (I've since gotten used to this ritual; it seems there's always at least one per class, and usually more).

For those of you who have not taught before, here's how it works: the student brings you this paper that gives you (as the teacher) no practical information, except to tell you that the student requires some special privilege (commonly, extra time and privacy when taking exams). You have to sign it -- in all the places I've taught, I've never been allowed to keep a copy -- and then the student takes it back. Presumably it gets filed somewhere, I don't know.

And then, naturally, you forget about it, because you're not allowed to keep a copy. Until exam time comes, and you remember that two of your students have special requirements, but you can't remember which students (many students with so-called "disabilities" are quite high-functioning), and one of them might have dropped your class a few weeks back anyway. Oops. I've been doing this for a few years and I still manage to screw this up most of the time.

The most frustrating thing, though, is that you're given no information about how to teach more effectively. I understand and accept that we're dealing with confidential information on a need-to-know basis, and I will often be getting the bare minimum of relevant information. But this conflicts with a desire to teach properly, and if I know that (for example) talking more slowly or repeating myself will help or hurt the situation, or if making my lecture notes available is useful, or if I should avoid calling on a student in class because it would embarass them... well, it'd be good to know, but there's no way for me to find out without a confidentiality breach.

The obvious thing to do in these situations is to talk to the student directly, and simply ask if there's anything you can do... but often the student doesn't know, because they aren't a professional educator.

Best solution, I suppose, is to take matters into my own hands. Read books on as many of these disabilities as I can find, particularly any that might give clues on how to teach better, and hope for the best.
Posted by at 4 comments:

Thursday, March 12, 2009

Last-Minute Begging

I see this happen from all kinds of people.

Students: "I know I haven't turned in half of the assignments and I haven't been in class for the last month and this is the last week of the term, but I'm failing the class and is there any way I can do something for extra credit?"

Professors: "I know grades for this term were due a few weeks ago, but I've been so busy with other things that I never got around to sending them in. I hope that didn't inconvenience you by preventing your graduation, or making it impossible for you to get a final transcript for that job you're applying to. I'll get it in this week, I promise!"

Professionals: "I know you asked me how I was doing on my task list every week for the entire project and I've said fine, but I realize now I'm three weeks behind and we've got a milestone due tomorrow. Can I get some help?"

For some reason, some people have a really hard time saying that they're behind until it's too late to do anything about it. And yes, I've been guilty of this in the past, which makes me quick to spot it in others.

Now if only I can find a way to convince students of the danger of this without them having to live through the hell-stress of being about to fail, before the lesson sinks in...
Posted by at 1 comment:
Labels:

Wednesday, March 04, 2009

IDEO's Ten Tips for Teachers

Brenda pointed me at this article about creating a "21st century classroom experience." This has nothing to do with game design per se, except that just about all of these tips are restatements of basic game design principles, suggesting once again that game design is applied education (or maybe it's the other way around).

Summary of the tips and their context as a game design teacher (several points in the article are restatements of one another, so I collapsed them):
  • Don't just push information. Encourage students to think critically by creating an environment where the students can (and want to) ask questions. Translation: let the player actually play in your game world. How fun would a game be if it just told the player to enter a certain code and then asked them to play it back?
  • Make it relevant. Don't just explain arbitrary facts, put it in the context of how they're actually used so the students can see a connection between theory and practice. I've already written about that a couple of times.
  • Soft skills are important. What will really make the difference is your students' abilities in leadership, empathy, communication, teamwork, and other things that are hard to measure on multiple choice exams. This is why games like The Sims and World of Warcraft are popular, despite them not having distinct measurable goals.
  • Allow for variation. Education isn't one-size-fits-all; different students have different levels of ability and prior experience. Translation: include multiple difficulty levels in your game.
  • Give practical experience, not just theory. The article goes so far as to say that teachers are "designers" so apparently I'm not the only one saying this. Translation: if it's nothing more than a series of cut scenes, it isn't a very fun game. Or, as Sid Meier has famously said, "if the designer is having more fun than the player, you have made a terrible mistake."
Posted by at 4 comments:
Labels:

Sunday, March 01, 2009

Teaching Iteration and Risk-Taking

There is an inherent conflict between the nature of classes and course objectives, when it comes to designing a game as a class project.

The best way to learn to design games is to make a rapid prototype, fail miserably, figure out what you did wrong, and try again. Repeat until you get it right. In order to do this, the student has to feel like it is okay to take risks, that it is perfectly acceptable (even expected) to try crazy stuff that may simply not work out.

But of course, this is for a grade. Enter the fear of failure. Or, it's not for a grade at all. No threat of failure, but likely no effort put in by students on an "optional" project. Is there a way around this paradox?

Here's the method I'm currently using:
  • My non-digital game design project has four milestones. The first is just a high concept, target audience, basic information (number of players, etc.) and some core mechanics. The second is a rough but playable prototype. The third is a playtested prototype, with the mechanics finalized or close to it. The final milestone is a polished product.
  • All milestones are graded. Early milestones are easy points -- just turn in something, anything, as long as it works. Later milestones are graded based on the quality of the design -- you'd better have done some iterations.
  • For the future, I'm thinking that early milestones should be worth fewer points than later milestones. This puts less importance on early work and more focus on the final product.
  • On the days where milestones are due, students bring their works-in-progress to class and present the work for peer review. This also gives me a chance to see how the projects are progressing. In the future, I should probably just give a grade right then and there for the early milestones.
  • Make it clear to students from the beginning that the more they iterate on their project, the more they playtest, the more they fail and then change, the better their final project will be. Unfortunately, this is one of those things they might just have to find out the hard way for themselves. I'll try bringing in a student work from an earlier course (with permission) in its various stages of completion, to show just how much difference playtesting can make.

Saturday, February 28, 2009

Blogging on Applied Game Design

In addition to this blog, Brenda has given me the ability to post on the Applied Game Design blog, so I will occasionally make posts over there about the theory and practice of game design.

Why not just post here? I want this blog to remain a resource for students and educators about teaching game design, and my own rantings on how to actually make better games are best done elsewhere.

Any post over there by 'ai864' is me. I've already made my first post.

I will still be writing here about teaching game design, of course.
Posted by at 1 comment:

Wednesday, February 25, 2009

Theory of Fun back in print!

Raph Koster's A Theory of Fun for Game Design has been out of print for a few years, making it obnoxiously difficult for anyone to actually buy it for less than 200ドル or so.

Happily, it is now back in print for about 15ドル.

I suspect a lot of teachers will suddenly be adding another book to their required texts next term...
Posted by at No comments:

Global Game Jam article on Gamasutra

For those of you who are wondering what was going on during the Global Game Jam, Stephen Jacobs wrote up a fantastic blow-by-blow account of the action. His article is on Gamasutra.

I'm even quoted a few times in the article.
Posted by at 1 comment:
Labels:

Friday, February 20, 2009

Sometimes, I teach a little too well...

The other day, I met some people who are thinking of hiring a game designer, I mention that I'm available for contract work.

One of my students who was present stepped in front of me and mentioned that he's also available, and cheaper to hire than me.

I know that I always say to pay attention, be observant, be ready to pounce on an opportunity... and apparently some of them actually listen. I'm thinking that, in the long run, this is probably a good thing.
Posted by at 1 comment:

Wednesday, February 18, 2009

Summer Internships

The question was recently raised on the IGDA Game Educators mailing list: how can students find summer internships in games? If you're a student, this is probably on your mind; if you're a professor, students will probably ask you. I posted a response there, but I thought it's worth saying here.

First, let me say that internships in the game industry are rare. This is not about game companies being mean, or hating students. It's because game projects typically take longer than a summer, and development teams don't particularly like it when a key project member leaves in mid-project. It also takes people time to ramp up, which means just around the time the intern is finally able to contribute something to the team, they leave. Also, interns take a lot of management time that a typically-overworked producer does not have, so many studios decide that it's just not worth it.

This is not to say that internships don't exist, merely that the companies that offer them tend to be low-key about it (lest they be flooded with tens of thousands of resumes from eager college students). That means they aren't advertising, so you have to find them other ways (see below).

My advice to students seeking summer employment:

First, do your homework. Research a lot of game companies, go to their corporate websites and see if they have internship programs. Best bets are local companies, since realistically you aren't going to get housing or relocation expenses (some companies won't even consider you for an internship unless you live in the area). Be willing to look at lesser-known companies (not just the big names that you drool over), and look in related fields like serious games -- fewer students are looking there, so there's less competition.

How do you find local developers? First, check GameDevMap. Second, check if there's a local IGDA chapter. Third, check Google with a search string that implies game developers in your local area. Fourth, check with your school's career services office... but you probably won't find anything there that you couldn't have found on your own, which is why I list it last.

Some "internships" may not be listed as such; rather, they may be called "QA" positions that just happen to span the summer term.

If you can't find anything in games, consider a related industry. Programmers can do a programming internship at any software company and still gain valuable experience. Artists could work in fields like advertising or industrial design.

If you absolutely can't find any paid work, finances permitting, "hire" yourself full-time to work on your own game projects! Force yourself to work 40+ hours per week on your own game, as if you were at a full-time job. (This works even better if you have some friends you can team up with.) Keep your scope small, so that your projects are achievable. The point here isn't to "start a game company" or "make a great game and sell it" -- the point is to get valuable experience making games. If your project sucks, that's fine, as long as you learned something from the process. If your project does end up being awesome, enter it in the IGF student showcase, which is just as juicy a resume bullet-point as an internship (if you win).
Posted by at 1 comment:

Sunday, February 15, 2009

Does "online" mean "automated"?

It seems to me that every school that offers online courses does things a bit differently. For the classes that I teach online, I try to have as much interactivity as I have time for. I'll post on discussion boards, I host virtual "office hours" through an online chat program, and I send out regular emails with my own personal spin on the topic. I also offer feedback through grading papers, even if it takes me longer.

I realized today that in theory, the entire thing could be automated:
  • The course content is all online, so there's no reason why I need to add anything to it. Let the students read it on their own without the professor offering any extra commentary.
  • The discussion boards are for students to interact with each other, not the professor. When "participation" is one of the grades of the course, there are tools where you can get post counts, average length of post, and all kinds of usage stats without ever having to actually, you know, read what one of those student people is actually saying.
  • Papers can't be automated easily, but if you design the course you could go light on those assignments and heavy on multiple-choice and fill-in-the-blank quizzes which can be graded by a computer system.
  • Instead of holding regular "office hours", simply post your phone number and let students call if they need help with anything. You know they never will, whether it be from feelings of politeness or intimidation.

Not that I would ever teach this way, mind you. I don't think it's really teaching if I'm not involved, it's more like a long, drawn-out certification process.

On the other hand, it's easy to "teach" a class this way, so I'm sure there are people out there who do it like that. Some might just be overwhelmed with other things in life so they fall back on something easy. Others might be greedy and want extra pay for next to no effort. Still others might think this is what online classes are supposed to be, that once you get a computer involved it somehow means humans should be removed from the equation.

I suppose the lesson here for students is: buyer beware. Make sure that you're getting your money's worth when signing up for an online class, and make sure you know what kind of instruction and personalized attention you can expect. If all you're looking for is a few quick credit hours without having to leave your dorm room that's one thing, but if you're actually looking for an education then do your due diligence. (Put at least as much effort into shopping for a class as you might into getting a high-end stereo system for your dorm, since that's probably about what you're paying.)

Interestingly, I think there's a parallel here with outsourcing in the game industry, in that many companies that think "outsourcing" really want the thing they're outsourcing to be automated (and they find out to their chagrin that game development is not so easy a process to automate).

Posted by at 3 comments:
Labels:

Wednesday, February 11, 2009

What is the teacher's most valuable IP?

I have an ongoing discussion with several colleagues about the basic question of where a teacher's value lies. This is particularly important in a field like game design, where a new professor is likely going to be the only one in the department with any game-related expertise and will therefore be doing some curriculum development, some course content development, and of course the actual teaching.

There seem to be two schools of thought with respect to this.

The first model, I'll call "value in output." The professor is a machine that converts money and coffee into curriculum and course materials. The real value is in these secrets of the field that the professor distills into small documents like lesson plans and curriculum documents. This is valuable information that must be protected. You can tell the schools that think this way because they have something in their contracts that makes sure the school gets IP ownership of the professor's work, or (at the very least) they would be very much against a professor releasing this material to the public, or taking it to another school.

The second model, I'll call "value in person." The idea is that it is the professor who is valuable, not the work. A skilled professor can always create more classes, revise the curriculum or what have you, and it is therefore the human being that has value. An analogy would be valuing the goose more than the golden eggs. You can tell the schools that fall into this category by their willingness to release their course content online, give their professors more control over their own work output, and are generally happy to just sit back and do nothing as long as the profs are bringing glory to the school.

We have this in the game industry, too. Where is the value in a game: the IP, the code base, or the development team? Depending on a publisher's viewpoint, they will treat their developers very differently.

If you're a teacher or a developer, think for a moment about how your school (or your publisher) sees you and your contributions. Is there more focus on your work output, or your ongoing ability to produce that output? Which view is superior? If the answer is "it depends," what does it depend on?
Posted by at 4 comments:

Saturday, February 07, 2009

Speaking Schedule

Yesterday, I was in Savannah giving a presentation with Brenda at SCAD to other educators about the use of games as a teaching tool. It was intended as a combination of my earlier Origins presentations and our Game Design Improv event.

I learned something interesting here: when talking about games in education, I take for granted that most of the time I'm talking to educators who already play games heavily (or teach game development), so the use of games in the classroom is not a hard sell. In this case I was speaking with professors from art history, photography, audio, film, media studies, and several other fields that are not directly related to games. We spent a lot of time discussing whether games were worthwhile for classroom use at all, and if so in what situations. It was a wonderful discussion that really challenged us all, and it's a discussion I'm not used to having. I was also impressed by the high degree of game literacy from these professors who were not gamers; participants referenced a number of game industry personalities and important games. Apparently it's not just game designers who study other media; they're paying attention to us, also.

Coming up, I've got a few speaking engagements. I'm speaking at GDC, both times during the Education Summit. I speak twice: I'm doing the next iteration of Game Design Improv with Brenda, and also speaking with Susan Gold and Gorm Lai about the results of the Global Game Jam.

The month after that, I'll be at GDX (here's last year's site, the new one isn't up yet), speaking about the relationships between art history and game design -- basically, why game designers should take at least one art history class, and why they should pay attention. (Short answer: because we may feel like games are a new medium and we're blazing new trails, but an awful lot of what we're doing with games-as-art is stuff that the art world already addressed hundreds of years ago, and we need to understand this so we don't keep reinventing the wheel.)
Subscribe to: Posts (Atom)

AltStyle によって変換されたページ (->オリジナル) /