Session 13: Project 4 Planning and Team Formation; Serious Games

• Download this transcript - PDF (English - US)

The following content is provided under a Creative Commons license. Your support will help MIT OpenCourseWare continue to offer high-quality educational resources for free. To make a donation or view additional materials from hundreds of MIT courses, visit MIT OpenCourseWare at ocw.mit.edu.

RIK EBERHARDT: I also had a couple of students asking me about, what do you do after this class? If you want to take more classes in games, if you want to take more classes in game design, if you're thinking about the spring semester, I just wanted to throw some course numbers up here.

So there's CMS.301. It's Introduction to Game Design Methods. If you're interested in design research, if you're interested in design methods, and you happen to also be interested in games, but you're likely going to be doing things in design elsewhere-- so that might be application design, toy design, anything physical, anything game-like, whatever. The methods they're going to teach in there are going to be useful for all those things. But the class is focused on using game design as a way to talk about design methods-- so CMS.301.

CMS.608 is a class Phillip teaches, and I co-teach with him, on game design-- so if you want to know more about how games are designed. Some topics we talk about are things like game balance, tuning. The projects are all board games and card games. So the entire class is done with analog game design. So we can actually get more detail into how rules work, how rules mix together.

We play a bunch of board games. We analyze them. And then we make board games.

It's very similarly structured to this class. It's team-based. You'll do four game design projects in that class.

There is CMS.610. That is Media Industries and Systems, the Art, Science, and Business of Games. That's taught by Chris Weaver from Bethesda Softworks. He worked on the Elder Scrolls series for a while.

His class is focused on the business and publisher side of the equation of game development. So if you're thinking about doing this as a professional career, at some point you're likely going to have to deal with publishers. Either you're going to be working for one, you're at a studio that will be working for one, or you will be pitching to one yourself.

So the big focus of that class is the pitch. How do you pitch your ideas to another group? And it's also focused on the demo. So if anybody's heard of the term E3 demo-- basically how to make your game look good even though it doesn't work.

Hopefully the game works at the end. But it's really focused on, what do you need in your game in order to communicate that game to another person in order to provide funding for your game? So that's CMS.610.

It's a really great course. He has a lot of really good war stories from what the game development process was like from the '80s on up.

And then lastly, CMS.617-- Sara and I teach that course. It's called Advanced Game Studio. It's basically an independent study, but with teams, to make games.

You spend the entire semester making a single game. Sara and I act kind of as your publisher, kind of as your mom and dad, kind of as your mentor. Basically we are there to help you make your game, and to help your game from start to finish. But you have something that you can either submit to a festival, you could show to another person, or put in a portfolio.

Before you start this class, you should be in a team already. So we'll be sending emails out about this. We try to do a few events in January for networking and for people to meet each other to form teams. But you could form teams with people you've met in this class and other classes.

I have a feeling that people who took this class last year are going to be looking for teams for this year. So there'll be some emails going out around December and January, and hopefully one or two events going on at the Lab in January about that.

Yeah. And then if anybody has any questions about if you want to minor in games at MIT, if you want to do a concentration in games at MIT, you can do that through Comparative Media Studies and Writing. You can talk to me about that after class. You can also go to the CMSW website and talk to Rebecca Shepardson about that, and what the requirements are for that.

It's comparative media studies, so it's multiple media. But games is one of those media that you can focus on and concentrate in. OK. So that is the advertisement part of this class.

So today we're going to finish up team formation. I'm going to introduce the Project 4 deadlines, which I briefly mentioned last week. And then we're going to start Project 4 today.

You've got a lot of time today to do brainstorming and to do prototyping in your teams. We're recommending, because you're going to have eight-person teams, breaking up into smaller groups to do some initial prototyping. You want to basically think of this as prototyping as a means of brainstorming to come up with lots of different kinds of mechanics and actually try those mechanics out, and play with them a little bit, before you decide on one.

We're giving you a lot of time to do this this week because we want you to have something playable by next Monday. So that's that. For teams, it sounds to me like we had five topics that were interesting to folks. Is anybody still interested in the malaria topic? OK.

Not malaria. Why do you let me come up here and talk to you? What was it? Ebola. Ebola, yeah. So nobody was interested in that. All right.

So I've got early warning leading to early action for heat waves, cholera prevention and hygiene, forecast-based funding, SNAP, and adapting to climate change. Even though we've got five topics, that does not mean we need to have one team per topic. We can have multiple teams doing the same topic. And that's OK.

So raise your hand if you don't think you're on a team right now. OK, that's a good portion of you. So what we're going to do is, just like last time, we're going to break up into groups based on the room.

If you're interested in the topic, go to that group. Talk with those folks. If you are in that group and you signed off, you said that you are definitely on this team through the mailing list, identify yourself to the group as yes, I signed up for this on the mailing list. This is what the team is so far. Here are the people on this team right now.

And actually, to help that through, what I'm going to do is put these on the board. And then I'll have people who signed up for that team come down first. And then everyone else come down.

So over here, let's do heat waves. Over here, let's do cholera, SNAP, climate change, and forecast-based funding. So if you are already on one of these teams, and you've said this is the team I want to be on, go to that area right now.

Ah, whatever. That's OK. All right, so heat waves-- one, two, three, four, five. Cholera-- one, two, three, four, five. Cholera? Six. Cholera, seven.

Are you-- standing up-- anybody here on SNAP? One, two, three, four, five, six, seven. OK, cool. If you're on SNAP, come on down with the rest of the group.

Adapting to climate change-- if you're on the team, or if you think you're on that team-- OK. And then forecast-based funding, if you think you're on that team-- one, two so far?

AUDIENCE: Everyone who thinks they're on a team, put their hands up.

RIK EBERHARDT: OK. All right, so if we're going to-- one, two, three, four, five, six, there's only six. OK.

So move to whatever team you're interested in right now. Talk with some folks. If you're on the team already, talk about some of the things that you talked about last week, brainstorming-wise. If you want to be on that team, talk with the members and ask if you can be on that team, basically. I'm going to check in on you in ten minutes to see what it looks like.

AUDIENCE: Right now it seems small enough that we could be one team. Also Liz wants [INAUDIBLE].

[SIDE CONVERSATIONS]

RIK EBERHARDT: All right. After this amount of discussion, how many people are still undecided about what team they want to be on? Kind of undecided? Anybody else kind of undecided?

All right, so if you are 100% decided, put your name on your post-it. Put it up on one of these things. Do it really, really quick. Come up. Put it up. Sit back down, please.

All right, so the dangers of having more than 10 people.

PHILLIP TAN: Yeah. So in fact, there is already dangers of having eight people or more. But this class was actually intended for you to actually feel that pressure, right? When you've got an eight-person team, you're going to have communication problems up the wazoo.

That table might tip. Be careful.

RIK EBERHARDT: It'll be fine.

PHILLIP TAN: Yeah. Your laptop's on it.

Once you get to a 10-person team, what we've seen from previous years is that 10 people and larger teams don't actually outperform six-person teams. They actually get about the same amount done.

RIK EBERHARDT: Or less.

PHILLIP TAN: Or sometimes less. Because the communication overhead actually breaks down further. You might get a lot of content done. And it turns out to be very uneven in quality, because you have multiple people doing content.

Now you could succeed in breaking your team up into little subgroups and be able to organize yourselves that way. But we've never seen it done successfully in this class with students with your level of experience. So what we will recommend is that if you've got something like 12 people-- or 13 people, now?

RIK EBERHARDT: 13.

PHILLIP TAN: Yeah. You will probably get more done by splitting into two groups. If you are deliberately brainstorming in order to take advantage of 13 people, then of course you're going to come up with a game that can only be executed by a very large number of people. What we're just saying is that those games have traditionally not done very well in our class.

They may be functional. They may actually deliver on the thing that you intended to make. But we've seen six-person teams do much more. Partly because they iterate a whole lot faster. And they may have smaller ideas. But the ideas end up being a whole lot more polished.

So that's our advice to you. If they really want to do a 13-person team, are we going to let them?

RIK EBERHARDT: Um, wow. Yeah.

PHILLIP TAN: Against our better judgement.

RIK EBERHARDT: Against our better judgement, we might. But what we're going to ask, I think, today, is to break up into two smaller teams for brainstorming.

We actually want all the big teams to even break up into smaller teams anyway to do some brainstorming and to do some prototyping. Once you have all that figured out, in class today-- by the end of class today-- you can decide how big you want the team to really be.

The one issue that we have, though, is we've got some people who are not in class today who will be coming into class. We've got the three that we talked about. There might be one or two more. If there are any other people like that, they will be automatically put on the smallest of these teams.

So I'd rather a six-person in cholera turn to seven, rather than an eight turn into nine. Because these eight-person teams are actually just good enough.

PHILLIP TAN: Yeah. The eight-person teams are just about the size that we were hoping for. Six-person teams, actually-- to be perfectly honest, I think the six-person teams have an advantage. But that's just how the numbers break down.

RIK EBERHARDT: Yeah. When we have seen a 10-person team actually work, what really happened was it was 10 people. Eight of them worked on the game. Two of them worked on the networking component.

The networking component did not work. Yet the game was still as feature complete as it could be without networking. It could work without the networking.

That's not what we're looking for. We want the game that you are submitting-- the game that you're creating, the design document that you're submitting to us on Wednesday, and the game that you're playtesting on Monday-- to be the actual game. All those features that you're saying are going to be in that game. We want that to be the actual game that you submit at the end of the semester.

So don't think of it as, well, if two people flake, then it's back up. It's not. If two people flake-- if you're too big, and you've got two people who don't know what's going on, and they cause some issues, it's just going to be a disaster for the entire team.

So this year, all of the Project 2 and Project 3 teams were actually bigger than we've done them in previous years. Previous years, they were about four people, maybe five tops. And we had you do six and seven, I think, right?

Did anybody feel like with seven people they got a communication method that worked really well? Like already--

PHILLIP TAN: I see-- what was the method?

AUDIENCE: [INAUDIBLE]. It's not perfect. [INAUDIBLE].

PHILLIP TAN: Yeah. It's the sort of thing that-- whatever method you use will definitely improve with practice. So if you've got something that sort of worked well, that's something you try again. But the fact that most people didn't should already give you some warning of what a large team is going to feel like. It's going to be tough.

RIK EBERHARDT: For the structure of the class, on Wednesday we're going to be talking about more of the requirements-- the aesthetic requirements-- for Project 4. We'll have basically another design discussion next Wednesday. On Monday we're having a short design discussion about educational games.

And then we'll have one of our first discussions trying to talk about some of the person-to-person issues we see in making games. In this case, it's team dynamics, and how to identify team dynamics. We'll have a couple more talks like that to kind of help you get used to running in a bigger team. But between now and next Monday, we're hoping in class to give you plenty of time to actually work on some of it.

One of the biggest issues with working in a big team is just figuring out, what is that core thing that you're actually making? What's the thing that you're trying to communicate to each other? We've talked about how you can use the division document for that, and how you can use the actual prototype you make for that.

But often, it is just having everybody in the same room at the same time talking and just working together. So we're trying to give you as much time as we can--

PHILLIP TAN: In class. because it's hard enough to get six people outside of class to meet up, let alone an eight-person team. Right? So we're going to give you more time in class to meet up with each other.

That does not mean that you should be spending all your time in class planning on getting your face-to-face coding done. That's actually a waste of time. Because you could be talking to each other. You can use it for things like code reviews.

RIK EBERHARDT: Yeah, code reviews, stand-up meetings-- things like that. All right. So we're going to put this on hold for a second.

I'm going to go over, very quickly, the deadlines. And then we're going to take a break and come back. So if this will move forward-- all right.

So why did I react so strongly about the Animal Crossing, all these sorts of mini-games? It's because of what we're asking you to do-- whoa. Don't do that.

So what we're asking you to do is create a small, fully functional, polished browser game. One of those many games would count as a small, fully functional, well-polished browser game. And we're asking you to use the design iteration techniques you've used in the past.

What does that mean? We're actually talking with the same design scope as the previous two projects. It's just you've spent more time on it to actually get it working exactly the way you'd want it to work.

It may be slightly larger. So if your previous two products had maybe one core mechanic and one supplementary, there might be two supplementary mechanics to that core. But that's about it.

If you've got a game that has an overworld, then the overworld should be the bulk of your game. If the mini-games that you decide to make are the same size as that overworld in scope, that's already way too over-scoped, if that makes sense.

It's an eight week project. You've got about two weeks to concept and prototype multiple game experiences. So what we're asking for today and tomorrow, or on Wednesday, is you're not just prototyping one game. You're prototyping lots and lots of different little games. You're looking at all of those games. You're actually going to have time to spend on multiple different prototypes, rather than just a single prototype that you iterate on.

So what we're asking is if you've got an eight-person team, break yourself into two groups of four, four groups of two-- create some really small, board-gamey-looking things, some very small interactions. Maybe they're playable. Maybe they're something you just describe.

But really go big blue sky. And try to think of all the different things that can happen. Because these topics that you're dealing with are very large.

Make sure that your design is grounded-- very, very well-grounded-- in the sources that we've been given by the client. There's going to be multiple times that they'll be here to see your games and talk about your games. They'll be on your email, so that you can ask them questions about that as well.

So design constraints-- use all the mechanics that we've been practicing in class with your previous projects.

PHILLIP TAN: Not all of the mechanics simultaneously. Use any of those mechanics.

RIK EBERHARDT: Any of those mechanics. So it could have trade-offs. It could have randomness. It is not required to have both. It's required to have whatever it takes for the topic that you're working on, whatever makes sense for the topic that you're working on.

Those top two tend to be in the realm of what those topics kind of lean themselves towards. But if you find something else and you want to use that something else, great. Spend some time really working on it. Spend a couple weeks working on it before you make a full commitment.

So your target audience-- each of those topics has their own target audiences, which they talked about. The top three are the ones to really focus on, depending on your topic. So Red Cross staff and volunteers-- people who are knowledgeable and motivated about the topic already, who just need a little bit of extra information-- community organizers, and then youth-- people who are motivated, but maybe not knowledgeable about the topic.

Again, the other requirements-- we are holding you to these. Maximum play length of 10 minutes. Single or multiplayer game. Test your user interface well. It must use and play audio for the player, unless audio is absolutely not required for your design.

If you design really does not need audio, then don't use audio. But a, if it's a web browser experience, there probably should be some way to use audio as a method of getting feedback to the player. So it could be as simple as a ding when something happens. And that's OK for this project.

What matters to us is that you have a unified aesthetic, which we'll talk about on Wednesday, what exactly we mean by that. And then also we're asking you to give design thought to spectating users. In the final presentation, you're going to be presenting the games on the projector. People are going to be watching the game as it's being played.

They should be able to understand how the game is worked, just by watching it. Maybe they might need to watch it one or two times to figure that out. But they should be able to figure out, what are the things that are going on in the game? And how are all those interactions happening?

So your deliverables-- that was from up till now. So on Wednesday, turn in to Stellar a high-level design doc or "back of box" copy-- the same form we've been using previously. It's some kind of vision statement that says at this point, these are what we think the features are going to be.

If at any point you make a significant design change that says, our feature list is going to change, our game is going to look different, update that document. You have up until the end of the semester to do that. And whatever you turn in-- whatever that document is on the last day of class should be what game you're turning in.

So that document and the game should have the same features in there. But we would like to see any changes that happen between now and then. We'd like to see how those changes happen and why. So reflect them in that.

On Monday, turn in a product backlog. You're going to do a two-minute presentation-- the core of your game design idea. And then we're going to do a playtest.

On the 27th, we are going to have at least one, possibly two, of our clients in on that day to play those games. Jano and Jared-- both of them came in for the first day of class. They were not in class when Pablo was on.

We are asking for some kind of Sprint tasklist to be submitted to Stellar weekly. What exactly that is is completely up to you. We've given you a format that we like. We've given you a method that we know works.

If you decide to change that method, let us know what you decided to change it to and why. But whatever you have-- every week, I should be able to go to Stellar and see what tasks you have to do for the next week's worth of work.

We are asking for product backlogs. That's actually a concrete. Please give us a product backlog. The

Format you use for the product backlog doesn't matter to us-- the feature list, if it's a list of user stories. What matters is that all the features that you think are going to be in the game are listed. All the features that are done are listed as done. And you've done some kind of estimation on what size those features are.

And then we're going to have you do two-minute presentations in class. And all these dates are in Stellar, in the Stellar calendar. So the next two-minute presentations are also on November 12 and then November 26.

Any questions so far about any of this stuff? All right.

So the project is due on Wednesday, December 10. On Stellar, turn in all of your previous builds, your written postmortems, your design change logs, your updated document. And this time we're asking you for focus test reports.

There are in-class playtests on the 27th, the 5th, and the 24th. Two of those can be used for focus test reports. The other two must be external.

And then, yeah. We're going to have postmortem presentations. So on postmortem presentations, instead of five minutes, you're going to have 20 minutes.

We're asking for a polished presentation of the work that went into developing the project-- all of the iterations that you made. So we want to know about your design iterations in this presentation. We also want to know those five-- what went right, what went wrong, what was interesting in the project. So that's about 10 to 15 minutes given on process, and team management, too.

For all of your games, someone who hasn't played the game before will play the game live on stage. So that's basically one way for us to see somebody who hasn't played the game before try it out and see how it works.

AUDIENCE: Who's in charge of acquiring the person who hasn't played the game before?

RIK EBERHARDT: It's a little bit of you and a little bit of us. We'll do the best we can. So we're asking guests to come in. We're hoping our clients are going to be in. Some of them might have already seen your games before. Some of them haven't.

If you have friends, we actually suggest you bring in friends to come in and to watch the presentations-- maybe not play your game, but play somebody else's game. But we open the final presentation to the public.

We have a rehearsal on Monday the 8th. And we have the final on Wednesday the 10th. So on Monday the 8th, you don't need to do the play the game part of the rehearsal. But you do need to do a full dress rehearsal of the entire presentation.

And the reason why we're doing that is we're going to give you feedback on that, on what you might have missed, and what we'd like you to see in the presentation. And you've got a couple days to apply that feedback to your presentation and to make it better, basically.

And I think that's it. Yeah. That's all from the other day.

So any questions about the postmortem presentations? Previous years-- I'll send out the link to previous years, so you can see what these tend to be like. But we've recorded them in the past. So you can see what other people have done. And that'll go to the Announcements page on Stellar.

All right. It's 1:50. Take a 10-minute break. Come back at 2:00. And work in your teams.

PHILLIP TAN: So the rest of class today is pretty much for you to figure out what is this project, and get working on who you're going to be working with and things like that. So what we're going to first do is the typical brainstorming process.

We're not going to guide it so much this time. But just a quick reminder-- you want somebody who is in charge of facilitating it, which means reminding everybody what the problem is, and also calling out people who may have trouble getting their words in front of the group, like people who are trying to get in a word edgewise-- so basically moderating a discussion.

And someone, of course, should be taking notes. We have our giant pads of paper in front. You can use chalkboards.

For the cholera team, we suggest splitting in half. But that doesn't necessarily mean that your brainstorming team is necessarily your game team. What we are thinking is that after brainstorming you will better know whether your ideas can be split into two projects or not.

Given how many cards disappeared on there, we really, really, really recommend that you split in two groups. But there may be a more organic to split that. Because your ideas may actually fall down on a more clearly defined lines. I noticed that you already did some brainstorming up there.

But think, what would you do with half the size of the team? Then after that, have the discussion about who is on which team.

By the end of class today, you should know exactly who is on your team, how to get in touch with each other, what your email addresses are, what your phone numbers are, or instant messaging handles or whatever. And make sure that you've figured that out. Let's see.

One thing that I wanted to tack on to Rik's presentation earlier about the expectations for the postmortem-- we brought up the person who has not played your game before coming up and actually playing your game. And I know some of you might be worried about that. Do be aware that however well or badly that person performs, no matter how much they like the game, or completely misunderstand what your game's about-- that is going to be, at best, 1.5% of your total semester grade.

That's not really significant. It's not going to really swing anything. So don't worry about it.

But we are actually using those sessions to gauge usability. To what extent have you actually designed a game to make your game easy for people who've never seen your game to get into it? These are the things that we want you to be iterating on. These are the things that we want you to be catching for.

And without having a real-life, high stakes-- there is going to be a person who hasn't played your game in front playing your game-- you may not take it so seriously. So we want you to be taking usability really, really seriously.

That's why Rik said, the scope of the game doesn't necessarily need to be all that different from the past. But the amount of polish, the amount of time that you've thought through your UI-- it's what you should be spending all your time on.

Finally, we're going to go a little bit more into games for learning in the next week. But one thing that we want you to be thinking about while you're brainstorming is, of course, what is the player doing? Now if you're trying to teach something to someone, if you're trying to get them in a situation where they're learning about a certain concept, it is ideal if the thing that you are trying to teach them is actually the thing that they are doing.

Now there's a couple of other ways-- actual, can we bring up Constantine's slide? Sorry. The dongle's there, too.

There are a couple of other things that you probably are already considering putting into your game. Things like, what is the theme? I noticed the brainstorming for the cholera already started talking about things like story line. So does the theme of the game actually match not just the topic that you're trying to teach, but also the mechanics that you're designing for it?

You want to be thinking-- and a couple of you have already been asking-- about things like, who's going to be playing your game? What's the demographic? Also be thinking, what situation are they likely to be playing in?

Are they likely to be playing it on their own at home? Is what you want to design for? And you can specify this. You can say, this is a game that's meant to be played by an individual person with an individual computer on their own time. Or this is meant to be played in a group like the SNAP game was played in a group, in front of everybody else.

And that, by the way, falls into the framing idea. What is the context in which someone's actually going to be playing the game? To what extent have they played games like what you're describing?

If you are making some sort of hard core strategy game, to what extent do people need to be familiar with strategy games in order to be able to play the game? Or do they just need to be familiar with things like Facebook games, for instance? Or do you really want to make a game that doesn't assume much play literacy at all?

You want to be looking, of course, at the data, and that means all of the material that we provided you, as well as any information that you're looking at in Google searches or academic research, or information that you're getting from your domain experts, from either the Humanitarian Response Lab or the Climate Centre. Is that right? Yeah. So make sure that we are representing that as fairly as we can.

Because this is a game, you do have liberties to at which point you can sort of abstract out those numbers. Maybe they're not mathematically very, very precise, because you're trying to get a sudden feel of the game. And that, of course, goes into the aesthetics part-- not just the graphical aesthetics, but the way how your game feels.

If you're trying to represent a really, really tense situation on the ground, and the way how your data model makes it resolve makes it feel like your game is really clinical, and it's very, very easy to deal with the situation as long as you know the tried and true formula, then you're not accurately representing the situation. Even though you may be accurately using data. So make sure that you're balancing that aesthetic feel together with the content and whatever real world facts you're putting into your game.

Because these games are all really about real world things, you might want to make sure that your fiction and narrative is something that's not too fantastical. Or at least, if there is a fantasy element of it, it is the part that has least to do with the believability of the things that you're trying to communicate.

You can say that there is a village or a city that's dealing with a cholera epidemic or something, and that's not a real city anywhere on a map of the world. But you can look at that city and imagine this could be a real city somewhere in the world.

You could go as far as saying, OK, this is like the dark ages or something like that. Because the disease has certainly been around for a long time. But you want to be able to keep reminding people that this is a real thing.

If you say that this is a science fiction thing where you're on a different planet and it's a completely different kind of bug that behaves exactly the same as cholera-- I'm starting to feel that maybe the fiction that you're creating for your game is undercutting what you're trying to get this game to do, which is to actually teach something real.

RIK EBERHARDT: To jump in on the fiction narrative-- so things to think about. Your games are being played by a specific culture-- people with a specific cultural background. Especially the cholera game will likely be played by-- I believe it was Ghana. Yeah, it's Ghana.

So students who are in Ghana-- what kind of culture do they have? You're going to have to research that and figure that out for those games, to figure out what kinds of common backgrounds might they have that you can talk about.

For the heat waves game, that actually has more of a focus on Red Cross volunteers and university students. You can specify, we understand that the people who are playing this game are likely going to be from Europe. And they're likely going to have this kind of background.

When you're creating your high level game design document, come up with what you imagine your target audience to be, so you have some kind of cultural background to use. Again, you're choosing fiction that is going to be so supportive and helpful, and not fiction that might be not known or might undermine the idea.

One thing to keep in mind with the fantastical-- studies have found that some games-- when it comes to pandemics and outbreaks, using the zombie fiction actually can work sometimes. There is something to be said about using a common fiction that people know. People can say, all right, I understand how zombie pandemics work. Because I've seen all these films about it.

Whereas if you just told me it was a disease, I might not have seen enough films that had anything about how disease actually spread. So really think about what is your problem? What fictions might be useful? What narratives might be useful for the problem that you're fighting?

PHILLIP TAN: Use fiction to keep the topics relatable. And if that means drawing on things in popular culture, that's great. That's a tool in your hand.

Don't use fiction as a way to paper over design problems, which I've often seen. You know, if we set this game in space, then we can sort of skip over all reality, or something like that.

When you're brainstorming, make sure you know what you're brainstorming about. Are you brainstorming mechanics? Is it about what people are going to be doing? Are you brainstorming what the fiction is going to be?

I would say do a separate brainstorming session for each one of these things. Maybe just spend 10 minutes. You don't have to brainstorm every single thing that we're showing you here.

You could brainstorm what is they aim and impact that you want to achieve in this game? How are you going to do that? Are all of you even on the same page about what you want your game-- the kind of change you want to see in the world?

And that's going to be your purpose. That is going to be-- do you all understand what this thing is? A lot of it has been defined for you. But I'm not guaranteeing that everybody on your team necessarily shares the same idea. So the brainstorming process might be able to get that out.

And at some point in time within the next couple of weeks, you should have a pretty good idea. You should have had a chance to at least talk with your team about every one of these elements. This is a research framework that's been put together by one up our colleagues, Constantine [INAUDIBLE]. I think we can put a link to this.

RIK EBERHARDT: Yeah. I'll post the slides, and this particular slide, to Stellar.

PHILLIP TAN: And we might get back to elements of this later in the week. But right now, this is just basically something to help guide your brainstorming.

RIK EBERHARDT: Yeah. Aesthetics we're recovering on Wednesday. Fiction we're covering in a couple of weeks.

PHILLIP TAN: Finally, one reminder about brainstorming-- if your brainstorming session runs more than 10 minutes, you'll want to flip your secretaries around. So that somebody else is taking notes. Let the person who's been frantically writing things down actually get their ideas in, too. OK?

We're not going to time that for you. That's going to be something for you. And once they've got their teams, email, video game bosses?

RIK EBERHARDT: Put your vision statement-- it should have all your team and all your member names in it. And that's due on Stellar on the date that it says, on Wednesday.

PHILLIP TAN: So put all your names in the vision statement. The rest of class is yours.

 

Free Downloads

Video

• iTunes U (MP4 - 89MB)
• Internet Archive (MP4 - 89MB)

Subtitle

• English - US (SRT)