Author: Danielle Riendeau

Monday night was a particularly fun session for our class, chiefly because we spent most of the night playing games. Man, I love this job sometimes.

Seriously, this was an exercise in experiencing – and analyzing – game mechanics. This is a term that gets thrown around quite a bit in games writing, so here’s how I described it to my students:

“First, the academic definition, from a Game Studies posting: Game mechanics are rule based systems / simulations that facilitate and encourage a user to explore and learn the properties of their possibility space through the use of feedback mechanisms.

In plain English, these are the systems by which you engage with the game. Jumping is a mechanic in LittleBigPlanet. Cover is a mechanic in Gears of War. Each operation that the player executes in a game is, for our purposes, a game mechanic.”

I set up four “stations”, each running something wildly different from the rest, in terms of genre and theme. Civilization IV was going on a laptop, Need For Speed: Pro Street on one TV, Resistance 2 on the other, and my beloved DS flat was running Super Scribblenauts by the teacher’s station. I brought a Wii (and Boom Blox!), but in my rush, I forgot the Wii-motes. It ended up being just fine – my students each had plenty of time to play and watch, and we had a pretty nice variety going, so no sweat.

It was instructive to watch just who went where, and how each person reacts to playing wildly disparate games in succession. Some students struggled with the controls of the FPS or the racing game, since one or the other is simply not the genre they’re most used to (all of my students are gamers, of course, but certainly, they each have their preferences). Civilization, meanwhile, provided a much more cerebral struggle. A few students attempted to get through the tutorial in the 2 hours allotted for playtime. Since it’s just so damned different from other games, Scribblenauts probably provided the most interesting (and possibly the simplest) opportunity for mechanical analysis, but the DS spent the most time closed out of all of the stations.

Both Need For Speed and Resistance garnered crowds of spectators (well, as much as one can call two or three people a “crowd”) throughout the night. It makes sense, since both the laptop and DS games are meant for one player, on a smaller, more “private” screen, and the blockbusters are supposed to be spectacles.

After playing, we had an exercise in analysis – basically, each student picked one of the games, listed out each discrete mechanic, and noted its strengths and weaknesses, as well as how well the mechanic “fit” with the theme/premise of the game. Basically, does it take you out of the experience, or does it “fit” within the whole picture?

Even though we had clearly defined “mechanics” for the purposes of this class, it’s still a something fuzzy term – something that’s easier to know intuitively than to explain with perfect clarity. As Miguel Sicart states in the same paper I gathered the “academic” definition from,

“Seasoned players would probably not hesitate to call the cover system a “mechanic”, something that connects players’ actions with the purpose of the game and its main challenges. But the meaning of the term is not always clear.”

Thankfully, my group is awesome, and we followed everything up with a lively discussion of the games on offer and yes – how their mechanics “worked”. Somehow, we got to the subject of Crazy Taxi (a game that I’m playing a whole lot of these days, as part of the Dreamcast collection) and its pure, effective, downright addictive mechanics. The next time I do this class, I’m bringing in Crazy Taxi.

Next week, we’ll be buckling down and starting in on the final project – a two-level “game” in LittleBigPlanet, complete with a full game design document. I’m also prepping an introduction to job searching in the industry – and spending an inordinate amount of time on Gamasutra’s job board in doing so.

Check out every installment of LittleBigClass here!

Monday’s class was a big moment of truth for me (and my students). The first major multi-week project was due, and it was the first real test of their ability not only to design amazing levels, but also to present their work and prove their skills as communicators and team players as well.

I can’t go into any details for confidentiality reasons, but suffice it to say, both groups knocked it out of the park on their pitch presentations AND their design documents. I’m not only excited as a teacher (hopefully, this means they’re actually learning something in my class), but as a gamer – I really can’t wait to play the finished products.

I’m glad we’ve spent as much time on design documents as we have – not only does it appear to have aided the groups in getting all of their information together in a clean, clear, comprehensive format, it’s going to help them in the long run. I was running around the Gamasutra job board the other day, gathering material for an upcoming exercise, and it quickly became apparent that great design docs are still an asset to any budding designer’s portfolio.

Just check out this little blurb in the description for a Level Designer job at Irrational:

“Please remember to include: video, screenshots or save games for levels that you created in the past. Game design documents, writing samples and/or game analysis should be submitted as appropriate.”

Unlike a position in programming, or even the art department, jobs in design blend skillsets that are simply harder to nail down in terms of specifics. Just check out the “Required experience and skills” section:

“This position requires a high degree of creativity. You will be required to work with the team to form a “vision” of your levels and use that vision to inform your design decisions.

An important part of the role is communicating that vision clearly and concisely to the rest of the team and ensuring that they have a clear and specific mandate for their work. You must also provide a receptive ear so that other team members can provide input on the game design.

Above all we are looking for somebody with enthusiasm, passion and the desire to create levels that are going to amaze gamers.”

Design can be a muddy thing. Sometimes it’s even difficult to define, precisely, and the lack of bullet points in the “requirements” section speaks volumes to that.

My goal for this class is to send students on their way through the program with well-practiced, portable skills, an extensive creative vocabulary, and yes, design documents and finished levels that they can show off in interviews.

Speaking of jobs…

Most of the class after the presentations was spent on describing the various positions and roles that exist at development studios (and at major publishers). It’s funny, going through the roster, just how modular game design is: we’ve got the designers masterminding the game, artists visualizing and producing assets, programmers bringing everything into fruition, QA fixing all the bugs, and producers managing the whole team of disparate personalities and skills. I’ve always been fascinated by team dynamics, and much more interested in the “behind the scenes” stories about developers, which are almost always more entertaining than the stories in most actual games.

This point leads me to put on my blogger/game journalist hat for a moment:

It sucks that PR controls the narrative about the making of games so tightly in the games press. I’d love to hear about the “happy accidents”, the personality conflicts and “saving grace” kinds of moments that go into the making of my favorite games, and I think a lot of other gamers would too. The best we have are post-mortems, which are wonderful, as a rule, but few and far between. I’d love, as a reader and as a writer, to be able to access developers for full on “behind the games” features.

Alas, the best we have are the twitter feeds of outspoken developers like David Jaffe.

Next week, I’ll be lugging several consoles to class for our second major project: analyzing game mechanics across genres. I’m still trying to nail down the best titles for the assignment, but for now, I’m thinking a sampling of Civilization IV, Super Scribblenauts, BioShock, Boom Blox, God of War II and yes, LittleBigPlanet will do nicely for our purposes.

Check out every installment of LittleBigClass here!

There are some concepts in game design that are relatively easy to talk about. Take functionality, completeness and balance – the subject matter for the night’s first lecture. It’s not easy to attain balanced, fair design, but it’s at least a pretty concrete concept. We all know unfair, unbalanced gameplay when we see it. But what about the more abstract stuff? Things like “fun” “challenge” and “play” are far more difficult to define, and even harder to actually design for.

Welcome to week six of my class, where we tackled all of the above.

We whipped through that first lecture in about fifteen minutes. Completeness, functionality, and balance – these are easy concepts to explain, if damned hard to master. Since we’re a completely design-oriented class (leaving the coding up to later courses), functionality isn’t too much of a problem, but we are aiming for work that feels internally complete and balanced. So when we design in LittleBigPlanet, we’re balancing for pace and difficulty, and trying to keep a nice system of risk vs. reward alive in the gameplay.

Fun and accessibility are much tougher to summarize. Different people obviously enjoy different things. Hardened strategy gamers, twitchy FPS players and Wii-fed six-year-olds will all have wildly different (and still entirely valid) ideas about what is fun, so I think it helps to start by acknowledging the different kinds of fun.

To simplify, we’ve got hard fun (challenges and goals), easy fun (playing around, exploring), people fun (social interactions, competition) and serious fun (the need to play, explore ideas, etc.). Most games will blend more than one of these “types”, obviously, but one or another will tend to dominate. LittleBigPlanet itself crosses into all four, but for my money, its most important role is rich in the creative aspects of “serious fun”.

Challenge

Challenge is one of those things that’s insanely hard to get “just right” – make your game too easy, and it will feel unstructured, boring and lame. Too hard, and you’ll piss off players or bore them in an even worse way. Hit that sweet spot, and you have an enormously satisfying experience. A player who feels like he/she is constantly learning and applying those new skills, having a good time with the mechanics, and experiencing (whether subconsciously or not) the addictive effects of a competent risk vs. reward system is usually a happy customer. He/she is having fun.

One of my students actually asked me about reviewing games and whether I’ll score a title lower for being inappropriately hard or easy. Immediately, I thought of Mario Galaxy 2 and Donkey Kong Country Returns (and decided on the spot that this needs to be a podcast topic).

It’s always interesting when I have to switch my so-called “hats” on the fly – from the designer/teacher to reviewer and back again. But it’s true, I certainly take difficulty into account when it’s time to grade a game, and I did with the aforementioned examples – I thought Galaxy 2 was too hard for it’s all-ages demographic, while DK was aimed more at adults with nostalgia for the older series, hence the tough-as-nails gameplay came off as rewarding rather than punishing.

It’s a little scary just how subjective that judgment is, from the other point of view. Once again, consider it a future podcast topic.

Learning by Example

I’m constantly using examples from games I know well (and have talked to death on the podcast) to try to illustrate everything. Last night, I used BioShock as both an introduction to player choice (the infamous “harvest or rescue” decision), and as an example of risk vs. reward (the camera mechanic, where you get damage bonuses for playing shutterbug with splicers). I can’t help it – it simply has good, well-implemented, dramatic examples of what I’m trying to get across. Sometimes big daddies and little sisters just teach better than I do.

Of course, so do screw-ups. I brought up a couple of examples of great games that are fun (and well balanced) all along until they hit a difficulty spike that quickly kills the momentum. Like the infamous spinning blades of platform death towards the end of God of War, and the Meat Circus in my beloved Psychonauts. In both cases, it’s been made clear that those sections simply weren’t playtested enough thanks to a big old lack of time – an obvious lesson for my group.

Next week, the first big project is due – a full design document and a pitch. I’ll try not to mention BioShock this time.

Check out every installment of LittleBigClass here!

Hi, I’m Danielle, and I’m going to be your teach… er, writer for a series I’m doing on my game design fundamentals class. Each week, I’ll be writing updates and impressions from the perspective of a teacher using LittleBigPlanet as a tool/gateway drug into the mad world of game design, so get your console fired up and your notebook at the ready.

It’s Monday night, and we’re in week 5 of our journey across time, space, and LittleBigPlanet. After a little pow-wow regarding changes to the syllabus, we’re off and running on a lecture about game design documents (sort of like the blueprints for a game). We take a look at David Jaffe’s spec for Calling All Cars. We browse through the original BioShock pitch document and marvel at the (ridiculously early) art and original story premise. We take a peek at the Grim Fandango puzzle design document. Then, I send them off to work in groups on a design document expedition.

This gives me a few minutes to catch my breath and plan the next steps. This is my first semester teaching game design specifically, though last spring I taught a game-y course in interactive storytelling. The difference here is that once my students have the basic concepts down, they’re actually going to build everything. Instead of going the more traditional route and designing a bunch of paper games, we’re going to make everything in LittleBigPlanet.

I actually designed this entire course around the toolset in LBP – partially because I want to really unleash them in a deep, accessible, creativity-friendly world that won’t discourage them, and partially because I want them to have something truly portfolio-worthy coming out of the class. They’ll have two fully fleshed out design documents, pitching experience, and at least two solid LBP levels to their names upon getting out.

These are grad students in their first leg of the game design track, which is evolving at NEU at a dizzying speed, so I needed to give them some “portable” skills that they can take with them no matter what side of production they’re going for, or what engine/operating system/what have you they’ll be designing on. LBP is, in my opinion, the very best non-technical design tool you can get your paws on. Media Molecule’s hiring of promising designers from the community only proves that point, as does the fact that they make all of their on-disc stages with the packaged toolset. It’s amazing stuff – and I’m genuinely excited to be able to use it in a classroom setting.

Teaching is…

a weird balance between organizing and improvising (there’s plenty of communication in there too). The last month has taught me a little bit about that, since equipment issues and scheduling problems have messed with my grand vision for the class. I’ve made lots of changes to the syllabus since we began – and I’m sure I’ll make a few more by the time we’re done. But I have no time to worry about that now, because it’s presentation time.

In order to prep for their first project (which consists of a full design document and level sketch for a complete “game” in LBP, as well as a formal pitch presentation for their work), I’ve had them do a little research in their groups. They each found two design docs, which they’re critiquing and presenting to the rest of us.

It’s a pretty great mix – both groups picked an example of an awesome, complete design doc and an abysmal failure, so the critiques are going well. Hilariously, one group even picked the design doc for an earlier version of Duke Nukem Forever, and they go through the entire (incredibly colorful) description of the level at hand, a trek through Vegas that includes shrink rays, unborn alien babies, a splash in the pool, and a bizarrely placed inflatable dinosaur.

I surprise them all by making them pitch the game based on their good design doc on-the-fly, just to get them used to talking on their feet. It’s a huge part of their first and third projects, and presentation skills are an absolute must for any successful designer, so I don’t feel too bad about putting them on the spot. It’s a pretty informal atmosphere, so that helps as well. They all do remarkably well, which is comforting, since it means they really got into the assignment and are ready for their next step (actually writing and pitching for themselves).

My students, it must be said, are awesome. I have six, which is perfect, since we can really go one-on-one and talk games all evening long. We can talk about what each person is playing in each session, and we’ve come up with at least three commercially viable, amazing-sounding game ideas since the beginning of the semester. Tonight, we even talk about the handling of sexual relationships in Mass Effect, which, if you listen to Jumping The Shark, you’ll know is a favorite subject of mine. This job would be a complete slog if they weren’t involved, funny, interesting people, and I really can’t wait to see their creations.

Next week, we’ll be spending a few hours with LBP tutorials, and I’m sure I’ll be asked a few questions about how to do things I’ve never tried in game before. That’s the fun part of teaching – thinking on your feet. Or, in this case, thinking on your controller.

Check out every installment of LittleBigClass here!