Then there's the question of grading. If I have a programmer, a couple of designers, a producer, an artist, maybe a sound guy, all working on different aspects of the same project... how do I grade them?
So far, I've come up with several possible methods:
1) The "I know it when I see it" method. No quantitative grading at all, I just assign whatever grade I feel the student deserves. While this would probably give the grades that are the most in line with what students have done, it's a terrible stress on the students themselves, and it puts a lot of burden on me to Get It Right. And if a student complains that they got an unfair grade, I have no defense.
2) The project-based method. I grade the final project, not the individual students. Everyone gets exactly the same grade. I don't like this, because it doesn't allow for variation in student abilities.
3) The discipline-based method. I grade the programming on the final project, and anyone who was a Programmer gets that grade. I do the same with design, art, audio and production. Everyone gets graded on their own work... except that you quickly realize that everyone's work affects everyone else. Maybe the game has a brilliant design, but it just can't be implemented by the programmer(s) in the amount of time we have; this is an issue with design and programming and production, so who gets a lower grade?
4) The method I'd like to try is a hybrid between project and discipline. I grade the final project on its various aspects, and each student gets a different weighting of those aspects based on their role:
- Programmers: 40% programming, 5% design, 10% art, 10% audio, 15% production.
- Designers: 15% programming, 40% design, 5% art, 5% audio, 15% production.
- Artists: 5% programming, 10% design, 40% art, 10% audio, 15% production.
- Audio: 10% programming, 5% design, 10% art, 40% audio, 15% production.
- Producers: 15% programming, 10% design, 10% art, 5% audio, 40% production.
- Everyone also has 20% class participation. Class time is roughly the equivalent of team meetings, and not showing up for work is obviously bad.
Where the five categories are roughly defined as:
- Programming: does the game work? How buggy is it?
- Design: is the game fun?
- Art: does the game look good?
- Audio: does the game sound good?
- Production: did the game get finished on time with all of the intended features?
I'm hoping to impress on the students that their work affects the rest of the team, and the rest of the team's work affects them, and that in the industry they're ultimately "graded" on the sales of the final game above all else.