Dennis CS377G Reflection

Before CS377 had begun, I had always had an inkling of an idea that the design principles that I had learned in classes such as CS147 were not so different from the skills and techniques that could be used to make video games, but it was always just a small inkling.

Additionally, I never thought formally about the design elements of a game, and thought of the creative process behind a game as something more magical than process-oriented. Whenever I wanted to make a game before the class, I would put myself through a long period of building out system upon system in code to try to realize a vague vision that I had sketched out in my notebook.

I also started the course a little weary of the design philosophy preached throughout Stanford; it seemed like while people paid a lot of lip service to understanding users and their needs, HCI classes seemed to create a lot of work for students for little payoff.

I was a little suspicious of the moniker “Serious Games”, because I was concerned that this would be a class that looked at play and games as simply tools to achieve a goal, and not an art in an of themselves.

The Students

In the class, I was able to interact with people of many different skillsets and interests; the class was diverse, even more diverse than most HCI classes. Something about the class drew a particularly enthusiastic group of people: perhaps it was the fact that it was especially hidden from the broader Stanford community, or perhaps it was the premise. But through the other students, I learned:

• How to give and receive feedback, criticism, and praise, especially on creative projects, and how to use this information to push the envelope on my games. Because we were working together on our games so often, I had the chance to hear a lot of feedback from other students from a designer to designer perspective, and I quickly learned to parse their insights from their personal preferences. I think when feedback is more scarce in other classes, it can be easier to take things more personally or defensively. I definitely feel more comfortable with seeking out feedback.
• How to be a good playtester, and a good playtestee, by understanding when to listen, and when to give more information. This was created by a cycle of showing people my games, understanding more about the playtester-playtestee relationship, and then attempting to reflect it when other people asked me to playtest their games. I think that now as a playtestee, I try much harder to not be interjecting my thoughts with suggestions on how to make things better, but instead voice as many of my emotions as possible.
• How to combine people’s talents in a complementary way, and how to work in a team and turn a jumbled mess of creativity and desires into a (somewhat) functional product. More than any other kind of project, creating a game seems to create a lot of investment from the creators, so it was important to be able to understand what people in my groups cared the most about, and protect it on their behalf. Games don’t get created in a vacuum, and I think this was one of the most valuable things I learned.

The Teacher

Christina was a great teacher because she understood how to balance giving us direction versus giving us freedom. Her course design encouraged students to experiment, fail, and learn, while also making sure we had all the tools needed.

A big part of this preparation was through the readings, sketchnotes, and responses. Having these be just a simple yes/no grading scheme allowed us to focus on the projects, while also making sure that we engaged with the incredibly interesting readings; I’m walking away from this class with an entire repository of readings that I will personally be passing on to anyone who has any interest in game design.

The experimentation-fail-learn cycle through the three assignments perfectly encapsulated why I am still in school: it pushed me to create something interesting within constraints, while also assuring me that it would be okay if it wasn’t perfect. Having three assignments that were each about two weeks seemed to strike very close to the right balance, but I did feel like the work curve was very heavy on week 2. I think Christina’s advice that you could only use the first third of your time faffing around on a project was an extremely helpful heuristic that will guide me on all future projects. The course gave me an outline for how to do my own experimentation with projects in the future.

I really enjoyed the teaching in this class, and I hope it can be virally spread as a model for HCI-teaching throughout the university.

The Games

And of course, an overview of the course wouldn’t be complete without talking about the games that I made.

• My P1 game was a card game about learning historical figures. This one was really hard for us because we stuck with our original idea for too long; once I became comfortable throwing out our core rules to pursue a completely different team-battling idea, I learned that your first idea is definitely not your best idea. I think in the future, I will always design my games planning to be okay with throwing things out.
• My P2 game started off as an Inform game about time travel, and became a Twine game about time travel. I stubbornly stuck with Inform, although it was an engine that made little to no sense to me. I should have realized that a game isn’t about the tools you used, it’s about the experience you created. I felt a degree of pride over using Inform, but I should have realized it would have been much sooner to get things done in Twine. I am going to focus less on doing things the “right” way, and focus more on just getting them done.
• My P3 game was a project where we created a card game focused on diversity and cliques. Well, perhaps focused isn’t the right word, because what I learned from this project was that a game needs a core. For a while, we had strayed from our original themes of diversity and cliques, and moved towards a more milquetoast game about matching colors that used some of the mechanics developed earlier. However, because those mechanics had a message about diversity at their core, they ended up feeling hollow. I think it’s okay to decide that your game needs a different thing at its core, but not okay to have a game without one entirely.
• My P4 game was a project where I joined an already existing group that was working on a art-learning board game. I wanted to take a lot of the lessons that I learned while working on P1, and apply them here. However, I should have been more mindful that experience is invaluable; I didn’t do a good job of learning from what my teammates had done in P1, which used a lot of time. Going forward, I’ll make sure to learn everything I can from others, before blindly making things.

All in all, I’m incredibly grateful that I had the opportunity to participate in such an amazing class in my penultimate quarter at Stanford.