Final Reflection – Tianze

I took CS377G in the fall quarter, where I learned the fundamental theory of game design and developed the habit of “rapid prototyping, iterating again and again.” Then, in CS247G, I went through a kind of “spiral of understanding” that gave me a deeper grasp of this whole design practice.

First, I came to realize the potential of collective improvisation. Before, I figured it would be more efficient if everyone did their thinking independently first, and the meeting was just for putting those ideas to the test. But during our P1 design meeting, I caught a glimpse of some “group magic.” We started by testing a prototype I had made—it wasn’t very fun. So we began improvising rules on the fly: everyone gets some shrimp tokens, and then… and then what do we do? We freely made up rules just to keep this improvised game going. Whenever a rule got too complicated or wasn’t fun, everyone could feel it immediately, and we’d quickly change direction. Before long, we had a genuinely fun prototype. Even though the final version’s rules differed a lot from the original, the core fun stayed consistent throughout. This experience made me realize that a game isn’t just about “designing a set of rules”; fun is an equally crucial part of it. My earlier “solo design” approach placed too much weight on the internal consistency of the system while neglecting fun, and fun emerges far more easily under collective, improvisational conditions.

Picture: P1 (The Shrimp Game) – I created this concept map

On top of that, I broke through my self-imposed limitations and became a “technical person.” Before signing up for this class, I’d set myself the goal of “learning Unity.” But after we split into groups for P2, my work circled back to gameplay and narrative design. I accepted this role, telling myself, “Since time is limited, I’ll just do what I’m good at,” and “learning Unity takes too much time, I’ll get to it later.” When building prototypes, I also reached for the more familiar HTML instead of trying Unity. But with my teammates’ encouragement, I started using Unity in the final two weeks. As an “AI native programmer,” I didn’t start from a tutorial. Instead, I tried to optimize my AI workflow, constantly pushing Codex with the question of whether things could be “even more automated.” Although Codex initially lied to me, claiming that “you’ll have to do all the GUI work yourself,” after combining its help with the developer community’s latest practices, I achieved “full automation” using tools like MCP. In the end, I completed most of the programming work with almost no GUI operation at all. This experience made me feel really proud. That said, I should also remember to “keep my taste, use AI wisely.” At the very least, after this experience, learning Unity doesn’t scare me nearly as much. Maybe one day I’ll explore even more on the technical side!

Picture: P2 (Otowa Blues) – I developed this interface in Unity

Becoming a game designer has always been my dream, but it wasn’t until this year in this class that I truly threw myself into game design, and loved it this much. After I graduate, I plan to keep developing indie games. I’ll make full use of what I learned in this course, and I look forward to having you play my games. I want to thank Christina, Butch, Lucas, Ryan, the TA team, my teammates, every playtester, and every classmate who designed such wonderful games. This course gave me so much—a designer’s perspective, theoretical lenses, a practice-oriented mindset… If I had to sum it up in a single sentence, it would be this: Want to make games? Just do it!