Modernization Hub

Modernization and Improvement
From Pitch to Product: The Development of Hello Waves

From Pitch to Product: The Development of Hello Waves


GUEST SPEAKER: That says
choices for your game project. These are the six choices that
I want to make available to you. The next one is perhaps the most
challenging one intellectually. It’s about new
funding mechanisms for disaster preparedness. I will explain this. We call it forecast-based
financing, or FBF, and it’s the one that has the
most potential to transform the humanitarian world. All right, moving
to the next one. The next one is
the most complex. Do you see the drawing of
the time bomb with the fuse? OK. So allow me to give a
little bit of context. We did a little bit
of this conversation when I showed up
a few weeks ago, but I imagine you
all forgot by now. The humanitarian sector has
two main funding mechanisms. Imagine a pot of money. Even if there’s almost no
money there, if the pot exists, money can go in to then
be taken out to spend. One of the pots of
money that exists, one of the funding
mechanisms that exists, is for disaster response,
meaning hurricane or flood or volcanic eruption. Something has already
happened, is happening, and is killing people. People are dying, but
if you did something, you could save lives, for
example, get on a boat and rescue people who
are stranded on a roof. Or people are sick,
go give them medicine. This is disaster response,
and if you spend money, you can do very good things when
the funding mechanism exists. There’s another pot of money
which is for a normal day. The Red Cross has vehicles. The vehicles need maintenance. They need to change tires. You need to buy a new computer. You need to pay rent
and electricity bills. You need to train staff. So on a normal day, you
have a budget for, you know, either maintenance or
development of new projects or writing proposals and so on. And that pot of money exists. We call it the annual appeal. Every year we appeal
for help, and people or donors or governments
give us some money. What does not exist is what
the drawing, the cartoon depicts, which is when
there’s a signal from science that a disaster– that something
bad is likely to happen soon. We don’t have money to fund
action before the disaster, after the forecast. So you can click
to see the text. The context is that there’s
that missing money pot. We have my for
after a disaster, we have money for the
normal day, but we don’t have money for before the
disaster after the forecast. The issue is that if you spend
money in that time window before the disaster and
after the science says a disaster is likely, you
can do very good things for very cheap and relatively
simply and much more reliably. It’s not only more expensive,
but more difficult, to save a life when
the storm waters are flashing through a city and
people are about to drown. The boat is unsafe. Whereas if you do
it the day before, when the water has
come down from the sky, but it’s still in the
river and not in the city, people can take action
by just walking away on their own means,
with their valuables, and not just depending on
someone to show up with a boat. So we came up with a
financial mechanism. We call it
forecast-based financing for disaster preparedness,
which is [INAUDIBLE] in our particular method. There’s a pot of money,
so like a bank account. You need to have a
threshold of disaster risk that needs to be exceeded. So it can’t be
two drops of rain. It has to be a lot of rain. It cannot be some breeze. It has to be a hurricane
of Category 1 or more. But once the threshold is
established and reached by the forecast, then there’s
some standard operating procedures, some actions
that people have to take, spending money to save lives. And that is something
that if you could come up with a game that captures that,
this is the one that if we help communicate
forecast-based financing– I said to the public, because
it can work for a broad audience digitally. Ideally it would reach those
who can contribute either money or decisions, muscle power. The chances of
embrace for this one are not as high as
all the previous ones, but if it were to happen, it
would have the highest impact. Because right now
there is billions of dollars being spent
in the two extremes, and if a small
fraction were spent– invested in that precious
window of opportunity when you see the fuse getting
close, that time of effort can really have a
very, very high impact. There is a link to
a journal article that should be very
clear for MIT students. We also have some simpler
readings on general. And I have been engaged with it. And I’m ready to help. This is, I insist,
the one that is intellectually most challenging. But I think if you
nail it, it will also be the most rewarding. Questions? PROFESSOR: So one thing. When we first started
designing this class, this was actually
the problem that we were most interested in, mainly
because the other problems we just hadn’t heard about since. The cholera was a recent
proposal that was asked for, and Ebola, of course,
very recent as well. So if you really enjoyed
some of the challenges from projects two and
three, and you really took on the planning
aspects, the trade-offs aspects of those
two games, if you’re looking at kind of trying to
communicate to another person how these kind of
probabilities works, this is probably a
really good project you might be interested in. And I should say also that
working with a few MIT teams, including the
Humanitarian Response Lab, including the
Environmental Engineering, we have two generations of
three students plus on professor go to Uganda to work on
making this happen for real. We got German money to do
it in Togo and in Uganda. So it’s beginning
to happen, but it’s hard to explain
because it’s dry. It’s like explaining insurance. People get bored
before they get it. So maybe a game
can help motivate. STUDENT 1: Our team is working
on forecast-based financing. So because we’re about
planning for disasters, our game is pretty
heavy on chance. But we want to teach the
players to do is to use planning and forecasting
in order to reduce the effects of that chance and
sort of gain valuable skills in mitigating that. PROFESSOR: So basically
if you have– there’s one, two, three, four,
five testers, plus let’s say each team send out
two people to test other games. Remember to rotate. We’re going to do this
for about 20 minutes, as long as it takes, and
then see where we are and do it again to get some
just quick testing and make sure that
the five of us get to play a good
number of your games and give you some
feedback on that. So remember if you’re
using digital– if you’re not– If a computer’s
not being used for testing, close it, or make it look
like it’s not being used for testing by typing on it. All right. Let’s get started. [INTERPOSING VOICES] STUDENT 1: Hi. We’re forecast-based funding. The general idea
behind our concept is that planning
ahead for disasters is much better than
trying to react to them. So if you can have operating
procedures or ways of planning for them and money
allocated for that, you can reduce loss of lives
in the event of disasters. We are actually
between two prototypes right now that we’re testing
to try and get at the ideas. The first one is a sort
of higher-level city-based simulation of cities
at risk of disaster, which you then have
to fortify by training volunteers or preparing for
upcoming disasters in order to prevent too much damage
from happening to them. One of the problems that
we’re seeing with the game is that it’s kind of abstract
and not as interactive for players to
connect with, but they are getting a good understanding
of the idea of planning ahead. STUDENT 2: And so to try
and address those issues, we have a second
prototype right now, which is about trying
to actually, like, rescue volunteers in
a flooding– rescue people in a flooding city. And so that hits the other
end of the scale, where the player is told ahead of time
this disaster was planned for, versus this disaster
was not planned for, and the appropriate
effects for each. And then they have
to rescue people under those two
different conditions, and then they get
to directly compare what the experience
is for, like, acting in one circumstance
versus the other. STUDENT 1: Over the
next couple days, we’ll be looking at what we
learned from both of them and trying to either
combine them or pull out the parts that we thought were
really useful to make one game. PROFESSOR: I can tell
you’ve worked hard on this. This one’s a hard one. STUDENT 1: Yeah. PROFESSOR: Did we assign you a
target audience for this one? STUDENT 1: I think it was
stated a couple of times that we should be looking
at people like policymakers or donors in the sense of people
who would be allocating funds from governments or
nonprofits, things like that, basically to make it clear
that this type of planning is a good idea. PROFESSOR: Oh. And what– have you decided
on a technology yet, or are you still pondering it? STUDENT 1: We’re probably– STUDENT 2: We’re using Phaser. PROFESSOR: OK. [LAUGHTER] All right. Thank you. [APPLAUSE] STUDENT 1: 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 the 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, is 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’ll 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 over these couple days. Right now the forecast
is pretty low. If we see that it’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 the
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 our
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 well with it, but 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,
Tom, what is your biggest risk going forward? STUDENT 1: So– STUDENT 2: I mean,
I think in terms of our technical
implementation, we’ve already got good playtests
of our work done, and we have 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
a finished product, it may still not
be playable if we don’t write good instructions. GUEST SPEAKER: All right. So on that front, think
of incremental additional features. So the game begins with a
super-simple, even maybe too boring choice, but
then a new choice arrives. So the learning by
playing can be staggered in a way that is intuitive. Good. Good luck to you, and we’ll
talk more about choices later, but– 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 and then it’s not that
value, it’s up here, and then everyone doesn’t
believe forecasts. Good. Thank you. STUDENT 1: Thank you. [APPLAUSE] PROFESSOR: OK. One down. STUDENT 1: OK. So it’s a little light on there,
but our game is Hello Waves. It’s a game about
forecast-based financing that we’re developing
for the Red Cross. The idea of
forecast-based financing is using the idea of forecasts
about the future in order to make decisions that are more
effective than just reacting to disasters when they happen. So I’d like to show you a
playthrough of our game. So, as I said, Hello Waves. Here are the instructions. We would have done a tutorial
if we had enough time, but this gets the idea across. And designing a good tutorial
that actually teaches the player well is kind of
hard to do in a logical flow, so we have these instructions
that explain how to play, what the point of the game
is, and a couple of tips about how the game works. So if we go into
the Play screen, you can see something
similar to what we showed you a couple weeks ago, where you
have all these different toys at their castles, and as
you go through the days you’ll see a forecast of
what the water level is going to be at over time. And so you can see that right
now they’re gathering candy. The water level will change. This character is underwater,
and so he takes damage. And so what you
actually want to do is you want to move
toys out of the water so they don’t get damaged. However, they can only move
one castle over at a time. So because we didn’t
think ahead well enough, we’ll see that this
truck will actually take damage on the next turn,
because he’s underwater. Actually, he ended
up not underwater. We got lucky there. But theoretically he would have. And so as you go through
it, the end goal of the game is to build a castle. And so every toy
when they’re home can either choose
between gathering candy to feed evacuated toys
or building the castle to reach your end
goal of the game. And then the idea
of the forecast is that you want to use
the forecast in order to know how much candy
you’re going to need over the next couple days, and to
use it to know when you’re going to need to evacuate various toys
from their variously-heighted homes. So back to the presentation. Full screen. So we had a couple of challenges
in the design process. The first– and the
major one– is really that we were trying to teach
about forecast-based financing, which was a bit of
an abstract topic. It’s a little different than
just thinking long term, because you have to use the idea
of there’s some information we know about the
future that we want to use to make
optimal decisions, or at least decisions based on
some idea of the risk that’s out there. But we also wanted
to avoid things like just pushing
a button to win, where you have all
the information you ever need, and
there’s just one option that you know you’re
going to pick every time, and the game has no
thought whatsoever. And we also needed
to think about how we were going to communicate
the forecast to the player so that they could then
use that to make decisions. One of the problems that we
also ran into related to this was that we focused
a lot on the idea of forecast-based
financing as the topic and then tried to build a game
built on top of that topic instead of building a game that
used forecast-based financing. So that held us back
a lot in the beginning when we were trying
to come up with ideas. We also had a really difficult
initial target audience of policymakers, 50, 60-year-old
government officials or people at NGOs who were going
to be using forecasts to make decisions
of some sort, and it was supposed to teach them
about how they can use forecasts to make these decisions. Except this was a really
difficult audience, because they don’t
generally play games and they don’t
have a lot of time to learn about
this kind of thing, and so we couldn’t
really expect to get them to sit down for
a long period of time and play around with our game. In order to deal
with these problems, we came up with a
couple solutions. The first thing was that we
had no idea what kind of game would work or would make
sense or anything like that. So what we did is we
just broke our team up into multiple groups
and came up with a bunch of different prototypes. On paper we had two
different prototypes, one that focused on
the idea of managing a city and its resources
and its response to disasters, versus
focusing on individual people and how you’re going to
move them around to keep them safe from the disasters. And then we went
into a whole bunch of different digital
prototypes, one that was a text-based game
about managing a city. We had one that looked
like this, where you had two different
cities and you were specifying what
workers were going to do or when they would leave the
city in order to stay safe. And then we would take
the different ideas that we were learning from
both of these prototypes, combine them together,
take things out, and our final prototype actually
uses ideas from all of these. Another solution that we
kind of got lucky with is when Pablo came
to play our game, he told us that we
actually shouldn’t focus on the policymakers,
because he wasn’t confident that he could actually
get them to play the game. And so we switched our target
to being grade schoolers, which is why you saw the
sort of cutesy art with the beach and the toys. This actually made it
a lot easier for us, because we could target
people who probably had some experience
with games, or at least wanted to do something fun
and would be curious to learn about our topic. STUDENT 2: So another for
our development process– Or I can just speak here, right? PROFESSOR: Yeah. Just speak right there. STUDENT 2: So
another big issue– another set of challenges
that we ran into was through our
development process. And so we had initially
issues with communication and facilitation. Our team had a wide variety of
experiences and backgrounds. Some were hardcore gamers,
some mostly mobile gamers. And so there were
initially a lot of disagreements on what level
of game we wanted to create and what sort of game, casual
versus hardcore, that we wanted to create, and so we needed
to overcome challenges of facilitation and
communication within our team. Another major challenge
in our development process that we had to face came
from our design issues, where for a very
long time we had a vague vision of what to do. We didn’t know what kind
of game we wanted to make, and so we purposely tried
to keep our game ideas vague as we built prototypes. But then we ran
into issues where we would have solutions but,
like, no consensus on which solution was best, and where we
went for long periods of time without having a clear
direction of where we wanted our final game to be. So our solutions
for the challenges posed by the development
were a team structure. And so we structured
our team loosely into three subteams, a
production subteam which would take care of production,
like the deliverables and making sure
that all the game ideas are being
communicated properly, a technical team which worked
primarily with the code and making sure
the game got done, and then a user
experience team which handled art, UI, and sound. And so we kept the
responsibilities flexible. So as team members got
busy over the semester or as changing conditions led to
different people contributing, we kept– responsibilities
were able to easily flow between teams and team members. Additionally, another idea we
started with in the beginning was the idea of subteam
leaders, which were the two people marked with the Ls. But that was an idea
we later abandoned in favor of just having a
more flexible team structure or flat team structure. Another solution for helping our
development process was the use of good code practices, and I
cannot emphasize enough that this really helped speed
up our development, because we didn’t run
into trouble with code. It was mostly with design. So we used Yeoman, which is
a JavaScript module system, and basically it allowed our
code to be interoperable. We could write one module
separately from another module. So that solved a lot of issues
with dependencies or people working in parallel,
because it allowed people to work in parallel without
overwriting each other’s code. We also used good code practice
with state machines and MVC, which is model-view-control,
and so we had a very object-oriented
code, very modular. And when we did need to change
our code, rip it all out and put it back in, it
actually didn’t turn out to be too painful, because we
just had to switch a couple objects around. And then one final solution
that we used for our development processes were Slack and Scrum. So Slack is like a
modernized IRC chat room, and it’s very feature rich. It has a lot of integrations
with GitHub and Google Drive and things like that. And so that sort of
real time communication actually made it so
that we didn’t really have to meet outside
of class too often. If someone was
working, we would just email out saying
I’m on the Slack, and then people could
meet on the Slack, and it was
full-featured enough– like we could send attachments
and things like that– that most of our in
person communication could be done in class. And in class we adopted a sort
of, like, daily Scrum format, where we simply said what we had
done since the previous class and what our goals
were until next class. So in the end, though, we did
have to cut some features. These features
mainly were the idea of multiple– again, a
tutorial or multiple levels, simply because there would just
be too much content that we would need to playtest
in order to make sure that it was of
consistent quality and got our message across. And also trying to add more
individuality to the toys that you saw. They have different
graphics, but that’s as much as we could do given
the time constraints. So kind of just bring it back. Our three worst
decisions were first, we did end up spending
a lot of time on code and assets that never got used. We maybe, like, used 10%
to 20% of our final work in our final project. Actually, maybe that
is a bit overkill. But OK. Maybe 30% of our final code and
assets in our final project. This really was due to
this second bad decision, that we kept the game
and its direction too vague for too long. We always were holding
out for, oh, maybe we’ll be able to come up with
a better game idea, or maybe we’ll find
some magic solution to how we can make
forecast-based financing into a game. And because of this
mindset, we spent probably the first half of the project,
like, just staying too vague. And that hurt us in the end,
because we spent so much time going in all these
different directions. And really the
decision that kind of captures those
first two, though, is the fact that we tried
to make a game on top of forecast-based financing. So we had forecast-based
financing, and we were like, how can we skin this as a game? Whereas once we switched
that mindset and thought, let’s have a game, and how can
we put forecast-based financing into it? I think that was the moment that
we then came together as a team and really started making the
final game that we wanted. So our best decisions– STUDENT 1: So one of
our best decisions was that we chose good tools
at the beginning, which meant that as we
went through all these different
digital prototypes, we actually didn’t have to
completely rewrite our game. We could pull out the way that
workers worked in one game. We could pull out the view that
we were using in another game, and then we could just
combine them together, and that allowed us to
move quickly whenever we were changing our prototype. We also weren’t afraid
to trust each other, both in terms of what
everyone was working on, but also in terms of the
decisions that we were making. And so when we said that we
had to throw something out, we all understood that it was
for the good of the project. And we didn’t have
a lot of complaining or hurt feelings when
something didn’t get put in or when we decided to throw
out certain assets or code. And when we got
to the end, we had been through enough
of this vagueness that we were all kind
of frustrated with it, and we realized that we had
an idea that we all liked and we really got on board
with it and made it happen. Once we started working
on our final idea, and we saw that it worked,
basically every decision from that point on was how
do we make this game better, and we were all on
board with that vision. Thank you. Any questions? [APPLAUSE] PROFESSOR: Anyone in the
audience have feedback for them first, before– AUDIENCE: You can’t see
those sand castles very well. STUDENT 1: Yeah, we’ll have to
make all of our slides darker. PROFESSOR: Yellow and white. AUDIENCE: Yeah. Like, the yellow and white,
on your early screens. I was doing this on
your instruction screen. PROFESSOR: It’s also– AUDIENCE: I realize that’s the
game, not the presentation, but wow. PROFESSOR: It’s also a little
faded in the game itself. It could be the display
resolution you’re using. So we’re all done
with everything, try a different resolution. See if it makes a difference. AUDIENCE: The music in the
game level was too high. It was overpowering your voice. So I think you were
almost hollering just to be able to be heard. it doesn’t need to be that loud. So you can just crank down the
volume, either on the computer or on the controls over there. Something that I had
a question for, you don’t have to answer
it today, but you might want to put it in
your presentation was, how long was the design
of what you eventually established on the
table before you decided that this was the
thing that you were going for? Because I’m assuming it
was one of your vague– it came up during
your vague idea phase, and you’re implied that you
were in that mode for too long. But I don’t know how
long it was on the table, or was it only something
you figured out at the end of the
vague idea phase? Because otherwise
you wouldn’t have been able to switch to
this idea if it was not on the table in the first place. And how did you decide this
was it, that the sand castle game was going to be it? I understand– I think you very
clearly explained the benefits of deciding this was it. But how did you come
to that conclusion? So that’s stuff I wanted
to hear more about. But you don’t have
to answer it now. AUDIENCE: Yeah. Just a little bit
of specificity. You mentioned you spent too
long on that design phase. I wonder how long that was. PROFESSOR: You said Pablo
switched your target audience for you. Telling us whether that was
because of the game that he saw or because of something else–
if you know that information, throw it in there. If you don’t know that
information, that’s fine. Knowing why you
dropped the team lead. You mentioned you dropped it,
but you didn’t exactly say why. Again, really quick. This is what– we weren’t
getting blah out of it, or the flexibility
was more, whatever. And then, yeah, to– Oh. Defining your terms. You were saying things like
casual versus hardcore. Give a little bit a definition
of what you mean by that. It means different
things for everybody. So what is your use of that. AUDIENCE: Yeah. I think he specifically
said hardcore and mobile, but there are hardcore
mobile players out there, so this is like– PROFESSOR: And casual
can be considered a version of hardcore,
just in a different way. So just be really–
just be a little more clear about– because I
think you were talking about the target audience
and the kind of players and the kind of games
they might play. So just be a little bit
more focused on what exactly you mean by that. That’s it from me. AUDIENCE: Yeah. So in terms of
technical observation, Yeoman is not really
a module framework. It’s just a system to
generate the project and it puts
different frameworks. Again, just check that. AUDIENCE: So that’s a
terminology issue, then. Clearly it worked
out for your team. So we’re not saying
don’t mention Yeoman. It’s clearly a good thing. But just check your
definition of what it is. Because it’ll be more
helpful for other people to understand what
it is so that they can think about whether they
want to use it in the future. PROFESSOR: Oh, and
actually– So your demo, you spent about three
minutes doing it. We are going to have you have
a player from the audience play your game live, without
getting a lot of help. You can talk over it. You can, after a while,
start helping them. We want to see
them at least just to start playing on their own. Decide when you’re going
to put that demo in. You could actually
combine them both together if you do it at the
beginning or end. But if you do that, give the
player a little bit of time before you start talking. AUDIENCE: That’s all I got. PROFESSOR: Great. Thanks. [APPLAUSE] Snap, come on down. STUDENT 1: Hello. We are Hello Waves. We’re a game about
forecasting, specifically this idea called forecast-based
financing, of using forecasts to make decisions about
possible disasters in the future and how to prepare for them. We’d actually like to start
with a playthrough of our game. So if anybody would like to
be a volunteer to try it out. AUDIENCE: The guest
from not our class. Would you please
come down, Andrew? [LAUGHTER] PROFESSOR: Thank you
for volunteering. [LAUGHTER] ANDREW: Hi, I’m Andrew. PROFESSOR: Oh, do
you need a chair? There’s one right there. All right. [? STUDENT 1: I’m not sure
how to make it full screen. But anyways, this is our game. I’d recommend looking
at the instructions first and reading through them. And we’ll keep the
description minimal as you read through,
just to show the player’s initial reaction to it. [MUSIC PLAYING] ANDREW: Music. STUDENT 1: So yeah. Start the game. So as you can see, our
game, as I said before, you control some toys
on a day at the beach. And so by dragging and dropping
them between the castles, you’ll see that their
status is changed, and say that they want to move
on their next turn or that they want
to be collecting– or that they’re going
to be collecting candy or anything like that. And the game is turn-based,
so all of the actions will resolve on the next turn. ANDREW: Am I reading this right? STUDENT 1: Yeah. STUDENT 2: You can
also access the Help by clicking in the
bottom right corner. STUDENT 1: And so when
you go to the next turn, you’ll see all the toys move
as specified by the status bubble above their heads. ANDREW: So go ahead to
the next turn? [INAUDIBLE] and Next Turn. STUDENT 1: But
unfortunately you’ll find that when toys have been
evacuated, they’re unhappy and need candy to survive,
so they’ll all take damage. ANDREW: OK. I don’t want to be
in that [INAUDIBLE]. STUDENT 2: So you can try
returning them to their homes. ANDREW: Ah. STUDENT 1: And so you’ll see
that on this turn instead now they have their statuses
set to gathering candy, except for the dump truck,
who’s still evacuated. ANDREW: Gotcha. OK. I think he needs
to be evacuated. STUDENT 1: Exactly. And so the idea is that as
the player plays through it, they get better at understanding
how to use the forecast to make decisions
about the future, both in terms of how much candy
that they need to have stocked up in order to weather
out the rising tides, and also in terms
of when they’re going to need to move their
workers out– their toys out of the areas that are in danger. ANDREW: They’re gonna
be really affected. STUDENT 1: I think you
have those two guys. ANDREW: Oh, right. So is there a reminder
of where they started? STUDENT 1: Yeah. It’s on the castle. It’s actually blocked
there right now by the toy in front of it. But there’s a little shadow
on there, an imprint. And because he ran out of candy
and then– Actually, sorry. Because he went to a
place that was underwater, he took too much damage and then
was swept away by the waves. [LAUGHTER] STUDENT 1: And so
on the forecast, you can see that high water is
coming for quite a while, which is going to be a
danger for the toys, both in terms of possibly
getting swept away and not having enough candy for
all the toys that you’re going to have to move out of the way. ANDREW: [INAUDIBLE] PROFESSOR: Ooh. He may be out of luck. ANDREW: Yeah. PROFESSOR: And when you’ve lost
two toys, you lose the game. ANDREW: Pretty good. STUDENT 1: Thank
you for playing. [APPLAUSE] STUDENT 1: So
that’s Hello Waves. So in our game we had a
few challenges to overcome. The first was that
our game was based on forecast-based financing,
which is a very abstract topic. It’s a pretty
understandable idea of using information about
the future and ideas of risk in order to decide where
to allocate resources. But it’s still a bit abstract
and building a game around it took a little bit of work. It’s useful to note that
it’s different than long term planning. It’s not just thinking about
what will happen in the future, you know, building
a dam to prevent water or things like that. It’s actually about
using the information you have to make the
best decision for events that may be upcoming in
the semi-near future. We also wanted to avoid
making a game that was overly preachy or
simplified, where it was clear exactly how you’re going to win
and you could just basically push the forecast-based
financing button to win the game. We wanted players to
actually think and understand the concept there,
instead of just coming up with the buzzword of
forecast-based financing. And finally, we
had the challenge of actually communicating that
forecast to players in a way that they would be
able to understand and then make use of. You could see in that game
that we had water levels, and it would show
on the map, and we found that players were
pretty good at using that in order to make
decisions about what was going to happen
in the future and how to allocate
their resources. The other big challenge
that we had in the beginning was that our initial target
audience was policymakers. Like for Snap, Pablo had come in
and pitched us this game idea, and originally he had
wanted us to build a game for policymakers that
would help them understand the benefits of
forecast-based financing and therefore convince them that
they should develop policies that would give
resources to plans based on forecast-based financing. So I would like to take
you through a couple of our prototypes, just
to show you the evolution and comment on our process. Actually, to preface that,
we had a lot of prototypes, because our idea was so abstract
and because we weren’t sure how to address our audience. So we built a lot of
prototypes to start with. We had ideas that ranged
across levels of scope of what you controlled, where
you controlled entire cities or where you controlled
individual workers and moved them
around, and then we would pull from all these
different kinds of ideas, what worked, what didn’t, what
did people understand, what confused them. And from that we got a really
good idea of what concepts helped people
understand the idea and brought them into this final
game that we ended up with. So the project started
on October 15th, and this was our
first prototype. It was a terminal-based
game where you had some kind of information
about a future rainfall, and then you had to type in your
commands of how you controlled different cities. This– Actually,
people found it fun, but as you might expect the
feedback wasn’t very good and people didn’t
quite understand how to move forward with it. It put a lot of
cognitive load on people. So when we moved
forward, we tried to give people more easily
understandable actions to use. But the problem with this game
was that it was time-based and it updated every second. And so there were
so many numbers flying at people that even
MIT students who playtested it couldn’t understand. So we figured that
people like policymakers who didn’t have much
experience with games really wouldn’t be able to
understand the game at all. So instead we went
to turn-based. And that helped, but
at the same time– it’s tough to see
on this projector, but we have a forecast
underneath that says how much rainfall is expected. And again, that wasn’t
understandable to people, because they couldn’t understand
what three inches of rainfall meant for their city
and they couldn’t understand how that contributed
to a possible disaster. At this point, Pablo
actually came by the class and played the game,
and then he told us that he wasn’t even sure that
he could get policymakers to play the game, because
they may not have enough time. Instead he wanted us to
switch to grade schoolers, because we could
teach them something about forecast-based financing
and help them understand as they grew up. And this was great
for us, because making a game that was serious,
easy for somebody who didn’t have experience
with games to play, and also fun and engaging was too
difficult for us, actually. So moving to grade
schoolers was awesome. He also suggested that we try
to make the idea of rainfall or water levels more
visceral, and that’s when we came upon this
idea of the rising waters. Whenever players looked
at this, they instantly understood the
concept of the game. The feedback might not be there. The beautiful UI
might not be there. But the idea of having
cities with workers in them and a rising water level
coming towards them, everybody understood that, and it made
it a lot easier for players to reason about the game. From there we added things like
nicer art, better feedback, which you can’t quite see
in a static picture, more improvements to how
the forecast worked, and eventually we ended up
with our final version today. STUDENT 2: So to
talk a little bit about our actual
development process. So our team was structured
into three main subteams– production, which was in
charge of managerial roles, deliverables, and playtesting,
and so there was a shared responsibility there,
a technical team, which was in charge of the
bulk of the coding work, and a user experience team,
which would be in charge of assets and UI design. We also initially
envisioned subteam leaders, where we’d be kind of
communicating through them. But we found the concept
kind of redundant, and so we worked pretty much
with, like, a flat structure between the three teams. So from the beginning,
we encouraged good coding practice, and so we used
good tools available to us. One of these is Yeoman, which
is a JavaScript scaffolding framework. And this helped us out a
lot by basically automating a lot of our JavaScript tasks
and making our code modular. We also used Phaser’s
state machine, which is this kind of badly
documented new feature in the Phaser game engine,
which was the JavaScript game engine that we used. It’s a bit badly documented,
but it did save us a lot of headaches, and
once we figured that out, that proved immensely helpful. And we also used MVC, which
is a software engineering term standing for
Model-View-Controller. And again, by encouraging
these good coding practices, we reduced dependencies and
made sure that our team was productive. In terms of
communication, we– also similar to Snap– used
Slack, which is kind of like a modernized chat room. It’s very feature-rich,
and so you can share files in channel
and things like that. And we also used the
idea of the daily Scrum. We implemented it
in class, and we would say what we had done that
class, what we would be doing, and what we wanted to
do until next class. And so the major challenges that
we faced during the development process, though, were
that our team members came from very
different backgrounds and had very different
preferences about games. You know, some of
our team members were very hardcore StarCraft
players and very good at RTS games, while
other members of our team preferred like a more laid-back
mobile game, Fruit Ninja kind of approach. And so trying to mediate
those two viewpoints and trying to create
a game that would engage both types of
gamers was a challenge that we had to overcome. And so another big challenge
that we had in our development process, as you saw
through our progression through our
different prototypes, was that our direction was not
very clear until about halfway through the project. And so partially because
we had different ideas on what the game
should look like, and also partially because
we had such an abstract idea of forecast-based
financing that even we didn’t have that good
of a grasp on initially, it took us a while
to really get settled on what we wanted to build. And so this really challenged
our development process and made us have to build a
lot before we got something that we liked. And so eventually we did end
up having to cut some features, like multiple levels, or a
guided tutorial for the player. We thought that this would
introduce too much new content that would need to be
playtested, balanced, and tested to ensure
consistency with the rest of our game, which we viewed
as taking up too much time. And we also cut the idea of
adding more individuality to the workers or to
the toys that you saw, other than different
graphics for each. STUDENT 1: So some of the worst
things that we did on our team is that we spent a
lot of time on work that got thrown out entirely. All the prototypes we did, they
were actually pretty useful because of the things we learned
about the concept and about how people would play the game. But we did spend a
lot of time on things like art or nitty gritty
details that didn’t really need to be figured out and
that we could have put off until later in the project. We also kept the game direction
to vague for too long. As Norman said, we spent
a lot of time with that, and it probably ate up
too much of our time. Although it helped
us learn, we could’ve moved faster in the beginning
to get to a solid idea. Because once we got to a solid
idea of the rising waters, our team started to
centralize around a lot better because we could actually
deal with something concrete. While we were dealing
with the abstract ideas, everybody was all over the
place and arguing about things that didn’t quite line up. And the worst decision of
all that we started with, and that sort of made the
problem of going too vague and all these other
things happen, is that we were
originally thinking how do we skin forecast-based
financing as a game? How do we take this idea of
using forecasting decisions and then just gamify it? Which we eventually
realized wasn’t fun, and didn’t help us actually
come up with any ideas. Instead, when we
flipped it and started talking about what game
could we create and use forecast-based financing to
improve it and teach players how to play the game, and
therefore allow them to come out of the game having learned
about forecast-based financing, the world sort of opened up. Everything became a
lot more interesting and we found that we
started to move faster. Some of the best decisions that
we made, on the other hand. As Norman said,
we had good tools, which meant that even when
we threw out prototypes, although we wasted things
like art resources and things like that, we actually didn’t
end up wasting very much code, because things like the
idea of workers or cities could literally be pulled
out of the old games we had, put into our new game,
and then reworked to build our new structure. We also weren’t afraid
to trust each other and throw out the
things that didn’t work. Once we started
moving fast, we had a lot of ideas that
would come out, and we would say, OK,
this doesn’t work. We’re actually
going to scrap it. Or we think that this isn’t
the direction we need to go in. And everybody was willing
to go along with it. It’s not a good feeling to
see your things thrown out, but everybody understood that
was for the best of the game, and I really appreciate
their understanding with everything too. And part of that all
comes down to the fact that we were on board
with our final idea. We were all excited about
the concept that we had. Part of that might
have been the relief of coming to a concrete
idea after spending so much time being vague. But once we had
that concrete idea, we really moved fast and
worked well around it. So thank you, and any questions? [APPLAUSE] AUDIENCE: Who did your sound? It’s awesome. STUDENT 1: That was
from our UI team. AUDIENCE: Oh. OK. It’s really cool. PROFESSOR: Where
did you find it? STUDENT 2: So it’s
on our credits page. Most of it was online. The credits page in our game. [LAUGHTER] STUDENT 1: It’s a little
small, I guess, up there. PROFESSOR: Oh, OK. STUDENT 1: But it looks– PROFESSOR: [INAUDIBLE]. STUDENT 2: Yeah. “Hold
My Hand,” AJP, by– AUDIENCE: Would it
be possible maybe to create a short URL for this? For the game? STUDENT 2: Yeah, a bit.ly link? STUDENT 1: Yeah, sure. We can make a bit.ly link, and
we’ll send it out to everyone. AUDIENCE: Yeah,
just so we’ve go it. Yeah. STUDENT 1: That’s a good call. Yes. AUDIENCE: Having watched
the early crash and burn of the playthrough,
how often have people– I don’t know if you’ve
actually had a lot of people to play your current
version of your game– do people usually take
a playthrough or two before they start
getting the concept? STUDENT 1: Yes. That’s why something like a
tutorial would be really nice. Unfortunately, we didn’t
have the time to put it in– AUDIENCE: Yeah, no, no. I was just wondering how that– STUDENT 1: Yeah. Usually what happens is even
if after maybe a couple turns of playing through, they
start to get the idea. The problem is that as
the water starts to rise, they haven’t prepared enough,
and so all their toys will starve or get carried
away by the waves, which is a bit unfortunate and
probably makes the players feel bad on the first time. But then they– It
actually teaches them to think ahead about it. So the next playthrough,
they’re much more careful and understanding. AUDIENCE: So I was
wondering if you were playing any other games
or thinking about other games as inspiration or
thinking about how to deal with some of–
hitting the right level of strategic thinking
in your game. STUDENT 2: Well, so I guess in
terms of early on, because we had a very different idea
of what we wanted to do it early on in the process. We were thinking about games
like Civilization and how did they communicate all
these complex worker movements and managing multiple cities. But once we actually came
up with this game concept, I think we had much,
much smaller goals, and so did we have any specific
game models, do you think, or? STUDENT 1: There’s none that
I specifically think of. There were some things that
we were sort of inspired by, standard tricks
like when you hover over one of the characters,
they got bigger. Some idea of showing off
that this is clickable, things like that. But specific games
themselves, not really. AUDIENCE: OK. I was just thinking it ended
up being kind of board-game-y. And I feel like there’s
a lot of board games where they’ve been thinking
a lot about getting that right level of tactics
rather than strategy. But yeah. I guess it worked out too. AUDIENCE: So you
mentioned that you were able to change
how your workers looked and just keep your models. So that’s the holy grail of
object-oriented programming, that you have an
object that’s reusable and you don’t have to
throw out the code. Do you think there’s a
reason why in particular you were able to achieve that? Because I think that’s
not common, necessarily, in object-oriented programming. STUDENT 2: Partially a
little bit of OCD-ness, like, very early
on, very strictly saying we’re going to write
this object-oriented code, and we’re not just going
to hack things together. I think that helped a
lot, because we actually spent the time in the very
beginning to think about, like, which objects were
responsible for what and what their
purpose should be. So basically, I think because we
moved more slowly in the start and thought more carefully
about how that code should be structured, we ended up with
having an easier time later on. STUDENT 1: There’s also the
fact that because we had learned these things from the
prototype that we were putting into this game, that also
meant that the objects that we created– because we wanted
similar functionality to things that we had already
seen and we knew worked, it meant that we were
comfortable pulling out the functionality into that. So I don’t want to say
it was designed to fit, but there was the fact that we
moved it on purpose, really. AUDIENCE: I would like
to something on that. So we had a very good MVC model. So models were in this
tree-like structure, and it was very easy
to change models. So models knew about– Sorry. User knew about
models, but models had no idea about [INAUDIBLE]. So basically, it was quite easy. PROFESSOR: Thank you. STUDENT 1: Thank you. [APPLAUSE]

Leave a Reply

Your email address will not be published. Required fields are marked *