Tag: LittleBigClass

It’s been an especially busy (and awesome) week for the DGM 6400 crew. We had two sessions this time around, one of them being an all-day stint at PAX East.

We arrived at the mammoth Boston Convention and Exhibition center early, which didn’t prevent me from getting caught in an insane line to grab my media badge, and we were kicked out of the first IGDA panel since floor-sitters weren’t welcome. Thankfully, everything went up from there – we were able to play – and have conversations with each of the teams behind – all of the games at the Boston Indie Showcase.

Smuggle truck, in particular caught my eye – it’s a satirical take on onerous American Immigration law, and a hilarious, uproarious game to boot. Alex Schwartz, the “chief scientist” behind the project, talked to everyone, extolling the virtues of Unity (a particularly awesome game engine) and giving the background on the game and its unique story. Snapshot and Blinding Silence both brought genuinely unique mechanics to the table, which is always nice to see (especially when you’re surrounded in a giant E3-like expo hall with franchise AAA’s blaring all around you).

We spent a good deal of the day in panels, including the awesome (and too short) talk on “dialogue as gameplay”, where Bioware’s Daniel Erickson semi-infamously said: “We always talk about when there’s going to be the Citizen Kane of games. There’s never going to be a Citizen Kane for ballet either. It’s a dumb concept. It’s a totally different genre of storytelling. Our biggest advantages is player agency so it’s what we have to put first.”

At the show, we spent equal amounts of time in in-depth conversations with small, indie developers and in career-focused programming (headed by folks from larger “AAA” studios), so we were able to effectively get both perspectives.

The biggest takeaways:

– A student/candidate’s portfolio is absolutely king when looking for a job at a bigger studio. It should contain only the very best work (and smaller is preferable, i.e. have fewer “great” pieces as opposed to several “good” ones).

– Everyone recommended having a portfolio website – many companies prefer links to attachments, and a website is another chance to show design/programming/art skills. Free blogs (wordpress, blogspot, etc.) are ok, as long as they aren’t used as “blogs” per se, but as a portfolio site that highlights your work.

– At larger studios, you will specialize to a tremendous degree, but it pays to have other related skills (such as a character artist who can also rig) for lean times at the studio.
-On an indie production, you’ll probably do a little bit of everything (design, program, art, marketing, etc.). Students need to choose which avenue they’d like to go and optimize their portfolios accordingly.

– This is huge: you need to learn a game engine. The biggest ones mentioned (that kept coming up throughout the day) were Unity and Unreal. 

I was particularly interested in the point about learning game engines, especially for designers. Unity and Unreal were mentioned as top choices (for good reason, they’re damn near ubiquitous at this point), and something I’m certainly going to emphasize to students going forward. Every studio will be using an engine (whether its proprietary or licensed), so those skills are portable and incredibly useful.

On Monday night, we spent the entire class building in LittleBigPlanet. My students are excellent level builders by now, so we had a giant, tricky treehouse and a hilarious obstacle course up and running within an hour or two. Again, we have two small teams working on two-stage games each, so it’s nice to see quick progress.

Half of the class was spent playtesting – each team took turns handing over the reins to their classmates on the opposite team, observing their playthroughs for trouble spots, weak points, and everything else you never think of when you are designing things yourself.

It was remarkably instructive. One uninitiated student found a level-killing flaw within 5 seconds of starting a stage. Another playtesting session yielded several new ideas for directions their project could take. The feedback process is absolutely essential (and I’ve been teaching this class as if playtesting and the iterative process are gospel), and I could practically see the gears turning in students’ heads as they watched their colleagues fumble with their creations.

We’re building, playtesting and building some more from now until the end of the course, and next week is our penultimate session. 12 weeks goes by fast, and you can be sure I’ll have quite a few wrap-up thoughts at the end. For now, though, it’s LittleBigPlanet all the way to the end!

Check out every installment of LittleBigClass here!

As someone who finished grad school and entered the frenzied world of “hey, I’m overeducated and want a job in a specific creative field!” not too long ago, I’m very serious about trying to give my students as much ammo as possible for their own career planning. In that light, week nine was all about the job search – finding out what various companies are looking for, how to build particular skills, and how to effectively search for opportunities.

I gathered a few design-specific postings – from Blizzard (they’re seeking a designer for Diablo 3), Gameloft (looking for a general game designer), and Irrational (for both level design and systems design positions). I tried to go for variety (both in terms of genre and scope), and let everyone go wild on the Gamasutra job board if none of the pre-selected positions suited their fancy. Then, I tasked them with writing cover letters for their job of choice, listing all of their design experience and portfolio-worthy work (including everything we’ve done in class, and an “aspirational” project – a full mobile game – that they expect to graduate with).

The point, of course, is to get them familiar with what’s out there, what will be required of them, and what they should have in their portfolios come game day. We chatted about the value of knowing a given company’s line of games (and the ability to speak critically about specific design decisions), and the importance of having an absolutely stellar portfolio. Studios want to see that you have the skill and the determination to put together strong, coherent work – so levels and mods and well-thought-out design docs are a must.

Check out the “requirements” section for the Blizzard/Diablo position:

Requirements
• A minimum of 2 years game design experience on a shipped product
• Excellent written and verbal communications skills
• Absolute passion for playing and making computer games
• Able to work well in a team environment

Pluses
• Bachelor’s degree or equivalent experience
• Experienced in designing, playing role-playing games (RPG’s) and action games
• Experience developing rule sets (pen and paper or electronic, character classes, enemies, skill systems, etc.)
• Experiencing running pen and paper RPG campaigns

And the Irrational Level Designer:

Required Experience and Skills:
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.

We’re also planning to hit the career-related panels at PAX East this Friday – so if you’re hitting up the IGDA dev center for “Resumes That Rock” or “Portfolios and Demos that Rock” – feel free to come say hello!

The second half of class was spent on building exercises in LittleBigPlanet. After a few weeks spent primarily on design discussions, job searching, and mechanical analysis of existing games, we’re back in the LBP saddle for the rest of class, building two-stage “games” for the final project.

It was a simple assignment. If you like, take a gander:

In your groups, build a very simple stage that contains at least TWO of the following features:

1. An elevator
2. Suspended platforms
3. A vehicle
4. A “dangerous” obstacle (such as a pit, fire, poison gas, etc.)
5. A character with dialogue

This is an exercise in very rudimentary building, LBP toolset use, and problem solving. Do not worry about aesthetics. You’ll have 90 minutes to build and present your work to the rest of the class.

Not to leave anyone high and dry, I supplied a few youtube tutorials (in fact, tutorials I’ve used in building my own levels) for good measure and let them have at it. Once everything was up and running, I floated around the room, watching the magic happen. One group put together a sensor-enabled elevator that connected to a zipline (which ended with a sackboy-skewering pit of spikes), while the other worked on a tiny fleet of retro-looking cars.

It’s awesome to see these kinds of “it has guidelines, but feel free to create what you want” exercises work. It’s always a balance between giving clear, concise instructions and letting the creative juices flow freely, but I think we hit a nice middle point with this one. As always, the most fun part of this job is to sit back and watch the wacky stuff that comes out, and its always gratifying to see the “aha!” moments alight when a student starts seeing the potential in his/her fiddling.

Check out every installment of LittleBigClass here!

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!