Prior to this class, I was starting to develop a sense of how to design games from the ground-up, from my independent study version of CS377G last quarter. However, my experience was still relatively limited – while I made a lot of projects, none of them were playtested to the same degree as the ones this quarter, none of them were of the same scale, and they were all done either by myself or with a small team. Although I had thought about games critically as I played them to some extent, the ones that I focused on the most tended to be competitive eSports titles, like Starcraft or League of Legends, where much of the design was already set in stone, and the decisions being made year after year tended to be smaller ones that focused on incremental balance.
In this class, I got to collaboratively think about design with four other people from the beginning, bounce ideas off each other, and build on one another’s work. Unlike most of my previous experiences, I was on equal footing with my co-designers, and there from the beginning of the design process. Seeing how much our initial ideas could change, while still retaining the core of what different people found compelling about them, was exciting. I got a better sense of how to advocate for my own ideas, and build on others.
This leads to the main lesson that stuck with me in this course: how to effectively communicate and collaborate on design work. Exercises like giving ‘start/stop/continue’s at the end of Project 1 helped reframe criticism as positive and productive, and the way that we explicitly set expectations – both for the projects and the group dynamics – was valuable. It also made it clear that it’s absolutely valid to reach out for help or opinions. In the past, particularly at work, I’ve been reticent about asking for help, afraid that I’ll be a burden or reveal that I’m not as competent. However, this experience has clearly demonstrated that that’s not a risk: people appreciate it when you reach out, and it makes the entire process much easier.
In terms of game-specific lessons, the amount that we playtested also really helped drive home some of the lessons about effective tutorialization. In particular, introducing tutorials only when the relevant mechanic was being introduced and avoiding pop-ups in favor of having players organically learn the material was especially valuable. Because we were able to playtest so often, we were able to iteratively build affordances in to the game – like characters flashing to indicate a choice, highlighted forward and back arrows fo navigation and colored text corresponding to different characters – that combined meant we didn’t have to have any explicit tutorialization. Every time someone was stuck, we just added another affordance, and by the final playtest players were finishing the game without any hints from us, and without any explicit tutorial.
Being able to not just learn the theoretical value of teaching like this, but also see it put into practice, helped concretize these concepts, and made it clear that an affordance which works for one person won’t necessarilly work for another: getting ideas across via multiple channels is very important.
One of my biggest challenges throughout the course (and, if I’m being honest, more generally) has always been scoping, and setting realistic expectations. At times I would find features I thought would be cool, set out to work on them, and then realize they were much larger than I’d imagined. At first, I just buckled down and tried to power through – in particular, the way I’d originally envisioned the map for project 2 was extremely ambitious, and was taking an enormous amount of time. Luckily, after talking about it with my team, we realized there was a much smaller version – just one city map, not detailed ones for every area – that would still get us 80% of the way to our original goal. Recognizing this, and giving permission to do something smaller, was a huge relief, and let me put my energy into more valuable pursuits.
I think this realization – that the end goal is to make a good game, not meet an arbitrary checklist, was hugely important. Coming from a lot of academic work, where there are clearly defined requirements not just for the final form of a project, but often also how you implement it, this was a very different mindset. I’ve found in the past as well, at internships, that I would give myself a lot more work than I needed to by sticking religiously to these initial plans, as one would for a homework assignment, instead of checking in with collaborators and revising it so that I could spend my time better, and get an overall better final product. For me, this was a huge point of growth that I’m excited to take forward into my future design projects. I think it will help me to feel like I’m doing more effective work, and avoid getting bogged down by unrealistic inital goals.
Post-graduation, I’m going to be working full-time with a team of designers, trying to inform their design decisions. Prior to this, I wasn’t confident that I could really understand the birds eye view of the game – the people I’m working with built the fundamental mechanics, whereas the decisions I help make are usually just how to use different levers to balance the game and the play experience. A lot of the language they used – things like environmental storytelling, or play spaces – was familiar, but I wasn’t really confident what it meant before this class.
I think, given this stronger background in the theory of game design, and my own experiences actually making fundamental choices about game mechanics from square one, I think I’ll feel more empowered to really engage in these discussions on even (or at least, closer to even) footing. I’m still, of course, excited to learn, but I think that I’ll be starting off a little further along.
