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.
PROFESSOR: Schedule for the remainder of the semester.
Today is a short week.
Normal day today, slightly different day on Wednesday.
I'll talk about that in the lecture today.
Basically we hope to have the official class ended by 2:00pm.
So 1:00 to 2:00 will be class on Wednesday.
After 2:00, working in your groups
or taking off early if you need to take off early
for a flight or whatnot.
So it's up to your teams, whether or not
you're working in here or not on Wednesday.
This is also going to be the last lecture by us,
I believe, on the schedule.
Next week we've got two guest lectures.
One, on December 1 we've got a panel
from the Indie Game Collective.
They're going to be talking to us about the business of making
Indie games.
Two people who have their own businesses, their own studios,
and how their studios work together.
So that should be interesting for you.
And then on December 3, on that Wednesday, we
have Sean Baptiste from Fire Hose Games talking
to us on marketing, communication, and community
management for games.
Because we're seeing you can't just put out a PR release
and buy some advertising, you need
to build a community if you're making games professionally.
You need to find your players, because there's
lots of games they could be playing besides your own.
So he'll be talking to us about that.
The week after that is entirely based
around your presentations.
So December 8 is a rehearsal in class, live reversal
with your game.
If your game works on that date-- hopefully
it will-- but definitely your slides
and your spoken presentation.
We will give you feedback, you will then take that feedback,
improve your presentation, improving your grade,
and give it as the final presentation on Wednesday,
December 10.
At the end of the class on December 10 it'll be open play.
So after all the presentations are over
we're going to have some guests here.
You'll be able to open your laptops
and play each other's games and have guests play your games.
So that should be fun and exciting,
and maybe a little scary, which is good.
So plans for today then.
I got caught on that-- not 5 minute, but 2 minute
presentations.
Basically short, informal presentation
just like we did a few weeks ago, I believe.
We'd like to know about the status of your game, what
features you're working on, what features are not
being worked on right now, what features
might be dropped and cut, and I'd also like to see your game.
So if you have got one person talking,
maybe another person showing the game, maybe playing the game.
This could be what the game looks like today.
This could be the version of the game you tested last week,
but have something show-able, something
visual for us to see so that we can-- when you're
talking about your game we understand
what you're talking about.
With no slides, of course, for this presentation.
For presentation on 8th-- on the 10th
that is more formal, slides, all the good stuff.
There's a description about that in Stellar
and we'll talk more about that next Monday.
After that I'm going to give a short, about 30
minute, lecture on cutting features,
some strategies on how to do it, why you should do it,
things like that.
Might be obvious, may not be obvious.
After that is work in class.
Pablo is here to give you feedback on your games,
so we'll be giving you feedback on your presentations.
If we have questions about what you just talked about,
but also he'll be going around and available for each
of your teams to talk about the status of your game
and what's going on with your game.
That is class today.
Any questions?
All right.
So it is 1:10.
Are all the teams feel ready to give presentations right now
or do you need a couple minutes?
AUDIENCE: Couple minutes.
PROFESSOR: Couple minutes?
All right.
So we're going to give you 5 minutes.
1:15 I'm going to come back up here and Snap
is going to start.
TEJ CHAJED: All right.
Hi everybody.
I'm Snap-- I'm from Snap.
I am not Snap.
I'm Tej.
And so we've made a lot of progress on our game
and we've been able to run it a few times,
but it has not changed a lot since probably anybody who's
played the game has seen it.
So I'll just go ahead and play one round of the game
just to show off what we currently have, and then I'll
talk a little bit about what we're
planning to do in the future.
So everybody from the team, you want to play?
And can somebody start the game?
AUDIENCE: I got it.
TEJ CHAJED: All right so the way this game works is we're
going to throw out a topic.
In this case it's animals.
We're all going to try to enter as many animals
as we can think of, and we'll get points whenever two of us
enter the same animal.
All right.
And they can obviously all cheat, but let's--
AUDIENCE: Wait, we already started?
TEJ CHAJED: Yes, we started.
Obviously I would not be showing this normally.
This is a little bit easy to cheat on.
AUDIENCE: [INAUDIBLE]
TEJ CHAJED: Although we've had some other forms of cheating.
When Andrew was here, they just entered A, B, C,
in a row next to each other.
Anybody want to help?
AUDIENCE: Cow.
TEJ CHAJED: Cow.
I guess this is also cheating.
AUDIENCE: Lemur.
Snail.
AUDIENCE: Scorpion.
AUDIENCE: Amoeba.
AUDIENCE: Jaguar.
AUDIENCE: Chicken.
[INAUDIBLE]
AUDIENCE: Pig.
AUDIENCE: Paramecium.
AUDIENCE: Veal.
[LAUGHTER]
TEJ CHAJED: Veal is not an animal.
I guess baby deer is.
AUDIENCE: Geese.
Human.
TEJ CHAJED: All right.
So I think that gives you an idea
of how this game plays out.
Can somebody stop the game?
AUDIENCE: I got it.
TEJ CHAJED: So right now we have--
AUDIENCE: [? Yes. ?]
[LAUGHTER]
TEJ CHAJED: So right now we have the game completely
manually controlled.
And this is because current use case-- in our current use cases
for the client we've been playing
the game with a limited number of words input
and without a time limit.
So we let the client just implement
whatever time they want by starting and stopping the game
appropriately.
But we plan on also supporting an actual strict word
limit as well as a natural time limit that can
be displayed on the front end.
We initially went with Phaser because we
had a much different idea of how we would represent the game.
But we ended up focusing more on words
and, like, a more bare-bones representation.
And so we're actually going to remove Phaser.
Right now this is a Phaser window,
but it's not really helping us at all.
We're just entering words into a list.
So we're dropping all of that and moving
to just normal CSS, HTML.
We are also planning on-- we've experimented in our thought
processes about what sorts of ways
we want to show scores and activity.
We want to be able to show not just what words you're scoring
and submitting, but also when are other people submitting
words, when are other people scoring, how am I doing
relative to everyone else.
So we have a couple ideas around that.
We also would like to show you a word cloud in real time.
We currently have a word cloud for the back end.
So this is the game we just played.
And this is a-- and this is something
that you can watch actually as a moderator,
while you're playing, in real time.
And then here's another game which
is an actual game that the client ran in Berlin a week
or so ago.
So that was kind of cool that we actually
were able to do a real playtest with the actual client
in the real world.
But in the future we definitely want this
to look more interesting and to feel more competitive.
We want people to be able to see what else is going on
in the game, whereas right now you really can only see
your scores.
Any questions?
AUDIENCE: [INAUDIBLE] questions or comments, [INAUDIBLE].
AUDIENCE: What's your biggest risk right now?
Like, what's the thing that's most catastrophic?
TEJ CHAJED: I think since we're switching
the front end over to sort of new technology we need
to make sure that a, that transitions over well,
and b, that we have enough time to finish something
new and useful rather than just reverting back
to what we have now.
AUDIENCE: How does Snap happen?
TEJ CHAJED: So we have a server that
is receiving all the words.
And whenever it gets a word it adds it
to a list of words for a player.
And then every time it gets a word it also
checks against all other lists.
AUDIENCE: So it's basically any other player
types the same word?
TEJ CHAJED: Yes.
In the same game.
So for example, the game is now over.
If you started a new game, that's
an independent word list.
Yeah?
AUDIENCE: Just for curiosity, so let's say you put in "dog"
and [? Priam ?] put in "dog" and then Sam put in "dog"--
TEJ CHAJED: Everybody gets one point right now.
We're thinking of changing that and letting
people get more than one point, or maybe even
making it configurable.
Most likely-- intuitively it seems
that you should get more if more people have entered the word.
PROFESSOR: Thank you.
TEJ CHAJED: All right.
[APPLAUSE]
PROFESSOR: Next up is Awesome Cholera.
Yes, that is not the real title.
PABLO: While Awesome Cholera or other real title shows up,
we will have a long conversation about details,
but I'm very excited about the fact
that it's already being used and working.
And now the question will be how many features
you want available to the [INAUDIBLE] player.
And that selection process will be
based on both client need, playtesting, and also
your ambition on how much can be accomplished in this time.
[INAUDIBLE]
STUDENT 1: Do you want to do the talking?
STUDENT 2: Yeah.
So this was the last build to the game we playtested.
We hadn't changed a lot.
We tried to add instructions so that people
kind of knew what was going on.
And this is running, right?
Can you click Start?
So right now this is what people saw. they saw their villages,
and some health bars.
It was still kind of unclear.
And over here you can see, like, the text is still really small.
And when people clicked something
to do education or something they either
thought that, like, when they clicked that button
it instantly did it.
They didn't know that was a button--
like Educate About Soap was a button they could click.
Also we had this really terrible pop-up bug
that we're still trying to fix, but hopefully that'll be fixed.
And so because we were having so many problems with the GUI
we finally sat down and tried to redesign it.
And so I haven't actually-- we haven't done this yet,
but here are some really great drawings-- A plus,
I said-- of what the new GUI will have.
So above each locality we're going to have this little box.
I kind of stole it from [? Civ ?]
and a few other places, but-- So it's
going to have the name of the locality.
And it's even worse because it's going
to look different from what this is because we've already talked
about how we want to change it.
And so behind the work locality is going to be a bar,
and the bar is going to have a percentage
green and a percentage red.
And the percentage green will be the percentage
of people in that locality that are healthy,
and the red will be the percentage
of people that are unhealthy.
Above that-- sorry.
Above the word Locality, there's a little arrow that represents
the infection rate, which is something--
a lot of people used that word and thought that was
the information they were getting, but they weren't.
They were getting the percentage of people infected.
And so a lot of people wanted to know
how's the infection rate being changed.
And so we're going to have an arrow.
And right now it's just going to be, like, up if it's positive,
down if it's negative.
But we want to also change it so that they can tell
the magnitude of that as well.
But we're also trying to keep it so
that people aren't getting too many numbers thrown at them.
So we're still trying to iron that one out.
Below the Locality are a bunch of symbols
representing the different things you can do.
What we thought we were going to do
is if you've implemented them they'll be there in color,
and they'll be counting down so you know how much longer
that will be in effect.
And they'll also have a gold ring around them or something
to say, like, if you've educated [? them ?] about it which
means it's more effective.
And then the other screen is the screen
you get when you click-- there will be a little thing that
says Aid Locality above the Locality thing
for each of the different localities.
And over [? on this ?] screen-- [? which ?] [? got kind of ?]
messy-- but it'll show all the things you can do instead
of just the ones that are unlocked,
because a lot of people didn't know that things unlocked over
time.
So we'll have it showing everyone,
hey, these are all the things and they'll eventually
unlock, either over time or if you do a certain thing.
And there will be two columns, one
for educate and for prevent.
And as you mouse over everything on the right-hand side
of the screen, the description will come up
telling you about the effectiveness and the duration,
and giving you a description of what it's doing.
We're hoping that this'll make it more clear
as to what everything's doing, and it'll
be easy to read chunks.
So if they want to know more about it
they can mouse over it and just kind of read it.
Or if not they can just kind of quickly say,
hey, this is pretty effective but the duration's
short so I'll just use this for a bit because it's cheaper
and then maybe I'll use the thing that's
even more effective and has a longer duration when
I have more money.
The other thing on the map that I didn't scan yet
is, on the map, on the very top of it,
we're going to have a bar that tells you about what day it is
and when you're getting money, because a lot of people
were like, why am I getting money?
And they didn't know time was passing.
So we want to make all these things clear.
And so I think the GUI redesign will help with that.
Hopefully we should have it done after Thanksgiving.
But yeah.
That's where we're at right now.
Any questions?
PABLO: I have one, but you guys first.
Anybody?
STUDENT 2: Yeah.
AUDIENCE: Is your goal for people to win this game
and then have done the right things?
Or is it for them to lose the game
and then, based on that know what the right thing they
should have done is?
STUDENT 2: Right now the game's really hard,
and it ends up you kind of lose if you just leave it alone,
which is not what we wanted.
STUDENT 1: As you saw, earlier, it just went to game over.
STUDENT 2: We want them to realize the different things
they can do.
I don't think it's going to be superbly challenging right now,
is what I'm imagining.
Because you don't want people to do these things
and then be like, oh, these things
obviously don't work because I keep losing the game.
We want them to know that, like, hey, if I do these things
it will help.
And so that's what we're trying to get across.
STUDENT 1: Another idea I think that we're not communicating
effectively but [? is ?] [? an ?] idea we also want
to communicate is that the position on the map is
important.
So like if the village is-- upstream villages--
stuff you do there compounds to the downstream villages
just because, like, the water, you know-- if you're not
treating the water correctly in an upstream village
that water is going to be contaminated down
to the downstream village.
And at the end we also want to communicate through this game
is that, like, if you focus on the upstream villages
you'll have better results in the long-term because--
AUDIENCE: So I guess how would I discover that?
Is that just playing the game many, many times?
STUDENT 1: Exactly.
So that's something we have yet to communicate.
And we should figure out a way to communicate that
to the audience.
PABLO: So thank you.
Good luck reconfiguring the things
that need to be reconfigured.
My intuition is that you would be better off [? amputating ?]
choice, and leaving somewhere very visible [? other ?] that
says, these are other things that could be done but are not
represented in this game.
Because otherwise it will be just too [INAUDIBLE].
And unless you make a really awesome game
that people want to play and play
until they've tried everything, it can be too intimidating.
STUDENT 1: OK.
PABLO: One of the options for your consideration--
because right now you have the options of soap
and the latrines and vaccination and so on-- you could reduce it
to the things that the player, the macro-decider
could do in terms of public awareness campaigns.
So it could be about [INAUDIBLE] the water,
about washing your hands campaign and maybe
one more thing.
So limited to three things that are of the same kind--
you know, radio advertisement or sending people to [INAUDIBLE].
And maybe less villages.
Again, just reduce choice.
Reduce features so the gameplay experience is more engaging.
I just want you to know this is also
applicable to the other Cholera team.
The Ghana team is now really interested in promoting hand
washing because it's beneficial both to cholera and to Ebola,
which is a serious threat in the area.
So you are [? already know ?] doing what you're doing
and if hand washing does not fit in the game, that's fine, OK?
You are doing what we asked you months ago,
not what we say now.
But if you find a way to make hand
washing fit as one of the choices,
it's much better than having three vaccination
choices and two moving waste choices and stuff like that.
STUDENT 2: OK.
PABLO: Good.
And good luck.
STUDENT 1: Thank you.
STUDENT 2: Yeah, thank you.
[APPLAUSE]
PROFESSOR: Hello Waves.
STUDENT 3: Our game is called Hello Waves.
We don't have the title screen in yet,
but the idea is still forecast-based financing.
So it's a little washed out on there.
But if you can see there are these five different sand
castles with workers associated with each.
And up here in corner we have a forecast
of what the water level will be like in a couple days.
This is the water level right here, and throughout the game
it'll rise and fall.
And the idea is not to let your workers get
drowned by the rising water.
The other aspect of the game though it
that you have a certain amount of supplies
and whenever you move someone from their castle
in order to prevent them from getting
drowned, they will consume supplies from that stock.
And if you don't have enough supplies then
they all take damage.
So as you can see, right now everybody's
in their own castle.
If we click Next Turn the water level will change
and we'll see that the forecast will update.
We have a range of values on this forecast,
a high prediction and a low prediction,
and if you mouse over any of the castles
you'll see a red line appear on the forecast
just to help you orient what heights are on the forecast.
Or if you're looking at the forecast, what
it is in the real world.
So you can see the water move.
For these couple days right now the forecast is pretty low.
If we see that's kind of getting close
and we're worried about someone we can click and drag them
to another castle, and on the next turn they'll move over.
You can also click people to toggle
between building and gathering.
It's very hard to see the status text
right now because it's small.
We threw that in quickly for right now.
But he is set to building and these three
are set to gathering.
So we'll see that each turn these three will
gather one supply each.
This teddy bear will consume one,
so we'll see supplies go up by two,
and victory progress will go up by one.
What we have planned for the rest of the game
is we've made a lot of progress in terms
of the intuitiveness of the game, once you understand it,
but right now, there's a lot in the game that isn't
explained from the get-go.
And so if I give that spiel to anyone
they can play the game fine and they do pretty with it.
But if you just open up the game, you're lost.
So a lot of our work is going to be on the UI,
of making things more self-evident
and making sure that people can understand what's going on
and what their actions will do without me having
to stand there and tell them.
PROFESSOR: Any questions?
All right.
So I'm going to ask you again, what is the biggest risk going
forward?
STUDENT 4: I mean, I think in terms
of our technical implementation we've already
got good playtests of our work done
and we have, like, all of our major graphics in
and things like that.
So I think our major risk going ahead
is not being able to explain the game properly.
And so even if we have finished product
it may still not be playable if we
don't write good introductions.
PABLO: All right.
So on that front think of incremental additional
features.
So the games with the super simple, even
maybe too boring choices, but then a new choice arrive.
So the learning be playing can be
staggered in a way that is [? enjoyable ?].
Good.
Good luck to you, and we'll talk more about choices later.
I should say that this high versus low prediction
is something that I wish scientists did,
like you're doing.
Because most people say one value,
then it's not that value [INAUDIBLE]
earlier that [INAUDIBLE] forecast.
Good.
Thank you.
[APPLAUSE]
PROFESSOR: Heat Wave, come on down.
STUDENT 5: So the main things that Heat Wave
is focusing on right now are playability and education.
As you can see this is our start screen.
It doesn't have any instructions.
It's very lame.
We're completely redoing that.
We're also redoing our end screen and our forecast screen
because we want visual consistency and just
overall improved playability by making
the gameplay states more clear and more connected
to each other.
The other thing we're working on is we don't currently
have an explicit end condition.
You kind of just play for however you want to play,
and we're going to add in like a something happens
that eventually too many people faint, get heat stroke,
the game's over, so you have more
of an incentive to play well.
And then finally something we're working on is user investment.
So we are actually-- where's my mouse?
Sorry.
We are currently working on redoing pretty much all
of our character graphics because we
think that having better character graphics
will make the game more intuitive.
So one of the ways you play this game, if you haven't played
it before, is you have a bunch of characters--
I'll show in a second-- and you click
on them based on different characteristics to try
and offer them water or tell them,
maybe you should go inside, it's really how out today.
And different people will react differently to you.
And right now you have a bunch of characters--
where's my mouse?
And I'm going to play this.
They all look pretty much the same.
And we have labels--
[LAUGHTER]
Uh, you're already laughing.
Did something--
AUDIENCE: There was a flare.
STUDENT 5: Oh, yeah.
So I'll talk about that in a second as well.
[LAUGHTER]
So we wanted to increase emotional investment
in this game.
So one thing I talked about was an explicit end condition.
The other thing is-- we know that setting on fire
is extreme and, at this point, kind of funny.
We all just laughed.
It's not meant to scare you, but it is meant to make you care.
Before, we just had people disappearing.
And, number one, people didn't know that people
had disappeared on the screen.
Players were like, what happened?
Suddenly there are less people.
And then they'd get to the newspaper scene
and they'd say seven people have fainted.
Nothing.
So we added the fire just as a somewhat comedic element,
somewhat just emotionally investment element.
I don't want my people to get set on fire, you know?
So that has to do with playability.
And also the same thing with the graphics and the fire,
is education.
We wanted to make this stick with people long-term
and we thought that maybe having,
like, a more surprising reaction to them not doing anything
would make it stick with them.
Something else we're working on [? with get ?] education is we
need better and more dialogue.
So we redid the backend of our system for dialogue,
and it doesn't-- uh-oh.
Sorry.
I'm really bad at this.
We redid the backend so that it would support better choice
trees.
We haven't actually added the content yet,
which is something we're working on right now,
but we have the whole backend working
so that you can make decisions that actually really do
effect what happens next.
Something people complained about throughout
is they felt like their decision weren't having an impact.
That's going to be a lot more clear now.
And then finally we're implementing on setting up
longer-term choices.
So right now you can click on people
and you might talk to them and they might not
accept the water, they might accept the water.
You might have a discussion with them and make them drink.
But we wanted to have longer-term choices.
So what if you wanted to set up a public water fountain
or something like that?
And another thing that we're talking about
is setting up umbrellas and it might
be worth more of your time to just,
you know-- the forecast for the next day
it might say it's going to be 108, but today it's only 80,
so let's set up a water fountain today
so that tomorrow all the people can just get water and be
a little healthier.
So that's the two things we're focusing on,
playability and education.
And we still have a lot of work to do, which is obvious,
but we've done a lot of the backend work already
and we think it's going pretty well.
Any questions?
PROFESSOR: Questions anyone?
STUDENT 5: Yes?
AUDIENCE: [INAUDIBLE]
STUDENT 5: Oh, Julia did this.
Isn't it pretty?
AUDIENCE: That's dope.
AUDIENCE: Thanks.
STUDENT 5: It is dope.
I agree.
AUDIENCE: [INAUDIBLE]
[LAUGHTER]
STUDENT 5: Any other questions?
PABLO: Thank you.
Quick comments.
I agree with the idea of making something like the flame that
is visually compelling.
You may want to think-- if that's what you end up, fine.
But beware that the idea of fire is very much
elicits a hazard, something external,
whereas the nature of the heat wave risk
is a combination of the hazard like the fire
and the vulnerability of the player.
How susceptible are you, which is
different from an elderly asthmatic person
versus a healthy sports person.
So if you can brainstorm about how to depict that,
which can be more evocative of the fact
that it depends on the person and not
just some external thing.
STUDENT 5: OK.
PABLO: I have no idea how.
Maybe it's not doable, but if you can,
that would be [? an invitation. ?]
STUDENT 5: And even if we can't do
that we're going to try to implement
that same concept through the dialogue
by making the dialogue very specific, based on the person.
PABLO: Excellent.
Great.
STUDENT 5: Yeah, you had a question?
AUDIENCE: Yeah.
We found the fire funny.
Do you think everybody would find it funny?
STUDENT 5: So you have to think about the audience
for this game.
The audience for this game is the Red Cross worker.
Now I don't necessarily think that all of them
will think it's funny, but they'll definitely
elicit some reaction, and I think that's what's important.
Because before in our game we weren't
eliciting any sort of reaction, so it wasn't memorable.
The fire might be funny to some, it might be scary to others,
thinking about people going on fire, I don't know.
Me, personally, I think it's a little terrifying.
But either way it elicits a reaction.
That's really what we're going for.
Any other questions?
PABLO: One minor comment.
STUDENT 5: Yes?
PABLO: Most of the rest of the world
uses degrees Celsius as opposed to Farenheit--
STUDENT 5: Oh.
PABLO: So consider having a choice for [? that. ?]
STUDENT 5: That's a great suggestion.
Thank you.
We'll take that into consideration.
You had a question?
PROFESSOR: And your biggest risk?
STUDENT 5: Our biggest risk is-- so we're not
adding any features, but from our product backlog
it's just we're redoing a lot.
So just the sheer amount and the breakdown of work--
it's just we're redoing a lot.
PROFESSOR: And that's content work,
or is it front and backend work still?
STUDENT 5: So we redid a lot of the backend already,
but in terms of the adding of objects, that's more backend.
But in terms of the dialogue and stuff, that's more content.
So we have work on both sides.
PROFESSOR: OK.
STUDENT 5: Thank you.
PROFESSOR: Thank you.
[APPLAUSE]
Next up is Saving the Animal Village.
STUDENT 6: OK.
So I'm just going to start talking while Justin sets up.
We are a subset of Saving the Animal Village.
And our game is trying to teach cholera prevention
through a series of minigames, three.
And then the story is that the mayor
needs help deciding whether or not
cholera is what is plaguing the city
or if it's this monster that you encounter in the beginning.
And so the player will go through, explore the town,
and try to convince the mayor that it is, indeed, cholera.
The most prevalent things that we
need to fix, I guess-- the prevalent problems that we need
to fix are-- when we playtested with Pablo some time back
he noted that our minigames-- for example, the filtration
minigame-- wasn't really something
that would connect to our audience, which were children
who were in affected areas, like Ghana, from the ages of 8
to 13.
And we had this, like, factory setting before
and it was not something a child would encounter ever.
So what we're changing it to is, it's going to be inside a home
and a mother's going to be the one that's bringing the water.
And it's going to be basically things
that children that will be playing this game
can relate to.
And we're still in the progress of changing that.
And we're also in the progress of adding conversation UI
that's functional and that we can
use while not alienating the lower range of our age range.
Because Pablo mentioned that the children in Ghana [? who are ?]
8 years old might not be able to read as well as
we want them to.
So we're going to have more visual instructions
as well, which is important.
And that will probably be the deciding factor of
whether or not this game will be successful.
I would say the thing that is keeping
us back the most right now is the art, which we have
to synthesize to match Ghana culture
and communicate our message as well.
We're also attempting to implement a way to integrate
the minigames more through our main scene,
but we'll see how much progress we get through [? and ?]
[? we'll have ?] [? to correct ?] that feature.
Any questions?
PABLO: Just one clarification.
When I referred to matching, I like
what you just showed way better than what was there before.
And I think if this is the end aesthetic
of that minigame, that's fine.
My inclination is to think not so much matching
to Ghana culture, but making it more adequate or suitable.
So if it looks like science fiction to a Ghanaian child,
that's fine.
There must be someone from Ghana around the Boston area.
Send an email, talk to taxi drivers, I don't know.
Just like you're doing playtesting with kids,
try to find someone from West Africa, if not Ghana
so that they can tell you, no, cats
are actually spiritually poisonous
or whatever they may say.
I have no idea.
But you want to get some kind of feedback.
I love cats.
I hope they're not spiritually poisonous.
Good.
And then there were many, many games.
We will converse later, but this core idea I think
is a very useful one.
I'll be keen to learn more about how the game can be adjusted
in terms of speed of learning and the speed of-- as you
master it and it becomes more complicated
because of things moving faster or some kind
of additional complexity.
But good.
Well done.
PROFESSOR: So biggest risk?
Are you going to say it's art?
You mentioned the art.
STUDENT 6: Yeah.
PROFESSOR: What about the art?
Is it the UI art or the representational art
that we talked about?
STUDENT 6: Yeah.
So it's mostly making sure the representational art
aligns with-- what we think of it
aligns with what our intended players think of it.
And also just, like, we have so much art to produce.
Like, getting it done.
PROFESSOR: The gameplay is there, all the buttons work,
it's just getting stuff onto that?
STUDENT 6: Also the conversation UI, but our biggest risk,
I think, is the art.
STUDENT 7: It's mostly functional.
There's a few bugs to iron out, but the structure's all there.
PROFESSOR: OK.
Last questions?
Thank you.
[APPLAUSE]
All right.
Any generalized feedback you want to give the whole class?
PABLO: Yeah.
You're now in a place where you have on one hand more
to do than probably you think you can,
but also more temptation to do more things, new things,
explore new ways of representing, et cetera.
It will be a balancing act.
In order to get a passing grade you
have to deliver something that works well enough.
I'll let them define that.
I invite you to remain inquisitive
as to those simple-to-implement new ideas that can help
something be really better.
So don't try to do something really better that
require starting from scratch.
That'll be suicidal at this stage.
But that balance is a balance that you
will be experiencing throughout the rest of your lives,
whether it's designing a video game for the Red Cross
or designing, you know, rockets.
Good luck with it all, and we'll have
more personalized conversations after the half hour
presentation.
Thank you.
PROFESSOR: Thank you.
PABLO: And I'll be outside.
You let me know when.
PROFESSOR: We're done?
Do you guys need to take a-- should we take a break?
Should we just keep going?
AUDIENCE: [INAUDIBLE] 10 minute [INAUDIBLE].
PROFESSOR: Yeah.
So we're going to take a quick 10-minute break.
It's 1:50 right now.
So 2 o'clock.
If you want to talk about and synthesize the feedback we just
gave you, do that right now.
On the presentations you just gave.
You did really well.
You knew the problems that you had, which is good,
because I was worried on playtest that you might not
know some of the issues that you were seeing in the playtest.
So that's good.
We're really glad to see that.
The big challenge I see for your future
is planning for fixing those-- responding to those problems
that you know.
There's just a lot of unforeseen stuff that
can happen between now and the end of class,
and that is what my talk is going to be about,
is how to plan for disaster.
And part of that is, just don't have the disaster.
Cut it from the get go.
So let me just make sure this is up.
Next.
All right.
You have deadlines.
This is the creative process.
Deadlines happen at the end of the process.
Hopefully work happens before the process.
In this class your deadline is the last day of class, right?
Double check your Stellar, you might be surprised.
In the real world some of your deadlines
are going to be demo days.
E3.
Anybody heard the term E3 demo?
And soul-crushing-E3 demo, and studio
closed after failure of E3 demo?
Basically, show your game off to a bunch of press
and hope it works.
Usually that means don't allow any press to play it.
You just play it for them.
And by playing it for them, that might be just showing them
the video while you manipulate the controller.
You don't get to do that in this class.
Other terms you might hear from the industry.
Going gold.
It's not just for disco.
It is-- the Gold Master there on the left side,
that's a game that went gold and actually was canceled.
It got all the way to Gold Master,
and then they said, no, we're not going to ship it.
We're not going to produce it.
It's just not good enough.
That can happen.
Ship dates.
Back in the day games came in these things
called boxes made out of cardboard with printed
graphics that were in interesting-- Eidos
would make them in these trapezoidal things
so they wouldn't quite fit on the shelf.
So you would see-- that's an Eidos product.
Thief-- were you on this one, Thief, The Dark Project?
SARA VERILLI: Yep.
PROFESSOR: Yep.
Tomb Raider as well.
Again, you don't exactly have a boxed ship date,
but you have a give us a playable version of the game
ship date.
So how much time do you have left?
December 10.
You have 17 days left between now
and then to finish your game.
Well, let's assume you don't work on Thanksgiving.
Anybody going home to see family or anything?
A good portion of you.
Are you going to work while you're with your family?
Maybe you're going to try.
Maybe you're in a turkey coma, or veggie turkey coma for me.
But what about the presentation week?
So December 8 and 10, you're actually
in class working on your presentations.
Hopefully your game works by the start of class on December 8.
Hopefully.
We're actually going to recommend that you do not
change your game on December 8 and December 10,
and you do a thing we call "soak,"
which I'll talk about later.
It's totally up to you to do it.
I offer it every year.
It's almost never taken.
But I'm offering it.
So actually, was that 13 days or was it really 30 hours?
You've got 12-- this is a 12-hour-a-week course.
I took out the time that you're actually spent here in lecture,
that I'm stealing from you.
Sorry.
I like talking sometimes.
So you really have less than 1 work week
to get all this stuff done.
So think about that when you're thinking about your projects.
Can you do all this in one regular professional,
less than 40 hour work week?
So that's scary.
How do you meet your deadline?
Do you crunch or do you cut?
Who's heard the word crunch before?
Just raise your hand it you've heard it.
All right.
Raise your hand if you do crunch right now, if you are actually
in the middle of crunch, not even on this class
but in other classes.
Yeah.
As students, you already know how to crunch.
You do this.
This is your daily life.
And it's expected in some cases, it's some problems
with the system, guess what?
The same problems in the game industry.
There is a way to do crunch-- to do a viable crunch.
And that's actually what next week is probably
going to be for you, is your crunch week.
So ways you can do crunch and ways crunch
is viable in the actual, real world industry.
You spend a limited time period in crunch.
So if you hear about death marches,
that's not a limited time.
That can be months, years spent working
80-hour days on some studios, unnamed, in Australia.
We're recommending spending one sprint.
If you do a planned sprint we say, in advance,
that we are going to crunch on this week.
That means we're going to spend that week picking up the slack
and getting through a bunch of stuff
and we're going to work a long period of time.
And it's going to be awesome.
Because guess what?
It's voluntary.
It is team-driven.
We decided, as a team, to do this.
The management did not say, you are going to crunch right now.
And in fact, a lot of game industry would say,
that's not even crunch.
You're having too much fun.
That can't be crunch.
For them crunch is compulsory, unpaid over-time.
Three words that I despise.
So if you are going to crunch and it is voluntary
and you plan for it in advance, you
would follow it by deep soak.
Deep soak, in this case, means test, play, itemize bugs.
It means you are playing your game,
you are understanding every subtle nuance of the user
experience of your game.
You probably have a very good understanding of the programmer
experience of your game, of the artist, of the producer,
of the person on the team.
You know how your game ticks from your point of view.
But you don't yet know it from the players point of view,
even after focus testing, even after seeing
other players play it.
You probably haven't played your game
enough to really understand what's going on.
What it actually does from the get go.
So you play it a lot, you itemize bugs,
you prioritize bugs, you write bugs down,
but you don't actually fix them.
You just see what they are, see how bad they are,
decide whether or not afterwards you want to fix them or not.
All right.
So that's how you do crunch.
I give that to you.
You will probably do it.
That is OK.
Good luck.
But, advanced course.
If you want to cut features, this is how you cut features.
So from now until December 8, ask yourself,
can you ship your game right now?
That's part of the aspect of sprint, right?
At the end of a sprint you should
be able to ship your game.
It's a viable product.
I can send it over the wall, someone can play it,
and it is good and ready to go.
In order to do that-- and in this talk
I'm assuming that, in order to do this,
you're going to need to reduce the scope of your game
because you need to ship it soon.
So what can you cut?
Some developers say these are the only things you should cut.
Features that are not fun and features that
do not advance the game's goals.
So play the game a lot.
Decide whether or not those features are fun,
collect evidence for it, have a theory about what is fun
or what is not fun, identify those features
that go towards that theory and remove them.
Just don't even continue working on them.
In this case you're thinking about the game
from the idea of your player and your stakeholders.
These are basically features that if you spent more time,
it would not be time well-spent.
But there's some other ones.
There are features that are too big to be finished in time.
Really take a realistic look at your product backlog right now
and decide if you can finish it in time or not.
Could you cut those features?
Just give it a moment's thought.
Think about it.
Features that just don't work.
Why bother fixing something if it's just going
to stay broken in two weeks?
Can you cut it?
Can you just remove it?
Does it change the game or not?
Can you even fix these in time anyway?
You just have to look at it and you
have to analyze it and decide.
So how would you actually go ahead and do that?
Hopefully you can say yes to these things.
Is your product backlog currently prioritized
right now?
Did you estimate your features well?
So did you estimate the size and the time it
takes to create the features?
And did you create good blocks of work in your sprints?
And my guess is, probably not.
And that's OK.
We talked to you about Scrum, we talked to you about Agile.
The thing is, Scrum is not a process.
Scrum is people doing a process.
You could be the best person, the best programmer
in the world and be put onto a team,
and still have all the problems that you're having right
now because the team doesn't know each other that well.
That's one of the things we try to do on the first couple
projects, is get you used to working
with the other people in the class
so you can find people that you've compatible work
styles with.
So that when you're in project four
you have a chance at forming a good, solid team
and having some team dynamics.
And remember when I talked about team dynamics
earlier in the semester?
Would anybody say that they are in the performing mode?
Like, do you feel like you are performing well?
Do you have an engine going?
Do you see tasks get done?
Do they just fall off the list because, oh, that was done.
That was verified.
That was awesome.
Has that happened yet?
Probably not.
That's OK.
Yeah.
A lot of head-shaking.
That's OK.
So we need something else we can try out,
because that's not going to work.
And even in the ideal world, you're
still going to have to cut.
Like, developers cut features every day.
Those are the tools they have to use them,
but when those fail we have other tools.
So based on what I read from your project three,
some people think cutting features
means dropping features.
That's slightly different.
It's not exactly the same.
The difference between a cut feature and a dropped feature?
A cut feature has intention.
You've planned for it.
You're going to tie up loose ends around the feature
after you've removed it from the feature list.
You'll actually even delete the feature from your product
backlog, and feel really good about it,
and not have to ever worry about it again because it's gone.
It's no longer going to be in there.
Dropped features are those things
at the bottom of the backlog that
just don't get into the game at the end
and could cause major issues if they're
connected to other systems.
So how do you have that intention?
You think through the dependencies.
Scrum does not have a good tool for identifying dependencies.
It's actually one of its weakest points.
It assumes that, if you do all the other stuff
your dependencies will just fall into place because you've
created really good backlog items
and you've organized them well.
So this is one of those things where,
if you had a couple more weeks maybe
you would want to switch to waterfall
or go into a Gantt chart or figure out
a way to graph every little thing that's
going on in the game.
And I'm going to say, don't do that.
But think about that and get in that mindset.
So take a look at your code and backlog for dependencies.
And here's one really easy thought experiment to take.
look at your biggest unfinished feature
and just think what would happen if you just didn't do it.
So in one of the games I saw-- this team here.
One of these teams.
You two teams over here.
What's your biggest unfinished feature right now?
Either team.
Somebody just say it out loud.
Maybe Matt, while he's chewing.
Or somebody else.
AUDIENCE: Our time to gather all the clues in our endgame.
PROFESSOR: Time to gather all the clues in the endgame.
That's your biggest unfinished one?
What would happen if you just didn't do that?
AUDIENCE: There would be no purpose to the game.
PROFESSOR: OK.
[LAUGHTER]
So is it still the same game?
Not really.
Would the other features feel its absence?
Hells yes.
All right.
So trace your dependencies, take a look at that thing,
go down the line and see, what all the other systems that
are tied into it?
This is where graphing could be helpful.
A little mind map, node map.
If I wasn't crunching and actually made this presentation
this morning, I would have had that graph.
But can you identify the loose ends?
And then if you've cut those loose ends off of that feature,
is your primary feature usable, understandable, and polished?
You don't have to do this for every single feature
on your feature list, but identify one or two really
big ones and just do a little thought experiment
and see what would happen if they went away.
Because they're going to go away at some
point in the next week and a half.
So you've identified a feature and you're going to say,
we're going to cut this feature.
We're not going to drop it, we're going to cut it.
What exactly does that mean?
So think cut plus.
So cut the feature, replace it with a different, smaller
feature.
Key word there is smaller.
Based on new knowledge you know your game
better now than you knew it when you first
made that product backlog.
That fits a similar purpose.
This is an OK solution.
It takes a little bit of time and you actually
might be too late to do that right now.
An example could be, you've got a first person shooting game
and you have rocket launchers, but you
don't have animated missiles.
Cut the rocket launcher.
You have-- what else do you have?
You need another weapon.
You need another big weapon.
Maybe you have a ray gun.
Maybe you can already animate things
on top of another character.
So you have a ray gun that if you press the button,
anybody in front of the button has a little animation that
vaporizes and dies.
You've got a very similar feature going on.
It's a cool weapon.
It's damage heavy.
You don't need to do that animated
bullet, that animated missile, and you save yourself
some time.
And you haven't hurt the game.
The player doesn't even know that that wasn't even there.
You didn't give the player a rocket launcher
that didn't fire missiles, and just made people randomly
blow up.
You've given them something different and new and exciting.
Next one, cut and redesign.
So take the same feature and then shrink it.
Redesign it for a smaller scope.
Again, based on new knowledge.
I'm playing the new Pokemon right now.
Pokemon, that really outrageous, complex, matrix
of strength and weaknesses.
When you break it down it's rock, paper, scissors.
I'm trying to make a game and I want to out-Pokemon Pokemon.
I'm going to have modifiers for everything,
I'm going to have even longer lists of different enemy types.
Maybe I just need to go back to rock,
paper, scissors, do a thought experiment,
create a short little prototype.
That's one thing you can do right now
is you can create paper prototypes on your own.
You've got big enough teams that one person can say, let me do
a really quick paper prototype of that feature
to see what it would look like.
Let me look at all the previous features we have,
make sure it matches, and come up with a little paper
version of it and see, is that going
to fit the same thing or not?
And if it does, great.
You've saved yourself a ton of time.
[? Today in ?] content, as we saw in the presentations today.
Content is ginormous.
Churning through that is really hard.
Lastly, cut and amplify.
Take an already developed feature and make it better.
So did you promise 32 guns for your shooter?
Could 20 just be enough?
And then spend that time you have with those 20 guns
to make them better and more polished.
So I already went back to guns.
That's just where my head was today.
If you think, if you had one good,
really, awesome weapon-- double sawed-off shotgun in Quake,
maybe.
That was pretty cool.
I used that one a lot.
And then a bunch of poorly developed ones-- BFG.
I don't even understand why they even put that in there.
Was that in Quake or was it just in Doom?
AUDIENCE: Doom.
PROFESSOR: But either way, though.
You rarely saw it.
It was cool for one second.
Maybe if that was a hugely important, expensive thing,
maybe cut it and the player doesn't even feel it.
So in all three of these things when
we're cutting the feature what we're thinking about
is, what does the player see?
Does the player have-- what did I say?
Expected feedback.
If you drop a feature might the player
still expect some feedback that they're not
getting because that feature's no longer there?
If you cut it the player should never
know that it wasn't there.
Here's a game where they dropped features.
This is one of our favorite examples from 2003, Big Rigs.
Where's my mouse?
Anybody played it?
[VIDEO PLAYBACK]
-Hey, kids.
Strap yourself in for some action-packed racing.
It's Big Rigs.
18 wheels of thunder, and we got trucks.
Yeah, trucks.
Big Rigs.
Off-road traction.
More power for non-stop driving action.
Big Rigs.
PROFESSOR: It's Big Rigs off-road driving.
You can drive off the road.
-Who knows?
Big Rigs.
Never lose a race again.
You're always winner with Big Rigs.
PROFESSOR: You always win, every time you get through it.
There's no timer.
-Phasing molecular mechanics to pass through solids--
PROFESSOR: Whoa!
- --so as not to interrupt--
PROFESSOR: Is this the future?
-Nothing stands in your way when you're Big Rigs.
Rear-spinning tires with warp-drive velocity
for inter-dimensional exploring.
Leave the game behind and exceed the boundaries of existence!
PROFESSOR: This game shipped.
This game was put on a disk, was put in a box,
was delivered to your local game store and Walmart.
People bought it, I think.
-Big mother-fuckin' Rigs!
-Big Rigs.
[END PLAYBACK]
PROFESSOR: Yeah, that was advertised as the trailer.
I quickly found out it wasn't, but I kept it anyway.
Humor.
Oh, where's my mouse?
No!
[INAUDIBLE] speaker notes.
[INAUDIBLE] back.
Apologies.
There.
[INAUDIBLE] here, down there.
All right.
So that is the ultimate expression of dropped features.
And-- oh, and I forgot to copy this.
All right.
So another example of cut features.
This is The Sims 4.
This is a quote from the executive producer, Rachel
Franklin.
Basically what happened was, when the game shipped-- well,
right before the game shipped, players
identified that through whatever they
did-- I think through watching community forums,
listening to what the developers were talking about the game--
they identified 89 features missing from The Sims 4.
89 features that were not in Sims 4 when it shipped.
How did they know about those features?
Well, they were in Sims 1, 2, and 3 but they
didn't put them in 4, so they should be in 4, right?
Basically, she says "I want to put everything we've ever
created in the last 14 years into a base game,
but we simply can't.
What we have done instead is to create an incredibly rich,
robust experience.
If we didn't build the core foundation
but I gave you pools, that wouldn't be the right thing
to do."
They didn't quite meet the player experience.
There could've been some things that-- maybe there
were some problems going on the production,
but they decided that they still needed a core game that
could work because they could always add some
of those features in later.
There are some people on the forums who say,
no, that's actually not going to be working in the game engine
because I'm the nerd on the internet knows everything
and I know you can't do that, developer
who actually made the game.
So that is a problem that they knew they were going to have.
They know that they have it when they ship the game.
They have to come up with a community response
to figure that out.
And actually, that's something we'll talk about next week when
it comes to community management,
is when you're creating this game and people find out
about this game, how do you then talk them down?
But actually, in the most part you'll
be talking about bringing them up.
All right.
So we're going to cut some features.
We're not going to drop them.
So who decides which features are going to cut?
Who decides what and when, and then
who's going to implement it?
How are we going to do this?
So the people who decide which features get cut usually
are the stakeholders.
In the professional world that's going
to be that executive producer.
For you that could be your client.
That could be your product owner,
if you have a product owner on your team,
if you have someone you consider a vision owner on your team,
it could be that person.
It could default down to producer or Scrum Master,
if that's the person we're saying
that we're following their lead, they're
going to make that decision.
It could be your game designer.
But it's going to be somebody on your teams.
One, maybe two people on your teams
who are coming up at least with the what and the when.
Not everybody on the team knows the schedule as well as
maybe the producer does.
But the who implements and how it's implemented-- that's
the entire team's job.
This is why we have those long, boring Scrum meetings
at the beginning and the end of each sprint.
It's because that's the time period when
we have all the team together to make these kinds of decisions.
It's definitely not the producer and Scrum Masters' role
to decide how you're going to cut that feature.
They're there to facilitate it and make sure
that everybody who's attached to that feature can talk about it,
can explain why, can give some argument,
can give some defense.
Rather than giving the entire team the need
to decide everything, one or two people
decide the initial part and then the whole team
focuses on just how we're going to cut those things.
And that's because how you implement
it requires knowledge of both code and content.
It's more than a feature list.
A feature list can't do this for you.
It can do the top, it can show you the what, but never the
how.
All right.
Last little section.
So you were working on a feature and your feature was cut.
You spent a lot of time on that feature.
Your roll was to implement networking.
And this is actually an example from two years ago.
But was cut.
In that case, it wasn't cut because of these things.
I don't want to cut it.
I want to see this finished.
I put some commitment into this thing, dammit.
I want to see this all the way through.
I feel guilty about cutting it.
I really let my team down.
I was just working on networking the entire semester,
and it's not going to make it into the game.
What have I been doing?
I feel sad about cutting it.
It's not fair.
How dare you cut my feature?
You're going to see a lot of that, if you haven't already.
But that's OK.
One thing to keep in mind when you're
cutting a feature-- and this is one thing
that we told that person-- was, your work needed
to happen because otherwise you wouldn't know that we needed
to know about your work.
You described this better, by the way.
SARA VERILLI: I'm trying to remember exactly what I said,
but it's something to the effect of,
sometimes the work that doesn't make it into the game
had to happen anyway because you had
to do the work to explore networking
to find out if it wouldn't work or not.
Just like you had to do the work to explore
several other features that did go into the game.
But you didn't know that the-- I don't
know-- you didn't know which of those features
were going to work out well.
But you were hoping that some of them would.
Some of them did, some of them didn't.
The fact that one particular feature-- the one
that you worked on-- is not a reflection on you.
Not at all.
It's a reflection on the game, and the project
needs to go forward.
PROFESSOR: Absolutely.
So yeah.
Work that gets cut is never wasted work.
And that's actually a problem I have
when game developers do their postmortems
and post in the Gamasutra is they always talk about it as
if it was wasted work.
But really, again, they wouldn't have had that information
had they tried it.
Work well-cut is exploratory work.
It means that you cut it early enough that it was exploratory.
You got your feelers around it.
You figured out that was probably
a direction you didn't want to go into, and you pulled back.
And actually you did that in the beginning
with your paper prototypes.
I don't think your games now actually are
one-to-one relationships to those paper prototypes
you created at the beginning of this project.
And you threw those away, and it was OK.
So why is this important?
Because the team is more important than the product,
which is, unfortunately, more important than you.
But that's OK, because the team equals you
plus others in the same situation.
You are actually part of the team.
So just keep that in mind.
This is where I go to my Goodfellas-- was it Goodfellas?
There's no I in team, baseball bat?
You are on a team.
Everyone's contributing to it.
Everyone's doing good work for it.
All right. so that's my spiel on cutting features.
Here is my-- what I'd like to do on Wednesday.
So Wednesday is going to be a short class.
We're just meeting from 1:00 to 2:00.
You'll have the remainder of the time to work in your group,
in your teams you as you like, but if you want to take off,
you can take off.
What we are going to do-- and it's
going to be me, Phillip, and Drew, because unfortunately
Sara won't be here-- is we're going
to meet with each of your teams individually for about five,
seven minutes tops.
What we'd like to do is look at an updated vision statement.
So between now and then take a look at the vision statement
you turned into Stellar, compare it
to the game you have right now, and modify it.
The vision statement is your publisher contract with us.
That vision statement that you actually finally turn
in on December 10 with your game,
is the thing that we are judging your game by.
If your game has all the features
that are described in that vision statement, then aces.
If you created a vision statement that
doesn't have the features are in the game,
or if you don't describe the features well in the vision
statement then we're going to use that
as an understanding of what could have gone wrong
with that game.
This should be a really quick thing you can do.
You can probably do this in five minutes today with your team.
You have everybody here right now.
You just had your presentations about your products.
So if you can take five minutes today, reassess your vision
statement, take a look at your product backlog, change it.
We're going to talk about that.
You can re-turn that in to Stellar
or you can bring in a paper version on Wednesday,
so long as we can see it when we're
sitting with you on Wednesday.
That's all we ask.
And again, like I said earlier, plan
as if nothing is being done over Thanksgiving, just in case.
If work happens over Thanksgiving, cool.
You did good.
That's bonus work.
So just keep that in mind.
Any questions?
All right.
Pablo is back in the room.
And you're working on your teams for the rest of the day.
Thank you.
[INTERPOSING VOICES]