Showing posts with label course notes. Show all posts
Showing posts with label course notes. Show all posts

Thursday, January 24, 2019

Spring 2019 teaching memo

For the Spring 2019 semester at NYU Game Center, I'll be teaching three courses:

GAME STUDIO 2.

This is a required core class for all first year graduate students in our MFA program. It's basically just about spending more time making games in groups. Hopefully these practice projects prepare them better for the thesis process in their second year!

I usually teach more undergraduate students than graduate students, so it'll be fun to adapt my teaching style to this older demographic. It's also a huge class, with more than 30 students; we usually cap most Game Center classes to 16 students because we have such a hands-on, one-on-one teaching approach, but here it's important for the whole cohort to get to know each other.

It's going to be a big challenge to scale my attention to a class that's basically double the average size, and I think I'm going to have to tweak a lot of my methods. We'll see what happens.


LEVEL DESIGN STUDIO.

This will be the second time I teach the level design class, and the main lessons will be conducted in Unreal Engine 4 again. (Most of our other classes are usually taught in Unity, but it's important to mix learning contexts and avoid monocultures.)

This year I'm planning three big changes:

Thursday, September 20, 2018

Fall 2018, teaching game development memo

Sorry I haven't posted lately, we've been pretty busy here at NYU Game Center with the start of the new semester. We're also currently in the middle of some curriculum renovation for our game design programs.

First, we're increasingly adopting JetBrains Rider as our code editor IDE of choice. It is free for students, common in commercial studios, and it's supposedly even used by the Unity CTO himself. While I find Rider to be somewhat annoying in its code style suggestions, its Unity-specific benefits seem to justify it as a teaching tool. We're also teaching source control with Rider's built-in Git support, instead of using a dedicated tool like SourceTree or GitKraken. (If this semester is a disaster though, I might go crawling back to VS Code and GitKraken.)

Second, we're starting to teach new game genres beyond mainstays like platformers. For instance, our MFA studio class now begins with a Fungus-powered visual novel project instead of a traditional platformer. This is partly a reflection of where contemporary game culture is at, where visual novels are perhaps more popular and relevant than platformers today -- but also a visual novel framing helps students focus on different development skills, like narrative design and pacing.

Third, we're gradually moving towards more of a "core studio" design school model, where every 3rd year student will be required to take core studio classes about making self-directed projects. Previously, undergraduate students would optionally enroll in these project studios, but we found that many of these students would opt out in favor of other electives -- and then they would feel unprepared to take on their capstone project in their 4th year. The goal is to normalize "bigger projects" for them. It's also a good opportunity for them to bond with the rest of the students in their class year.

As for my personal teaching load, I'm looking to debut a new class next semester about Let's Plays / game streaming culture. Game streamers are some of the most popular and visible figures in game culture, or even the larger internet as a whole, but I find that most of game academia doesn't really engage with it. It's partly a generation gap thing, where lots of middle-aged and elder millennial faculty (like me) didn't grow up with streaming and still view it as somewhat of an aberration / stain on discourse. However, there's no question that no one reads game critic blogs anymore (RIP, Radiator Blog!) and YouTube and Twitch are driving the big cultural conversations today.

As a discipline that seeks to engage with public game culture, we have an obligation to figure out how to analyze and teach this subject! So far, I'm still figuring out my course design, but I know I want to challenge students to become live game streamers themselves as part of their final project. I'll also be leaning heavily on T. L. Taylor's imminent book "Watch Me Play: Twitch and the Rise of Game Live Streaming" for most of the readings. Maybe next year I'll be able to report back on how the course goes.

Friday, March 30, 2018

GDC 2018: How To Light A Level, slides and transcript


This post is aimed at beginner / intermediate designers. It's a summary of the talk I gave at the GDC 2018 Level Design Workshop with David Shaver (Naughty Dog) for the "Invisible Intuition" double-feature session.

David's slides on blockmesh / layout are here (PDF) with case studies from The Last of Us / Uncharted. You can also get my full slide deck PDF here, and my speaker notes PDF here... but I don't know when GDC will upload the talk to YouTube, sorry.


A very brief and simple history of light starts with the sun. Then let's not forget about fire, controlled burning in gas lamps, incandescent light bulbs with a filament... and these days, there’s a stronger focus on more energy-efficient fluorescent lights, and LED lighting is also becoming more common.

It’s tempting to think of this as a story about technology and progress and older light sources becoming obsolete... but the light bulb did not make the sun obsolete, and the LED does not make fire obsolete! We still use fire as a light source all the time -- in our birthday candles, in our campfires, in our romantic candle-lit dinners -- in fact, I hate those little fake flickering LED candles, because a real flame has a unique quality to it, you know?

Fire hasn’t disappeared from the world, but rather our culture around fire has changed. That is, fire used to be a common and practical tasklight in Shakespeare's time, but now it feels more like special decoration for a special occasion. As a designer, you need to sensitize yourself to how light feels and conveys these ideas, because this is how you communicate those moods to the player.

Saturday, December 30, 2017

Postcards from Unreal, pt 2


My Unreal Tournament 4 deathmatch map "Pilsner" isn't really done. But as an exploratory project, I've fulfilled my goals to learn the basics of building 3D spaces in Unreal. I also reached the point where I needed an actual player base to confirm how the map plays, or at least tell me that it's total shit -- but it looks like I can't even get a denunciation when Unreal Tournament 4 seems to have a grand total of like 5 players!

I appreciate all the pre-configured art content and basic gameplay structures implemented in the game already, and it has been really helpful for me to learn how to configure my assets and work in Unreal projects -- but this experience has also convinced me that I shouldn't try to teach level design to my students with this half-finished basically-dead game.

It was also questionable how well this was going to run on our students' laptops, because half of them use Macbooks with small hard drives, and very little room for a Windows partition and an additional 50 GB for UT4 and the UT4 editor. This leads me to one of the original reasons why we stopped running a level design course: there are simply no popular first person multiplayer games with modern level editor suites that were easily deployable on our students' computers. (Given how long it takes to make games, computer labs are impractical.)

Wednesday, November 22, 2017

Postcards from Unreal


I'm building a Unreal Tournament 4 level in preparation for a level design studio class I'm teaching next year. I've been using Unity for a few years and now I feel very comfortable with using Unity for my projects, but I don't really have much experience with Unreal Engine 4. To try to learn how to use it, I thought I'd make a small UT deathmatch map.

Honestly, I think Unreal Tournament is a colossal over-designed mess of a game -- players can slide, wall run, dodge -- use 10 different weapons each with primary and secondary fire modes... I prefer the simplicity (and elegance?) of Quake 3 and its successors. Basically, Quake feels like soccer, while Unreal Tournament feels more like American football with 100 extra rules tacked on.

Nevertheless, it's important to be able to internalize how a game plays, even if you don't like it very much. I've tried to provide opportunities for sliding and wall running, and I've focused on what seems like the core three weapons in UT (Flak, Rocket, Shock) while attempting to channel the UT series' sci-fi urban industrial aesthetic.

Tuesday, January 31, 2017

Teaching, Spring 2017

This semester, I'm teaching three game development classes. Here's a bit about each one:
  • "Intermediate Game Development" at NYU Game Center. This is maybe the 10th time I'm teaching the class; it's a mix of Unity, source control, and 3D art. It's intended for 2nd / 3rd year undergrads in the undergraduate game design program, to give them enough awareness of different tools so they can start to focus their practice in future classes. Teaching it is always challenging... some students double-major in computer science and think the coding lessons are too easy, but for many other students, this is only the second code class they've ever taken. That said, the main point of this class is that code is certainly important, but making a video game involves much more than just code.
  • "Virtual Reality Studio" at NYU Game Center. This is the second time we're running the VR class, and it's kind of exciting because the department is starting to equip some state-of-the-art Vive workstations. Last year, the lack of motion controllers and room scale capability really limited a lot of project ideas, so hopefully we'll be able to accommodate the student demand better. What's challenging about teaching this semester is that there's a lot of new material: I have to figure out how to teach a Vive workflow AND I'm also trying to mix-up the theoretical readings more. Last year, we spent a lot of time reading Hamlet on the Holodeck, which was helpful, but also way too concerned with narratology for a class that doesn't focus on storytelling.
  • "Recursive Reality" at Parsons School of Design, Design and Technology. This is the fourth time I'm teaching this VR studio class at Parsons, which differs greatly from the focus at NYU -- here, at least half the students are interested in VR for film / installations. The equipment situation here is a bit less ideal, because no desktop VR HMD is compatible with the school's fleet of Mac workstations. So instead, we're focusing more on mobile VR like Cardboard and Gear, which actually works well for a lot of the students' design goals.

Friday, February 12, 2016

Oculus Rift DK2s kind of (secretly) do work on laptops (sometimes) and you can make VR stuff in Unity (maybe)

This is a rant + technical guide about how to get an Oculus Rift DK2 to work with Unity 5 so that you can make stuff with it. Maybe.

I'm teaching two virtual reality classes this semester, and I was dreading having to tell all my students that Oculus (in all their wisdom) has a public policy of no longer supporting Mac OSX, or any laptop, for the foreseeable future. Even now, when I tell my colleagues about this, they react with incredulous shock. With this single move, Oculus basically alienated the entire creative coding / technologist community, and basically 99% of the design / programming community in New York City.

The core of the issue is in how Oculus wants to synchronize (a) the image in the VR HMD (head-mounted display, or headset) with (b) the very subtle motions your head makes. If these two sensations aren't synchronized, then people usually suffer "simulator sickness." So, the VR industry generally wants to make sure these two things are synchronized as closely as possible, to make sure people don't vomit when using this glorious new technological medium.

In order to synchronize those things as fast as possible (90 frames per second is the minimum, 120 fps is the ideal) the HMD needs "direct access" to your graphics card.

Most laptops are engineered purposely to cut-off direct access like that, mostly because they have two different graphics processors -- one weak energy-efficient GPU, and one higher performance power-hungry GPU. For day-to-day non-VR use, the weak one is more than good enough, so that one is in charge.

From a VR developer perspective, we were early adopters and happily making Oculus prototypes for years, and our "weak inadequate laptops" were good enough. Then around runtime 0.5, Oculus discontinued OSX support and began insisting that all laptops were just inherently inferior and didn't deserve any attention. From our perspective, Oculus basically took away something that seemed to be functioning fine, for basically no good reason. It's really really really annoying.

If you search "oculus laptop", it's mostly going to be forum posts from the Oculus community manager telling people that laptops aren't supported... so I was pleasantly surprised when I was prepping to teach these VR classes and it turns out runtime 0.8 actually does work on my Windows laptop! My suspicion is that the GPU vendors Nvidia and AMD both updated their drivers to give Oculus what they wanted... well, kind of.

Friday, January 29, 2016

Spring 2016 semester in game development

Hey, what's up, long time no blog -- I've been busy prepping game development classes for the Spring 2016 semester. This season, I'm teaching four (4!) courses across 2 different universities, which is considered a really heavy teaching load in academia. (Full-time professors usually teach maybe 2-3 courses a semester, on average.) So I'm dying a little. But I'll be ok. I think.

Here's a bit about the courses:

Monday, August 24, 2015

Game Development Studies reading list, Fall 2015


In the vein of "Platform Studies" or "Code Studies", we might consider a "Game Development Studies" ("Console Studies?") -- a field of research investigating the technical and material aspects of video games, from early prototypes to production code to distribution. How have various processes of game development changed over time? How does that influence what games are, or how they are perceived?

Here are six books that, I think, do much of that work:

Friday, February 20, 2015

Radiator University, Fall 2015 catalog (excerpts)

CENG 395: ESCAPING A ROOM OF ONE'S OWN (STUDIO INTENSIVE)
In this class, we will analyze a variety of escape narratives, from stage magicians to US slave narratives to feminist memoirs to prison break films to the modern war refugee story, to articulate a robust "aesthetic of escape." When is escape possible and honorable, and when is escape futile or cowardly? From this cultural survey, we will conceptualize and construct a real-life "escape room" puzzle installation that attempts to invoke and honor this long and complex tradition of escapism in its materials, environmental storytelling, construction process, and puzzle design. (2 credits, Sao Paulo campus.)
Prerequisites: ARCH 211 History of Prisons, CENG 200 Intro to Plumbing Electrical and HVAC.

HTECH 201: HAMLET ON THE HOLODECK
Using a combination of 3D scanning, motion capture, and virtual reality technologies, we will literally attempt to recreate a scene from Hamlet on a "holodeck." In doing so, we will also critique the rhetoric of immersion that permeates popular fantasies about virtual reality and narrative, and align it with contemporary interpretations of Hamlet. For instance, in Shakespeare's time, the ghost-revenge plot was already a well-established trope -- thus, one could argue that Hamlet is essentially a self-aware character who knows he is in a cliched video game, and wonders whether he can transcend the military-entertainment complex's demand for graphic violence. (3 credits, Spring semester only.)
Prerequisites: ENGL 314 Elizabethan Literature, HTECH 100 Intro to Holographic Interfaces, at least 1 semester in any Melee Combatives lab.

EDUC 999: STANFORD UNIVERSITY EXPERIMENT (cross-listed: PSYCH 999)
The Stanford Prison Experiment was a notorious battery of mandated sadism that masqueraded as a scientific exploration of human nature. Using similar terms, we will attempt to build and perform a model "Stanford University" within our existing university, replete with its own facilities, students, faculty, and administrators. In the best case scenario, basic legal and ethical concerns for humane treatment of human test subjects will prevent us from running the experiment at all, thus implying that Stanford University itself is an oppressive institution barely distinguishable from a supposedly artificial and isolated prison. (no-credit pass-nopass only, Fall semester only.)
Prerequisites: CENG 395 Escaping a Room of One's Own

Previous semesters are available here: Fall 2014, Spring 2013

Esteemed alumni: have you recently thought about making a large donation to Radiator University? All donations to...

Friday, February 13, 2015

How to make stuff look at stuff / demystifying turns and rotations, and working with quaternions in Unity C#

Julia set fractal thing of a quaternion function... I actually don't really know what that means, but it's pretty.
This is kind of a blog post more for my Unity students, but I figure other people on the internet might find it useful -- let's demystify working with rotations in Unity, and explore some useful techniques for doing so.

There are 2.75 ways to store rotations in Unity: (1) quaternions and (2) euler angles (directional vectors are the 0.5, and some math functions secretly take radians instead of degrees, that's the 0.25)...

Euler angles are the typical 0-360 degree system taught in most junior high / high school geometry classes, while radians are in "units of pi" and represent the curvature of a circle. Then there's quaternions, which are scary 4 dimensional representations of a rotation that you may have never heard of / can barely spell! Fortunately, you don't need to know quaternion math in order to work with rotations, Unity will handle conversions for you.

Okay, so first let's explore a most common problem: how do you make stuff look at stuff in Unity?

Wednesday, February 4, 2015

Teaching game development... in public!


I remember one time in design school when a guest critic called out my classmate's project, a website to facilitate bartering. The critic balked at the idea of imposing specific procedures on how people should conduct a trade, and he talked about how the parents of Park Slope, Brooklyn shift several million tons of used toys using a very active Yahoo Groups (the class gasped in horror)... sometimes all a user wants is a message board.

So I'm one of those \Blackboard / "enterprise-class courseware learning platform" skeptics. If you've had the good fortune of never having to use one, they look like the image above, usually some really bloated outdated web portal thing with 50 different "learning modules" that 90% of university classes never use unless they're forced by the department.

As an instructor, I don't want to "setup an assignment" by digging through three different layers of menu screens! Sometimes all a user wants is a message board.

This semester, I'm running my game development courses on GitHub, Steam Community, and Tumblr. All three provide some semblance of message board functionality, so they're all suitable for teaching. Here's how I'm doing it:

Wednesday, September 18, 2013

Teaching struggle.

The other day, I sat down with a student in my Unity class to review some course material and answer some questions. They were wondering why their code wasn't compiling. Their code looked something like this:


Wednesday, August 21, 2013

What should you learn in Games 101?

I'm teaching an undergraduate "Games 101" class at Parsons this Fall semester, and putting together the syllabus has been... not easy.

It's supposed to introduce students to a body of game history / game theory, while also letting them dip their toes into non-digital and digital game design. This is like 4 different classes being merged into one, so it's going to be hard to cover all the bases while accommodating everyone's varying experience and fluency in game design.

Many of the students will already be familiar with video games and board games -- but just as many will be taking this class because their advisor said it was good for learning interaction design, or maybe they wanted what sounds like an easy elective -- or maybe they played Temple Run once (a month ago) and they haven't touched any video games since then, but they sure like playing beer pong and basketball and tag, and those are games, right? (In some respects, the "gamers" might have the most to learn.)

Some pillars of my approach to Games 101:

Tuesday, May 21, 2013

Post-partum: teaching Unity.

Here's a bit of reflection on my first semester teaching Unity at an art and design school, mixed undergrad / grad level. They're in the form of rough guidelines that I'm giving myself for next semester:

» Don't assume mastery of coding fundamentals. Some students will be able to formulate and solve abstract problems with little help, while other students will need to be taught the difference in syntax between variables and functions, repeatedly. Course prerequisites, even if enforced by your school's registar (at Parsons, they usually aren't), are no guarantee of mastery. In my class, I put a code comprehension section on the midterm exam, only to realize that some students didn't understand nested for() loops, which implies they don't fully grasp how unnested for() loops work either; but it was the midterm, and it was already too late. Some students didn't know how to use AND or OR, and some didn't understand scoping. I should've caught these problems earlier instead of unintentionally punishing them for it.
Recommendation: On the first or second week, conduct a diagnostic quiz that asks code comprehension questions, and assess which students need which kinds of help.

» Cover vector math, every day. Do light drilling. Even students with significant code experience may have trouble conceptualizing how vectors work together / what vector operations do, especially in 3D. I don't think I'd necessarily impose grade school drilling, like worksheets with 50 problems and 1 minute to solve all of them, but a few minutes or short drill, every day or week will help a lot.
Recommendation: At the start and end of each class, do some vector math problems together as a class. Practice thinking about vectors in multiple modes: visually as spatial coordinates, abstractly as sets of numbers, and procedurally as variables in code.

» Teach Maya and Unity, side by side, in parallel. I front-loaded the syllabus with Unity stuff, and only started Maya in the second half of the course. I think this was a mistake because we ended up having a 2 week break where students did very little code and focused on Maya, and it seemed to be like we were moving "backwards." I should've paced the class better to prevent this dead time.
Recommendation: When teaching the basics of 3D transformations in Unity, also teach the basics of 3D transformations in Maya, and emphasize the many similarities in interface and project organization: scene hierarchies, hotkeys, lights, materials handling, etc.

» Don't teach coroutines. I tried to teach this early in the course, and it ended up confusing a lot of people. Personally, I use coroutines constantly because I find them really useful for timing things... but maybe I shouldn't have projected my own practices on them.
Recommendation: Teach the use of timer variables and bookkeeping variables / using Time.time instead. It is worse practice sometimes, but it is a more immediately intuitive way of timing things, and reinforces fundamentals of controlling logic flow.

» End with procedural mesh generation / mutation? I really want this to be an "a-ha" moment of the course -- when students realize that everything is just a different way of storing data, and artists are just people who can figure out how to get the data looking and performing the way they want. Considering the emphasis on 3D, I think this is a much more coherent endpoint than my previous emphasis on AI and behavior.
Recommendation: If students have been working in Maya for a while and they understand for() loops, they might be ready to iterate through arrays of mesh data. Maybe look at implementing some Perlin noise or a simple sculpting tool.

This summer, I'm going to try to put these ideas into practice when teaching 6 week Unity intensives at NYU Game Center. Feel free to check-up on us on the class GitHubs (session 1) / (session 2).

Friday, March 22, 2013

Summer 2013 @ NYU GameCenter

This summer, I'll be teaching 6 week Unity studio intensives at NYU Game Center. The "regular" class during the semester is usually 15 weeks, so trying to fit all that material into a summer course will be, uh, interesting.

The sessions themselves are pretty expensive, but I believe that they do count for credit that you can put toward a degree. I believe non-students can also take it for non-credit status, which might be cheaper? Unfortunately, I don't set the price, so all I can do is to try to help you get your moneys' worth. You can look at the Github for "Building Worlds", the (15 week) Unity course I'm teaching at Parsons right now -- as well as a blog post on my general approach to game development education.

You'll, uh, also get to hang out with me, I guess. That's a perk, right?

Wednesday, February 13, 2013

Approaches to game development education.

I'm currently teaching a Unity class at Parsons called "Building Worlds" -- and I'm treating it as my opportunity to get everything right and Solve All Problems in Game Dev Education... Obviously, the reality of the class is much more complicated, and ambitious teaching philosophies never really survive a semester intact.

But before I become bitter and jaded, here are the main principles / pillars I'm starting with:

0) Game development is not game design. The former concerns process, implementation, and engineering, the latter is the art of theoretically abstracting behaviors and relationships into something compelling.

1) Breadth. Everyone should know a bit of every aspect of game development, a "liberal arts" education in all facets of development, and everyone should be able to make a game entirely by themselves. All developers should have basic drawing / modeling skills, basic coding skills, and basic design skills. Of course, everyone has their specialties and interests, but the goal of game development education should be to produce independent, T-shaped developers who can see the big picture and collaborate when they need to. Don't specialize too early.

Thursday, January 31, 2013

My Spring 2013 at Parsons

This semester at Parsons, I have two things going on:

1) I'm teaching an undergrad / grad studio elective course.

Currents: Building Worlds was originally pitched as an "introduction to Unity" class, but then the administration said that Parsons never conducts purely "software" classes. They suggested teaching Unity through some sort of theoretical lens -- and the class design is probably much better for it. So now, it's kind of an intro to Unity / C# / working with expressive 3D / architectural theory class, and it argues for "3D" as a unique expressive medium in itself. There's also a strong focus on discussing "behaviors" theoretically, and how to combine simple behaviors to produce some sort of emergence... whether that's what constitutes a "world." I think I'll assign a chapter of 10 PRINT as a reading? (The "Currents" prefix is like a disclaimer -- "This course is an experiment. Take it at your own risk.")

2) I'm also a "consultant" / aide / "technologist" on another course, taught by Colleen Macklin / John Sharp / Heather Chaplin.

Datatoys is a collaborative class between journalists and design students to re-imagine journalism as a toy -- to turn data into interactive systems that demonstrate patterns of behavior. "Let's face it," began the journalism professor, "reading the New York Times is really boring. Print journalism is dying. Now, what is the journalism of the future?" What are the politics inherent in toys and play? How do we reconcile that with the ethics of journalism? If play is independent and unstructured, does that resemble how journalistic objectivity is independent? Can players act as journalists? How and when do toys lie?

The multidisciplinary nature of these two courses is what makes them conceptually strong and compelling, yet also very difficult to realize into actual designed things... But if they were easy, then they probably wouldn't be worth doing.

Thursday, June 14, 2012

Dan Lockton's Design with Intent


I remember reading Dan Lockton's original PhD blog, like, 5-6 years ago, and being impressed by his ability to explain usability concepts with his many real-life examples. One of the bigger problems in usability design today, I think, is that it's often theoretical or just pulls the rote academic examples from Donald Norman.

What I like best about Design with Intent is that it doesn't preach usability or design as a religion: bad design and obfuscated design, just like good design, can be important tools depending on your goals.

Anyway. If you're not familiar, and you have some sort of interest in level / game / any design at all, then flip through this slideshow and let Lockton crack a few eggs of wisdom on you.

Saturday, April 28, 2012

What makes "good" writing on level design?

Liz Ryerson recently did a great write-up of level 5-5 from Wolfenstein 3D (and makes a good case for the surrealism of 4-3) and it occurred to me that there's a pattern to this type of writing -- it's usually very specific, talks only about a single level (but contextualizes it within the whole game), and makes ample use of screenshots to help the reader understand the layout.

Writing about level design is incredibly important because we often run through levels so fast and understand "the language of games" so intuitively that it can be difficult to verbalize and explain. In playing levels, they exist more as tools to express our intentionality, not as objects to be studied and examined. The reality of it is that it would take a long time, or sometimes it's very difficult, to gain the type of fluency in platformers or Wolf3D that the best levels require.

But this is how we do research -- we make games and play the ones we can. Articles and essays are the best way to learn about levels that you haven't played / can't play.

Here are two authors of "level criticism canon" that, in my mind, show us how to do it...