Showing posts with label parsons. Show all posts
Showing posts with label parsons. Show all posts

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).

Thursday, May 2, 2013

Game development as drawing; gesture, iteration, and practice.

(NOTE: There are sketches of nude human figures in this post, with their anatomy intact.)

If you ask any great AAA game artist about the single-most important thing you can do to get better at art, they'll probably start mumbling about "foundation." Photoshop, Maya -- these are just newfangled versions of pencils or paintbrushes or clay. They won't really teach you how to paint, or how to sculpt, or how to look at things and represent them. In this way, a bit of traditional, non-digital fine arts education can be an extremely useful tool sometimes.

In the pretty casual 12 week, 2 hours a week drawing class I took, the teacher presented two ways of thinking about drawing:

Monday, April 15, 2013

Dreamlab: VR research at Parsons.

Next year, me and Kyle are starting a (very small) virtual reality ("VR") research lab at Parsons. We've set our initial long-term research initiative as some sort of "virtual sculpting studio" -- so maybe one day you'll put on your Oculus Rift and power gloves, sculpt some virtual clay, and then send the model to a 3D printer? Wouldn't that be cool? We have lots of other ideas too, but those will require a lot more money / space / time, so this is us, thinking "small."

If you think it sounds awesome, please "like us" (ugh) on this weird startup grant social media platform thing so some giant well-funded entity can give us money. Or, if you happen to be a corporate or nonprofit entity that has money you'd like to part with, please get in touch.

The full proposal text is here:

We envision virtual reality as a “place” that allows us to do useful work and experience unique phenomena. Much like going to a woodshop to work wood, or a kitchen to work food, we imagine dedicated VR spaces for people to work and play with data in intuitive ways. How can we use the unique affordances of virtual realities to visualize, embody, and interface with virtual data most effectively?

Thursday, February 21, 2013

PlayThings, a toys and play symposium, 23-24 Feb 2013 at Parsons

PlayThings is a symposium about structures of play, and the ways in which design can enable or resist those structures. What does it mean to play? How meaningful is the distinction between toy and game? etc.

6 East 16th St, 12th flr
in NYC (near Union Square)
February 23rd - 24th
11 am - 5pm

Day 1:
a panel discussion around the ideas of play led by:
McKenzie Wark (Lang)
Colleen Macklin (PETLab)
Zach Gage (
Cas Holman (RISD)
moderated by John Sharp
a 3hr play session with various kinds of toys and games i.e. historical toys, mechanical toys, building blocks, plushies/puppets/dolls, board games, video games and physical games to introduce participants with the variety of things and activities that constitute as play.
(led by Kyle Li and Nick Fortugno)

Day 2:
Day 2 consists of a day-long workshop and play-jam session where participants come up with their own games, toys or other forms of public play and the creations are later reviewed by the panel and other participants.
(5 hr making + 1 hr judging/playtesting)
(basic toy building materials provided)

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.

Tuesday, December 4, 2012

Teaching game development community.

In Spring 2013, I'll be teaching an undergrad / grad Unity course at Parsons called "Currents: Building Worlds."

The course has a few learning goals -- (a) to gain a broad conceptual understanding of how Unity works across art assets and code, (b) to learn some useful software engineering patterns for games, (c) to develop self-sufficiency for solving Unity problems / "learn how to learn", and lastly (d) to recognize membership in a global game development community.

That last one's probably the most ambitious.

Saturday, May 19, 2012

Parsons post-mortem: "Games and..."

Parsons is a bit of a secret games school: they don't advertise much, and the students / faculty rarely shill for the program. (I'm an exception, I guess.)

I enjoyed my time here, but it's not for everyone. I find most prospective students are trying to decide between Parsons / NYU / USC or something, so this post is mostly tailored to them. (There's also a tl;dr at the bottom.)

Here are, what I think, the strengths of studying games at MFA Design and Technology at Parsons:
  • Diversity. A Model UN's worth of international students. About 40-50% of the students / faculty are women. Also, there's a healthy LGBT presence and culture, e.g. some of our bathrooms are branded "gender-inclusive", and ~10% of our cohort was LGBT. Some students are 36 year old engineers; some are 24 year old dancers and biologists. Altogether, this makeup is VERY rare in the monoculture that is the technology / games field.
  • Breadth. You will go to gallery openings and interact with the larger New York City art scene. You will learn soldering, coding, and typography. You'll get a general sense of where the "new media" art scene is at, to the point where you can go to a MoMA exhibition and yawn at their curation with knowing confidence.
  • Flexibility. If you realize you're not into games so much, you can totally do something else without any disruption toward your degree. Start welding something! Sew a dress! Make a video performance! Grow algae batteries! Build robots! Just start doing it and you can.
  • Maturity. MFADT is a very old program (15+ years old?) compared to most dedicated games programs. The veteran faculty know what they're doing. The courses and curriculum generally work.
  • New York City isn't AAA! The NYC indie scene is among the strongest in the world, with frequent meet-ups and events. Killscreen and Babycastles regularly partner with museums to do stuff, and there's always at least one games-related thing going on every weekend.
Now, as for the gaps in the program, I actually regard them as strengths, but I understand people see things differently -- so here are the "weaknesses"...

Tuesday, May 8, 2012

Souvenir prototype (build 08) is public!

You can play an early version (and by early, I mean still really unpolished, buggy, and unfinished) of our collaborative thesis at Parsons: "Souvenir." It's basically VVVVVV + Proteus + Dear Esther + a bit of Portal. For some of the thinking behind the design, read "Against Puzzles?"

Here are some bugs / glitches / issues we already know about:

Wednesday, April 11, 2012

Come see CondomCorps and others @ Spring Fair

If you're going to be in the New York City area on Sunday, April 15th, come check out my department's first ever "Spring Fair" -- basically, we're all just going to show the random stuff and side projects we've been working on for the past semester. I'm planning on debuting the newest version of CondomCorps (now with romantic subplots!) and I know my classmates have plenty up their own sleeves; there'll be plenty of games, robots, interactive installations, and just plain cool shit.

Come pop in for an hour or stay and hang out / mingle with Manhattan's technorati!

We'll be at 6 East 16th Street, 12th floor, right off the Union Square stop. Sunday, 1-6 PM. (map)

Sunday, April 1, 2012

Against Puzzles?

(I was going to do a "Radiator 1-3 is done" post for April Fools, but it hurt too much...)

We had a public playtest of me and my teammates' VVVVVV-FPS thesis project, "Souvenir," with a bunch of New York City junior high / high school students -- and I don't know if you've ever been to a New York City public school, but these kids generally speak their mind (to put it mildly) and they're ideal playtesters. I also had a few interesting conversations with them. One of them asked what the goal of the game was, so I started trolling / engaging them:

Well, when you go out for a walk, do you have a goal? No, you just walk because you like walking.

"Yeah," she said, "but if all you do is walk around, it gets boring after a while. I'll stop playing." Well, that's fine, then stop playing.

"Plus," her friend says, "I'd just play it once. And then it would gather dust on my hard drive." That's fine. Play it once and delete the game then.

"But like, if I wanted to walk around, I'd just go outside." That's fine. Then go outside!

They're so young, and already they're perpetuating the same messaging from massive industry interests: that the "realism of games" competes with the realism of reality, addictive games are better games, clear goal structures are best -- and retention, retention, retention. That's just one way of thinking about games, and they've already locked themselves in that mindset. They've been indoctrinated.

Friday, February 17, 2012

The shadow of the white cloud: architecture criticism at the 1893 World’s Fair and BioShock Infinite.

I’m taking an architecture criticism class with Paul Goldberger, the architecture critic at the New Yorker. My interest in the class involves its intersection with video game architecture and virtual environments. This is my research, as cross-posted at the Games @ Parsons group research blog too.

While the original BioShock’s diegesis focused on objectivism and the dangers of uncontrolled capitalism, Infinite’s level architecture is more about the dangers of American exceptionalism as exemplified by the 1893 World's Fair.

In my architecture seminar, the story of the World's Fair was a bit more nuanced than that, and it goes something like this:

Tuesday, February 14, 2012

Shilling for a friend: "Doodle Defense"

I don't normally shill, but when I do, it's for Kickstarters that explore new input methods. Doodle Defense, by Andy Wallace, could use a few of your Earth dollars. Draw on a whiteboard and watch colored things magically avoid them; ah, the magic of A*!

Thursday, February 2, 2012

Games @ Parsons

Hey all, just a brief plug -- me and my fellow students / faculty at Parsons are starting a new initiative to talk about the stuff we do in graduate-level game design studies. This public research blog is called "Games @ Parsons" -- we'll analyze indie games, post our own experimental prototypes, try to situate your favorite games in the context of academic research, announce cool NYC events for you to attend, and generally just be cool because school is cool.

Monday, April 11, 2011

Course syllabus: "Game Design and Architecture"

Here at the Design and Technology MFA program at Parsons, the "Game Design 1" course is extremely popular. Like, it's one of the first classes to fill up at registration. In it, you learn about analog game design and make your own board games / card games.

Conversely, "Game Design 2" is about level design, mostly in a digital context, and it is much less popular -- to the extent that this semester, it got canceled from lack of enrollment. (Or at least that's the reason they gave us.)

Why was Game Design 1 so popular, but Game Design 2 (level design) allowed to die? I see them as two very similar, important things for interaction designers to learn, but apparently both the student body and administration disagree with me.

However, I'm the one who's always right about everything.

So in my assignment for a design and education class, I thought I'd try to bridge the gap between the two and make a level design class for people who aren't particularly fond of video games. It focuses on interaction and environment across various types of games.

We deal with fairly simple, basic games and mechanics so we can focus on the levels. Also, keep in mind that the intended audience is middle school / early high school, though I'm sure if you crammed in some readings and essays in there it'd make for a decent college freshman class.

The working draft of the syllabus is pasted below. Feedback is appreciated:

Game Design and Architecture
Robert Yang. E-mail.

Think about the first level of Super Mario Bros. or your favorite map in Halo. Think about a game of Monopoly, when you're leaving jail and you have to brave the minefield of hotels. Think about a game of baseball in Fenway Park, where there's a 36 foot tall wall called the “Green Monster” that prevents easy home runs.

In video games, board games, sports, and anything else: it matters where you play.

Video games call this “level design,” but in this course we'll explore both digital and non-digital representations of the environment and how to build them. If you like board games, video games, sports, playground games, or anything else game-related: we'd love to have you.

Tuesday, March 15, 2011

Butte, Montana. 1973; a board game about open-pit mining.

Last semester I made "Feng Shui," a board game where two players discuss (or argue?) over how to place furniture using chopsticks. This semester I've made "Butte, Montana. 1973." (as in "Beaut" or "Bee-yoot" but not "Butt")

It's an art board game (or board art game? or bored art game?) about open-pit mining. And it's a box of dirt. It's not terribly interesting as a "game qua game" -- if you want that, go play Catan or Call of Honor or something -- but it's an attempt at wondering what else one can do with a game. It also made me realize that video game designers should be forced to make analog games more often.

First, a bit about the design theory that supposedly powers this beast:

Wednesday, November 24, 2010

So... I Played a LARP: "Ghost Engines in the Sky" by Nick Fortugno

low-res photos ripped (under Fair Use) from the New School Free Press article on the same game
... apparently not all LARPs are about throwing lightning bolts.

It was Nick Fortugno's "Ghost Engines in the Sky", set on a mysterious train in 1850. You're one of many passengers -- stricken with short-term amnesia, of course -- and you have to find out what happened / who should get blamed for it. Overall it was pretty cool, but I felt like there were some issues with the facilitating, signposting and the procedural rhetoric...

(*extensive* SPOILERS after the jump)

(this LARP relies heavily on fresh, unspoiled players -- like, literally, if you read anything more, then consider yourself banned from playing this game *forever.* If I could adequately critique this game without spoiling it, I would... But I can't, especially when it defies the popular conception of a LARP.)

Wednesday, September 15, 2010

5 in 5: "Dalloway Floorplan" (digital)

"5 projects in 5 days" is part of my coursework at Parsons. The complete rules are here, but my own additional design constraints are (a) gotta be a game, (b) gotta be made in less than 3 hours.

The next volume of Radiator ("Next? You haven't even finished the first!") will be an experiment of sorts in production: I'm going to use essentially the same level for all three episodes. This is great in that I only have to design and build and detail a single map!... And this sucks because I have to account for 3 different kinds of gameplay in the same space -- a heist, a mass murder, and a party. (If you want to spoil the gist of these ideas for yourself, see: heist, mass murder and party.)

Monday, September 13, 2010

5 in 5: "Mono in New York simulator" (digital, HL2 map)

"5 projects in 5 days" is part of my coursework at Parsons. The complete rules are here, but my own additional design constraints are (a) gotta be a game, (b) gotta be made in less than 3 hours.

"Mono in New York simulator" is a map using the first person shooter engine of Half-Life 2 that shows you what it's like to have mono (or mono-like symptoms, at least) in New York.

The gameplay consists of you being confined to your bed as your health slowly drains away. You can stare at the ceiling, the walls, or the floor, but not through the window. There is only one ending.

(No download offered out of mercy.)