Teaching Game Design as a Studio Simulation
What was originally a short missive in response to a TGD member on our Discord channel turned into more of an introspective on teaching game development as a studio simulation. It’s not advice, but maybe prospective game dev teachers can spare themselves some wrong turns in the process because of it. Or maybe none of it will apply because they’re teaching high school and not college or have genius teaching methods or whatever.
I’ve created seven different game design curricula, and one of them is structured as a studio simulation. Students do feel “all grown up” by taking on a title in one of these, and some nice content came out of the one I taught, but I did fall into some significant pitfalls.
1) Group work is really hard for students that don’t already have excellent communication and personality skills. (I hate the stereotype, but I’ve also found that teenage gamers are especially challenged by this part!) For a giant group, the importance of this is manifold. The students who took on management-like duties (producers) in this big group were often overwhelmed for a couple reasons:
1a) They didn’t understand the needs of their specialized teams because they had few skills in those areas themselves. I underestimated how important it was for management to have technical experience—both in order to provide guidance, help connect them to knowledgeable team members, and to just relate to the challenge.
1b) If a producer loses credibility among their team, the team dynamic can devolve really quickly into either the producer being ignored or giving orders and asserting authority. The teacher, the only real authority, has to be really hands-on and improvise in order to keep students focused on the project and not on politics. I was unprepared for how much behavior management I had to do, and because I was overwhelmed with other classes it became a bigger issue than it should have.
2) I offered the opportunity to work individually if students wished, thinking that students who did so would see all the group enthusiasm and be drawn into the project. In practice, individual projects kind of became a doghouse for students who were fed up with the project for one reason or another, and they felt somewhat entitled to label anyone still involved in it as foolish. Some of the group members felt like the independent developers were getting special treatment. Kind of the opposite dynamic than was intended.
3) Skills levels vary really widely. At the zero-official-experience level, some will have more general computing skills than others, not to mention those students who have already dabbled with modding or whatever. Will you be teaching only one grade or several? The wider the spread, the trickier I find group work gets. More experienced students feel dragged down by others and are inclined to “just do it” or tell others what to do without explanation, while less experienced students can feel bad about themselves, become demotivated, and very quickly stop asking for help and direction. Even if they keep coming to class, I see a lot of students with fewer skills try to blend into the background or check out mentally. This can be solved by being there for them as the teacher, and giving them plenty of attention, but just keep in mind that it’s a ton of work to do so! I didn’t have enough time to dedicate to a number of students who needed it last semester, and I feel like I let them down.
4) Who gets to do the game design? Is it all by voting or are there designers? The first time I did a big group project there was a lot of resentment among specialists who felt like they didn’t get to provide much input into the design or the aesthetic, and therefore were just worker bees. The second time, with the same group, I opened up the decision-making process, but then who got to make final decisions, and which decisions had already been made, became unclear and students were often confused or gave up. Skill level variability played into this, too. Who knew how challenging the idea of an “isometric 2D perspective” would be to comprehend?
5) Do you have any thoughts about how projects are going to come together, practically? We used version control, and even with some very simple to use scripts for committing assets, it was a big pain point to get students to use it well. I imagine that version control is beyond the scope of a high school class, so as a high school teacher are you going to have some shared cloud storage and then keep someone / yourself responsible for managing it? Unity Teams is pretty good, but the free version is limited, and it locks you into an engine.
I haven’t thought too long or hard about solutions to these problems yet, since I’m busy revising other courses for the fall. However… my preliminary thoughts are these.
1) I’m going to experiment with breaking the class up into smaller groups and possibly using competition incentives to motivate students. One really big thing I noticed was that more programmers != more programming. I had a contingent of multiple programmers, including a couple with notable skills, but even with version control I think the sum of the successful engineering done in the class was less than could have been done by one of them alone.
2) The high school / college student demo is not so different as you might imagine, but I imagine high school teachers have one big thing that I could have used a lot more of: class time. It was teeth-pulling trying to motivate students when they weren’t physically in class; and, at just over 3 hours per week of that, motivation ran out several times. More class time will probably ease some of the communication burden that it turned out Discord, Google Docs, and Trello just couldn’t compensate for.
3) I have two game dev curricula right now that I consider successful. Conspicuously, these are the two that are designed around individual, iterative projects. “Fail faster” is absolutely true, but there’s got to be a real carrot in there somewhere or students bail and sour. If a student can bring their own project from concept to completion, even if it wasn’t exactly what they dreamed of, that is the ultimate carrot. In group work with inexperienced, socially immature students, that isn’t going to happen. (Well, maybe it will – and I’ll beg to learn how you did it!)
4) I want to research whether teamwork skills can be trained and graded beforehand in a way that isn’t just corny roleplaying or “sink or swim.” Like, is there a way for students to practice being good teammates without also having the extra responsibility of making a game for a grade? How do you train and measure those skills besides saying variations of “don’t be a dick”? One semester I had students submit a description of the work that their teammates did. The idea was to identify whether everyone was contributing in a positive way, but clannishness and group politics made the info unreliable. It’s easier to grade a student on whether their character controller works than it is if they’re difficult to work with.
P.S: The conversation continued on Discord. Join us and read another member’s thorough reply to these thoughts on his blog at Chase Tail Games.
