It was an interesting experience teaching CS490 Software Development Studio this past semester. This was the second year of my experiment in letting students pursue their passion projects. The first year was intended as a one-off, but with the pandemic, it seemed a bad time to try to bring back the element of community engagement. However, next year (Spring 2022), we are already approved and funded to do another community-engaged project with Minnetrista, and I'm really looking forward to that. It means, though, that any breadcrumbs I leave for myself here may not be followed for some time.
We started the semester by having each student participate in two rounds of pitches, we spent some time building prototypes from a subset of these, and by the middle of February had set on three projects to pursue. All three were completed and published to itch.io:
The students followed the distributed methodology that I put together early in the semester. The only major edit I can remember from the semester was removing Trello as an option, since it didn't support the rest of the process as clearly as HacknPlan. At the end of each iteration, each student had to submit a statement that they had met the nine-hours-per-week labor commitment and that they had followed the methodology to the best of their understanding and ability. I thought about having them keep labor logs, as I did in game design last semester, but I decided to go with the more lightweight periodic self-reports instead. This kind of self-reporting is always open to dishonesty, given that grades were connected, but I did not have any sense of this as an endemic problem during the semester. Most students reported that they met all the goals all the time, although some admitted to cases where they were not on point.
Last Spring, the teams started up in person and then had to move online, and I felt like we had a good working relationship throughout. This semester, we technically had a room that we could use, but that would have been extremely awkward for presentations, conversations, and collaboration. We ended up moving almost everything online, including pitches, work days, planning meetings, and presentations. Given the constraints of the alternative, it was better in all ways. We only met face-to-face a few times during the semester for whole studio meetings.
A result of this is that I felt very much "outside" the group, and there was not a real sense of community between the teams. The most surprising way that this manifested was on Slack. Originally, different teams used different communication channels, but this was hard for me to manage and prevented people from reaching out for help across teams. I brought everyone together into one Slack instance, but people, by and large, ended up staying in their team's channels anyway. I used the #general channel to share thoughts, ideas, reminders, and the like, but I am not sure that anyone else ever really used it for general studio chat. Put another way, there was no general studio chat. A few people posted links on #random, but even that was really quiet, devoid of any good memes. It makes me wonder, if I were to run a course this way again, should more effort be spent on building up a sense of commonality, or should more effort be spent helping teams become self-sufficient and independent.
Early in the semester, I required that each team come up with a vision statement, explaining to the students that the main value of this is to be able to say "no" to good ideas. The rest of the semester was essentially just a series of sprints, then, in terms of what students were required to do. I advised the teams toward good practices of early playtesting and setting a feature freeze date, but I did not require either of these. Conversations with the teams, including our whole-studio semester retrospective meeting, make me wonder if it would be better to frontload some deadlines around these. For example, part of the methodology could give a date by which the first playtesting is expected, so that teams can move toward this.
Now, in some ways, I see this as inherently dysfunctional. I explained to all the teams—more than once—that "done" meant tested, and so for gameplay issues, "done" meant playtested. I talked about the relative merits of internal vs external playtesting, but I got a real sense that this was falling on deaf ears. When mentoring one, large team, I am active in the regular maintenance of the task board and discussion of "done", and the students get this; without this, I think the teams fell into a conventional undergraduate perspective about it, that "done" meant something much less rigorous. It is possible, then, that this another case where one method might work well for whole-studio projects and another one for small-team projects.
Along with vision statement articulation, external playtesting, and feature freeze dates, another item I have contemplated including is a style guide. Many of my teams have gone without these, but I have been inspired most recently by Ben Humphrey's talks and blog to think about the UX problems my students face. When there is one team, with good fortune, we have an artist who sets up a palette, fonts, and visual style, but even that is not guaranteed. Still, I think students understand that releasing a game using the engine's default styles is a faux pas. I do not want to push every team toward design bibles, but I think there might be some value in at least articulating a basic style guide early in the process.
I am proud of the work these students did, and honestly, their reliability and hard work enabled me to redirect efforts toward the unexpected picking up of CS431 these past few weeks. I hope they do not feel abandoned, but I consider myself fortunate that I had a CS490 group so consistent that I could trust them to wrap things up on their own.
In closing, I would like to share a final thought about the semester. Due to scheduling constraints and all the chaos of the pandemic, the CS490 class this semester was overloaded with technical people, mostly CS majors. I also had some of the most motivated and talented technical teams I have ever seen, and I actually think that's a separate issue from the first. That is, I had more technical people, but I also had better technical people. It was great to see these students deploy lifetime learning skills to teach themselves how to move forward on these different projects. The only downer for me, then, is that I didn't have these people together to work on a community-engaged project! I cannot help but think of what we could have accomplished if we had been able to all be together, in RB368, with coffee and donuts, meeting up for game nights, working with a community partner.
No comments:
Post a Comment