Essay Games Blog

Thoughts from a Solo Dev Studio

Back to School: Reflections

Selfie at the Pratt Game Arts booth at PlayNYC

As I noted in the Essay Games newsletter, I have a new full-time appointment at Pratt Institute for the 2025-26 academic year, and the Fall semester just got underway last week. It’s been amazing to feel so welcome by former students, celebrated by colleagues, and generally hit the ground running. The start of the semester is always a bit of a tense time since it seems like everyone comes back from their summer vacations and is ready for work. Maybe not the students just yet, but certainly faculty and staff and other art/games people that I’ve been in touch with in the past couple of weeks.

I always like the start of Fall. Without sounding too hokey, it always feels like a productive and inspiring time of the year. Maybe this feeling has intensified as I’ve gotten better at really taking time off during the summer. But regardless, I always find these autumnal months to be a “hunkering down” moment to get ideas and development moving. Some of that is being taken over by the start of the semester, undoubtedly. But even with the new job demands, I’ve been chipping away at project ideas and even started a new project file for a prototype(!).

Notes and news on that front will come later; for now, I wanted to reflect on returning to teaching full-time and some of the early conversations I’ve had with students.

Getting my office set up at Pratt.

For context, my appointment at Pratt is basically overseeing the programming pillar of the Game Arts program. So I’m teaching two sections of Game Programming 3, a course that delves into more complex C# scenarios, guiding students to build systems (and mechanics) that are more modular, flexible, dynamic, and polymorphic. One of the main overarching goals is to introduce and reinforce the Observer Pattern, a programming technique widely used for generating more agnostic code that uses events and listeners. In some ways, getting students to unlearn the hard-coded practices they’ve come to expect and rely on is the biggest hurdle in teaching this content/concept. I try to reiterate that the way they have been using more direct and static approaches to programming is absolutely fine, but that if they want to create more complex game mechanics, they need to make more complex (and flexible) code.

The last time I taught this class, I think there were several aha! moments where the students understood why you’d want to employ events, delegates, and customizable classes. For those that aren’t programming folks (and or those that are), using this system can not only create really efficient systems, but also can create dynamic scaffolding for a project that can “run” without all the necessary content to be exactly in place. Coding in this way can also allow for easily “extendable” code―or code that can be added onto easily without requiring huge rewrites or refactoring. So I hope this also happens with the cohorts I’m teaching this semester.

The other class I’m teaching is a Game Design Studio introductory course, one of the first theory/concept courses the Game Arts students take in the curriculum. It’s maybe one of my favorite classes I’ve taught. Mostly because, ironically, it doesn’t teach any software or programming. The projects in that class are all paper/pen prototypes or made with physical materials. We talk more about concept, design theory, and how to situate their game within a larger game/art context. We also play A LOT of games over the course of the semester, and it gives me a chance to really connect with the students early on in their journey in the program. We’ve already played a couple of games together, and it’s been really fun seeing how they respond and engage critically with design.

A lot of this class revolves around developing student vocabulary around games and to give them some language to describe what their attempting to do with their own designs. So we’re starting that process with (IMHO, the best of the best) The Game Design Workshop by Tracey Fullerton and building on her “considerations” for designing game structures. I love the way Fullerton outlines these core design ideas because they 1) immediately spark ideas in students (and me) and 2) are offered with really nice/neat examples that encourage critical thinking and discussion. Approaching games as a formal medium with materialist concerns makes way for some of the more heady arguments presented in the class later on in the semester, and I think it’s always important to start with these types of texts to lay a solid critical foundation for studying and making games (hopefully, the students feel the same way).

The Game Design Workshop by Tracy Fullerton

Typically, in all of my classes, I tend to skim over the official policy legalese required of all syllabi. Not because I don’t think this information is valuable, but mostly because the students are already familiar with these policies. I do make a point to highlight particular policies relating to learning accommodation, attendance, and zero-tolerance of hateful speech and outward displays of bigoted behavior (an issue that thankfully does not come up often, but has occurred at previous institutions). However, this year I also took a moment to address the evolving (and recently updated) policy on plagiarism.

Between both classes (and the two sections of programming) I spent extra time during our introductory classes to hold a discussion about appropriate uses of AI for class work. This discussion is a bit more pertinent for the coding classes, since 1) students are already using various LLMs to generate code and 2) ChatGPT and the like are more widely “accepted” within professional coding/tech environments (for example). Even if ChatGPT isn’t being directly used in professional settings, more and more job listings are including “experience with prompting” as part of calls for applications―a bullet point that students are acutely aware of.

I didn’t know what to expect when I opened up this discussion to students, but I wanted to hear directly from them and take a general temperature of their feelings on using AI. I was a bit surprised when students in every section immediately voiced discomfort using the tools and a preference for not touching AI in any capacity in the creation of their work. Many students (across all classes) said that they’ve never actively used ChatGPT or Copilot and have no intention of ever opting into those platforms. When I asked students for the basis of their resistance, many cited environmental concerns and the morally gray areas AI platforms are ill-equipped to handle (and often just neglect altogether). Other students referenced the poor quality of the output, saying that when they used it, they got spotty results that needed so much modification that editing took longer than just making things from scratch.

One of the Game Arts arcade cabinets is getting… repurposed.

In one class, a student presented an argument for using AI tools as a sounding board for idea generation and fleshing out concepts. They said that they’ve never used the tools for “end product” or results, but had used it to “talk out ideas and see if they made sense.” I understood how this could be helpful for some students, especially for students who struggle to communicate their ideas to peers. But I offered that I would be more than happy to be that kind of sounding board and that the classroom environment is an ideal location to workshop ideas with other people (especially because those peers will eventually play the finished work).

In both of my programming classes, I played Devil’s Advocate and asked my students if using AI tools to help search for API syntax was acceptable, or if students would ever use AI to write pseudo-code to flesh out structures. In both instances, students contended that they already get AI responses from searching on Google (to mixed results), and that pseudo-code could be helpful in some cases, but that they’d prefer to go directly to the scripting library to look at use cases. In one class, a student rebuffed my provocation, saying that using ChatGPT would deny them the opportunity to actually learn something, which was kind of the whole point of coming to school (to which I agreed wholeheartedly).

So in all classes, we agreed together that AI could be used for research purposes, but that it shouldn’t be used for any production-facing work. Furthermore, any use of LLMs for generating research that led directly to school work should be explicitly cited when appropriate. Lastly, I contended that I actually have no domain to restrict the use of these tools and that we are collectively operating on an honor system. I thought that this last bit was especially important for students I hadn’t taught before to show them that I fundamentally want to trust them and believe in their ability to produce meaningful work without the aid of AI.

With this discussion concluded, I felt very reassured that students are facing some of the incredible challenges of their generation with loads of critical reflection, well-informed perspectives, and thoughtful candor. That being said, I’m aware that students willing to express their opinions on the matter are self-selecting. The students at Pratt are also creative individuals predisposed (to a certain extent) to being more “humanist” than “techie”―even within an art and technology program. So I hesitate to take the small sample size of my classrooms and apply it unilaterally to “today’s youth.” But it did make me very hopeful.

Bringing my kiddos to school this morning.

I can’t wait to share more pedagogy and reflections from the school year. And hopefully, as things settle into a rhythm, I’ll also have time to keep posting about games I’m playing and work I’m developing. I hope all you professors, teachers, educational staff, and students out there are having a great start to the school year.

Leave a Reply

Your email address will not be published. Required fields are marked *