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.