From Pitch to Product: The Development of Hello Waves

• Download this transcript - PDF (English - US)

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]