As of late Monday evening, everything was going according to plan in week 12 (of 12) of my game design course. I currently (and typically) teach two sections of Game Design Fundamentals online at the Berklee College of Music each quarter, where students interested in game development learn about the history and current landscape of games, study a number of design principles, and workshop their own ideas into a fleshed out Game Design Document.
We do weekly lectures, often with sessions of a particular game, highlighting player experience goals, design, production and aesthetic considerations that went into it. We also do lots of demos with accessible game engines, and plenty of tutorial content. Since Unity is the engine I’ve made almost all of my own (small) games in since 2009-2010, the engine is usually a big part of this, and features heavily in the list of suggested resources I leave students with each quarter.
That list includes specific Unity Learning courses that I’ve taken myself and found especially helpful, Unity tools that I personally use and love (like Yarn Spinner, which is currently Unity-based but Godot and Unreal versions are in the works), and favorite tutorials for making small games or features from various genres. I have years and years of collecting these resources and recommend checking them all out to my students, so they have viable next steps after the class is done.
This is not to say Unity is the only tool I usually shout out (I do a lot of live sessions with the likes of Bitsy, Narrat, etc), but it features heavily. Since the announcement Tuesday, I’ve been frantically pruning that list and trying to figure out what I’m going to tell my students before our short time is up (and tearing my hair out revising curriculum for next quarter, which starts next week).
With the many pain points and wild potential pitfalls brought up by developers this week, I don’t feel like I can recommend the engine to my students in good conscience. These are brand new developers in most cases, making their first interactive works (many are already accomplished sound designers, composers, and musicians), and I don’t want to send them down a doomed path, particularly as the best thing about Unity—its community—seems poised to dry up. Developers are furious for good reason, and it’s reasonable to expect more folks to ride over to greener pastures at Unreal and Godot. I’m going to obviously need to transfer my own skills to a new engine so I can effectively teach my students and guide them on their first steps.
I don’t want this blog to sound like I think the debacle is about me. Yes, I’m angry that I sunk so many years into learning the “wrong” engine (and have a mostly-finished game and a bunch of prototypes sitting there in my Unity hub, begging to be completed by January 1st or maybe never touched again), but I’m obviously much more upset for mid-tier indies that are years into a project, who stand to lose tons of money on an unfair metric or tons of money AND time and progress, having to restart development in a new engine.
I feel sick for every team having to make brutally hard choices about what to do right now, especially in a bleak pitching market and general time of tumult for the industry at large. I’m very scared about these factors contributing to the possibility of an “Indie Winter” that developer Johnneman Nordhagen referred to in a Cohost post this week.
If anything, my current students are lucky for this timing—they won’t sink years of their lives into something that will screw them over. At least, not in this very particular case. For students further along in development and everyone else…apparently enshittification, as we are increasingly seeing, can come to just about anything.
All I can reasonably hope for at the moment is that the new resources I pull together—including smaller tools like the ones listed in Natalie Lawhead’s blog this week—can offer my students more fertile ground to start their own design practice. And that I don’t pick “wrong” again.