(I have lightly edited this post for clarity after hearing some confusion about it.)
I have a large and fun group of students in CS490 Software Production Studio this semester. The past two years, I've been experimenting with running the course in a non-community-engaged manner, allowing students to form small teams and create their own passion projects. This year, we're back to working with Minnetrista, who always make for a great collaboration.
We spent the first three weeks on preproduction, trying to figure out what it is we really want to make. The team decided on a multiplayer collaborative game that simulates the cooking process. It resembles Canning Heroes, which my team made in 2019, but we're taking it in a different direction. Rather than have the game played on one, large, interactive tabletop, this year's project will be played on multiple networked tablets. Each tablet will represent a different workstation that would be involved in canning; the current design calls for a prep station, a filling station, and cooking and jar sanitizing.
The students are really excited, and they bring a lot of energy to the process. However, they are all still pretty green. Few of the programmers have ever built a game at all; I think only three have taken my game programming elective, and one of them was 1.5 years ago with no game development since. Many of the programmers are just coming out of CS222, so yes, they can program, but they lack experience.
My purpose in writing today is to share some of the complications that I've had to deal with in helping the team get moving forward. None of this is to complain: I love working with teams like this. These are, in many ways, necessary problems that a team has to face before they can move forward. To put it another way, what I'm describing here is what I really do in the classroom with a single student team, which activities I could not possibly do when mentoring multiple game development teams as I have done the last two years.
The students were excited to get involved in designing the gameplay, and maybe a third of the team has taken my game design class. A lot of their work is still undisciplined and ad hoc, but I should have expected that: taking one class on a topic is only enough to get started, and it's a long climb toward expertise. Curiously, much of the prototyping work was done by people who had not taken the game design class, so I had to try to feed them a few fundamentals of player-centered philosophy as they worked. I wanted to be able to sit with them and work through the problems, but I was also pulled in many directions, so the design process was not as smooth as I had hoped.
To get an application running on a tablet through Godot requires working through multiple steps of setup and configuration. I've spent at least three hours working alongside the students who are working on this. I take no great joy in devops, but I am happy to help. It takes me much less time than it takes them, but it takes time, and that's time I'm not mentoring another aspect.
We're doing a multiplayer game, and so we really need to get the right version of the app running on multiple tablets simultaneously. I ended up switching from mentoring to a steering role to help the students with configuring a machine to be able to run a custom batch script that builds and deploys the app to all USB-connected devices. I feel a bit badly about aggressively steering, but it also felt like the best approach to scaffold the rest of the project.
A student came up with a UX flow that a staff member could follow to get all the devices connected. The first draft was well-intentioned but more complex than was necessary for the task at hand. I was able to give some feedback, but I wish I had given more guidance about how constrained a problem we were really trying to solve. The original testing protocol for the UX flow contained errors that we fixed before deploying it, and it was a good reminder to me to talk to them about the importance of validation. Every step is hard. If we had moved forward with the original protocol, it would have been worse than doing nothing, because we would have built up knowledge based on contradictions, from which we could not possibly deduce the truth. I would have liked to sit with the team working on this and mentored through rather than do it transactionally through Slack or Google Docs. I have to make snap judgments about where to spend my time. The squeaky wheel gets attention, but that's not always the where I can help most efficiently.
Most of the team has never seen Godot Engine before, so of course they are not using it prudently. Those with some experience are providing good guidance, taking into account the point made above, that just one course is only enough to get your toes wet. The code is not being held up to the standards that these students are supposed to know from CS222 or their capstone SE course. It can be hard to know what something like "SRP" means in the context of a new game engine, but I also don't see them asking the question. I am thinking about how to advise them so that they remember that refactoring is a crucial part of the process, not just a value-add. One of the most peculiar things I've seen is people spending time implementing gameplay that does not comply with the design we specified. Why they have done the latter is still a puzzle to me that I hope will be clarified in Friday's retrospective. Again, if I sidled up next to them every session and mobbed together, I am sure I could have taught them some great Godot Engine shortcuts and ways to think about code quality... but there's just one of me.
I provided a starter methodology and assigned it as reading. The team agreed to follow it. Two weeks later, it was clear that many had not read it at all, and some did not even know where it was. As I recall, nobody posed any questions about it, but truly, it should have raised some powerful questions, like, "What exactly is a technical environment with automated tests, configuration management, and frequent integration?" That is a good question.
We have talented artists in the room, but they are not in the flow. Some did not read the methodology. I still get the sense that some think the methodology is for somebody else, but I'm not completely sure about that. We're halfway through our second two-week production sprint, but we don't yet have a pipeline for how art assets are created and integrated, no non-CS-students can download or run the game, and despite my reminding them several times, we're not seeing organic formation of cross-functional teams: the art majors are sitting as if they are a separate department. I need to get in with the whole team and demonstrate what this should look like since they are collectively not getting it by imperative nor by methodology nor by contemplation.
I find myself wishing I had any veterans. I don't have anybody in the studio who has done anything like this before, so all the words of wisdom come from "the professor." Even if they understood what I was saying and didn't tune me out, there's not enough of my time to be in all the places I want to be. If some of the people in the studio had more experience building games, they could take a leadership role. I'm hoping that some of these students will stick around and help lead future endeavors. I think they all have the capacity to do this once they have more experience. Right now, they either don't know how or are afraid to hold each other accountable to our standards.
The first sprint is always rocky. The team had taken what I considered a conservative commitment for the first sprint, and they failed at it. That's fine. They took a more ambitious commitment for this sprint. However, I think they still don't see what it means to work together nor to do quality work. This is my challenge: how do I show them something better? It will be interesting to see on Friday, during our retrospective meeting, if they can become aware of how they are continuing to violate the methodology and the real costs that has.
When I was mentoring three or five teams at a time, the best I could do is hand them some rules and wait to hear about problems. However, those were small teams, and they could get away with ad hoc collaborations. This is a team of thirteen, and a team that size needs rules. I gave them the rules, but they're not following them. They are on the road to failing this sprint, which is fine but only if they understand why. It's that last piece that has me worried. They might see the semester as having eight more weeks. I see the project as already being half over with nothing to show for it.
Something I haven't written about yet here is that my department recently announced a new curriculum model. Rather than having one path through the major, there will be five concentrations, one of which is Game Design and Development. I will have more to say about that here soon, but in the meantime, I'll point out that a structured curriculum around gamedev is something I've wanted for years. Students will have more opportunities to learn these strategies for collaboration, for design, for testing, and for development, and I am hopeful that we'll see more and higher quality projects in the coming years.
No comments:
Post a Comment