Session 12: Project 3 Presentations; Project 4 Topics by Guest Pablo Suarez (Red Cross/Red Crescent Climate Center); Project 4 BrainstormingProject 4 Brainstorming

• Download English-US transcript (PDF)

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

PROFESSOR 1: It's 1:06. We're going to start presentations at 1:10. So Ghost Maze just get started. You don't have to come down here yet, but just make sure you're ready.

So just a brief going over what we're doing today. Presentations, I hear a lot of really good energy in the room. So I hope to hear that when you come down and tell us about your games and all the foibles, all the things went wrong, all the things that went right. Hopefully this is a really good prep for you for our next assignment, which is going to be much, much longer.

So after we get through with presentations, we'll take a brief break. And then we're going to just jump right in to project 4. I'll introduce project 4 again, going through all the boring slides with all the deadlines and stuff. When I get to that, if you want to fall on Stellar, I just updated the project for assignment today to make sure that the deadlines were correct.

And we'll double check that again as well. Unfortunately, Pablo who came to us in the beginning of the semester, is not here with us in person. But he will be here with us on Skype. He's in Geneva right now, but he'll be talking to us about what they're looking for project 4.

In particular, we're going to be introduced to six different game topics, game design topics. And you're going to choose one of them. We're not necessarily making your choice today. We're going to brainstorming today.

We're going to have people form up in a brainstorming groups around these topics to talk about them. And then you will have over the weekend to talk about it on the mailing list, to read some of the resources and some of the materials we posted to Stellar to see which topic you're most interested in.

We're going to start the day off Monday with forming teams. So a little bit longer time to form teams, bit longer time to really think about the topic and think about what the project's going to be-- again, you have more time to actually do concepting on this project. It's an eight week project. Nine weeks, if you count spring break, which you shouldn't. We designed it as an eight week project. What's that?

AUDIENCE: Not spring break?

PROFESSOR 1: I said no. Yeah don't work on spring break. Like you were going to. Any quick questions before we start? We've got two minutes left. Any quick questions you might have about project 3? About turn ins?

AUDIENCE: What did you mean [INAUDIBLE] spring break?

PROFESSOR 1: I said don't work during spring break. We designed this as a eight week project. Project 4 is an eight week project. We've designed it so that you are not working on a project over spring break. What's that?

You could give me some details about what I'm screwing up over here. So do we have a fall break? Don't we have a week long break? Thanksgiving break? It's 70 degrees outside. I'm in a different place right now.

All right, I said Ghost Maze, come on down and make sure your projector, if you're going to use a projector at all, works.

AUDIENCE: [INAUDIBLE].

PROFESSOR 1: What's that?

AUDIENCE: [INAUDIBLE].

PROFESSOR 1: I still didn't understand.

AUDIENCE: [INAUDIBLE].

PROFESSOR 1: No, just like 4, you only need as many people as you need to present to come down.

STUDENT 1: So if you remember, our game was Ghost Maze. And we'll run you through a quick refresher of what the game actually was first so you remember what it is.

STUDENT 2: So here we have our character in a maze. You've just woken up and you're in a dark maze. All you have is your lantern. And so your objective is to explore the maze, avoid ghosts, and drop beacons to help you explore the maze. And find a key, which will then unlock and exit for you get out the maze.

And so there are different effects that happened during the games, such as your sanity starts decreasing as the games goes on. And then randomly, as you're sanity starts getting lower and lower, your movement will get impaired randomly, and the light will turn red as you can see in this picture here.

And then another interaction that we had was when you get close enough to a ghost, your sanity start decreasing faster. So the light turns blue to let you know that you're too close to a ghost and you need to get away from that ghost.

STUDENT 1: So a few things that went right was that it was hard to balance everyone's schedules, but everyone was pretty flexible in terms of what features they were working on. So people would adapt to the features that needed to be done at that time. So flexibility was, I think, something that went more or less well, in terms of working on what needed to be worked on.

The second thing that went right was user experience. So we spent a lot of time focusing on user experience, and playing with the camera, playing with shadows, playing with the player movement. We spend a lot of time putting in graphics and audio so that it seemed a little more realistic to put you in the context that you were in a dark maze and lost.

A few things that went wrong is we started out using Flixel. But it took us a few days and we still couldn't get up a dev environment reading. So we decided to switch over to Unity. That was a pretty wise choice, but we made it pretty late.

We found that collaborative coding on Unity was really hard. Certain changes to the main scene would wouldn't merge well. So also when we were working on different branches, and then tried to merge it back into master scene, people's changes were lost or overwritten.

So we found that Unity wasn't great in terms of like having a big team project where a lot of people are coding at once. And sometimes we just re-applied changes on to the master branch.

Something else was we all had really busy schedules. People were out of town. In town, they could only work on the project at certain points.

So I think something that helped with that was at the beginning, we did a pretty good job of delegating tasks to people who work on the project earlier. But then later on it, it was pretty haphazard in terms of who is available at one of time. So maybe re-evaluating priorities as the project went on would've, I think, really helpful.

STUDENT 2: So lessons learned, we spent a lot of time working on user experience. Because we had a 3-D perspective game, there was a lot of thought that went into how the light was hitting the player, how to get the shadows to cast properly, how the player knows that the players in the maze. And being able to move around and understand how your sanity is decreasing. We spent a lot of time testing that.

Working early and quickly-- this was partly hindered because we lost at least four days of work because we were trying to get Flixel set up. And then it just didn't work. And we had to switch to Unity, so basically starting over from scratch.

Working early and quickly is super important because we ended up having to drop quite a few features because we didn't get enough done on time. And we also learned that working in 3-D is very, very hard. We were originally going to do a 2-D game, and then thought, oh, how hard would it be? We have a 2-D game, but let's just give it a 3-D perspective. That was not a good idea.

Doing the textures took a long time. It ended up looking really, really nice, as you can see in the pictures. But the time investment was a huge investment that we could have used to put in some more complex mechanic into our game.

And future improvements, team communication and availability is a huge one. We, as Rachel said, we had a task assignment at the beginning. But then due to people's schedule, we didn't really take that into account when we made the initial task list.

So people ended up having to pick up other people's tasks. And it became very hard to figure out who was working on what. And scheduling meetings was near impossible.

Getting familiar with the game engine-- using Unity at first was very hard because we weren't sure how scenes work. And eventually we figured out that if we make most of the stuff dynamically generated then we can just worry about the code, and not have to worry about all the user interface stuff that Unity does.

And that would have made our game develop a lot quicker. And setting deadlines was very important. We had a lot of tasks laid out. But we didn't set strict deadlines for when we wanted each task to be assigned, or when we wanted each task to be finished. And that would have helped push along our game and get some of them more mechanics that we wanted in it.

STUDENT 1: Yeah, I think something that a little bit arose was when we were going to plan on doing our testing session because we should have set the internal deadlines to match the testing sessions so that we get as much feedback as possible. But that said, we still got something out of the testing sessions. So that was good. I think that's all we have.

STUDENT 2: Yeah, that's it.

STUDENT 1: So I don't know if you guys have questions.

STUDENT 3: I'm from team Hardcore Dragon. And as a refresher, I mean our game is about being a hardcore dragon. So to us, that meant razing villages, being chased down by knights and accumulating a horde of gold that you have to protect from looters.

And we all were pretty excited about this idea. And that was probably the best thing about the project, as a whole, is it was a fun idea. Even when we got bogged down with work from other classes, or something emerged, or didn't go through correctly, or there's was a bug, and we couldn't understand what was happening, it was still really fun to be like, OK, I really need to make this dragon set this village on fire. And I want to do this because that's awesome.

And another thing that worked is that we use Gitter, which integrates with GitHub. Whenever something is pushed, it'll show up on to the right and you can link to it. And everybody who's on your project is on the Gitter chat. So it was easy to keep track of who was working at what time, who was online at that time, and who you could ask for help to let you debug whatever was going wrong.

Another thing that helped was Trello is actually really good tool. The last project, I personally used Google Docs. But Trello is much easier to look at something, drag it while I'm doing this right now, adding yourself to things, and breaking it down to simpler task.

It's all very easy on Trello. I mean, it's built for this. So it made long-term goal planning a lot easier. And you could see at this moment who was supposed to be doing what.

Unfortunately, the idea was also a downside to the project because it was Hardcore Dragon. I want to do so many things with this idea. When I blow fire on this thing, I want it to turn into a crumbled building and become a pile of flames, and it'll be awesome. That's not necessarily at the top of the feature list, obviously, because we have other mechanics that are more important than that.

But we kept coming up with these little additions that would make the game a lot more cool or awesome, but are hard to prioritize and just way too much to stack on top of the game. So that was the downside. And it was just hard to control-- it was hard to scope the game down to the five minutes game we needed to create for the project.

Gitter was good with the [INAUDIBLE]. If everybody was on and everybody used it all the time, it would be ideal. But since a lot of us are on the go and working on other things, in classes while people are working, using something else might have been better, like g-chat or Facebook, something you can access from a smartphone, or something more instantaneous.

We would just get-- if you weren't on Gitter at the time, it would send you a notification being like, you missed these messages. Which is almost as delayed a message as email. So it was kind of pointless other than the fact that it was integrated with GitHub and you could see who was online at the same time as you.

Another thing that didn't work is that meetings are really, really hard to coordinate with seven people. And what ended up happening was that we would all be like, OK, so half of us are free this day, six of us are free this other time. Let's meet then.

And then we wouldn't decide a specific time within the time were free to meet. And then by the time we noticed this, ti would like that day. And it was just hard to coordinate everything after it got to that point.

So for the future, I believe we would have to have a fully dedicated scrum master. And I really mean fully dedicated, not scrum master AKA programmer on the side, or scrum master who also gets music done and play tests, well it does play testing.

Everybody play tests, but a fully dedicated scrum master to make sure that everybody's on tasks, that the meetings will get scheduled, and that the tasks are prioritized. And if something falls through, they're the person to talk to, they're the person who's going to make you stop freaking out that this task took like three times as long as you've estimated it for.

We didn't have this one person dedicated to that. Everybody was like a jack of all trades in our group. So not having that one person to talk to, go to, made task prioritization really fuzzy, and made everything kind of come together really late. And it was hard to hold people accountable because there wasn't that one person who was on top of everybody.

Another thing we had to do earlier would be feature cutting. Because if you don't cut features definitively earlier, you'll still have it lingering on some people's minds. Oh, I have to do this so that in the future we're going to maybe use this feature.

But if you cut these features early, you limit the propensity to have bugs, or stuff like that. While it's unfortunate that you have to cut features, it's necessary. So doing it earlier is the best time to do it.

Another thing is, like I said before, a native messaging system. Gitter was cute but didn't actually work in the way that we wanted it to work. It wasn't instantaneous between all members.

It's hard to find a messaging system that everybody likes. But I think something like G-chat or Facebook messaging, something instantaneous like that that most people use already should be used as a group so that everybody can be on the same page and have access to the instant messaging.

Yeah, our game is there if you want to play it. Anybody have questions?

PROFESSOR 1: So if you were to do the feature cutting early, did you feel like you had the information in order to do that?

STUDENT 3: So there was some stuff that like after even half the halfway point, that we could've cut features. But instead of the halfway point, we did like two days ago, which is too late already. So even earlier than that.

It doesn't have to be like day one feature cutting. Just at maybe points throughout, be like, now that I'm here, what features look like they're not going to get through. And with a dedicated scrum master, who's like looking through, looking at people and how they're struggling with certain tasks, maybe people don't know exactly what their pace is internally.

But from an outside perspective, a scrum master might be able to more accurately help with estimates and stuff like that. So a dedicated scrum master would help with early feature cutting as well, probably.

PROFESSOR 1: This is a Unity project, right?

STUDENT 3: Yeah, a Unity project. Yeah, sorry. We actually didn't have that many problems with merging because we had, I think, at least one of us was really experienced with Unity, so that's was lucky, I guess.

PROFESSOR 1: OK. Thank you.

STUDENT 3: You're welcome.

STUDENT 4: So our team is MIT Simulator 2014. So our basic concept was you play as a certain dean of MIT you may all know. And you're making decisions that trade off between the endowment, wealthy donors, and student approval.

And the basic goal of the game is to try and survive as long as possible, while shitty things happen to the institute. So what went right in our project? I think what went right in our project is we connected with our audience.

A lot of MIT students know what it's like to be at MIT, and they know the setting, they knew the administrator We're not really pointing at, but we kind of are. And so a lot of people connected very well with our game. And so they enjoyed it and were able to understand it easily in their own terms.

So the second thing that went well is that humor works. A lot of our things in our game were like kind of unpolished, and kind of like slapped together. But because we had taken the time to make them funny and make them entertaining, people we're OK with losing all their money in one turn [INAUDIBLE]. Because, hey, the description of it was funny.

And so the third thing that well is that simple is OK. We ended up having like very few core mechanics. But then because of the setting that we had and because people connected well with our game, I think people are still able to get-- we think people were still able to get enjoyment out of the game because of those.

So now what went wrong? So first, Hex Flixel, AKA what do you mean it's not on Stack Overflow? So Hex Flixel, while it did play well with version control and I heard some horror stories about Unity version control, Hex Flixel played pretty well with version control.

But if you ever had an issue, you were pretty much out of luck. You could search on Google, and you'd get like zero results. Sometimes the official documentation wouldn't even turn up on a Google search result. So documentation was a little bit lacking.

I think the second thing that we could have improve on is that paperwork is not management. I think in the class in particular, this isn't emphasized enough, is that you can do all these agile development methods, like you can have a sprint task list and everything. But unless if you actually have people who are actively taking charge and managing a project, I think stuff still won't get done.

I think that's something that could be improved in the future in this class is like spend less time worrying about paperwork, spend more time actually like teaching about how to handle personal situations. Like what happens if someone doesn't have time.

Or what happens if somebody like does this? And so learning those managerial skills isn't a trivial task. And I think in the beginning, we underestimated how much those issues would be a roadblock to progress.

And then the third thing that went wrong I guess is that responsibility is shared. So even if somebody has a role assigned to them, we should all still like take the time to make sure that like everybody is completing their role. So just making sure that people are checking other people, to make sure tasks don't fall between the cracks.

And so overall people do like the idea of playing as a certain dean of MIT. Any questions?

PROFESSOR 1: So what would you do different? Not necessarily things about the Hex Flixel, [INAUDIBLE]. But when it comes to your management, managing stuff we talked about, what would you want to do different, or what [INAUDIBLE] particular problems that you had. And you know you're going to have a feature that you need to have scrappings for?

STUDENT 4: I think one thing that we would do differently is like take project management more as like a people problem then like a paperwork problem. Because I think like we kind of just assume that by filling in the sprint tasks list and by writing git commit logs, we magically work together as a team. But I think in the future, just taking a more active role in insuring that people are interacting with each other and communicating.

PROFESSOR 1: How about if I'm [INAUDIBLE] the responsibility of sharing things, like how would you address that [INAUDIBLE]?

STUDENT 4: I think for the responsibility being shared thing, I guess this was just in reference to a few particular instances where like we had someone who would claim that they would do something. And then because we assumed oh, because they claim that they would do it, that it would get done. But I think sometimes we got too complacent and then thought that it would actually get done anyways.

But I feel in the future maybe just sending out a couple more emails, just having people confirm that they've finished things, require that people send out emails confirming when they finish things, so we know that this thing didn't get submitted yet. Oh, shoot class is in an hour, or something like that.

So just like encouraging people to either like poke each other more, and also to be more responsible about like when you submit something. Or when you do something important, you email out to everyone just to show that you've done the work.

PROFESSOR 3: Would email be primary means of communicating between the team or was there face to face meetings outside of class, or [INAUDIBLE]?

STUDENT 4: So email was our primary means of communicating. We had one face to face meeting outside of class. And then there was another one that was supposed to be scheduled over the long weekend, but things happened. One or two people were gone for the weekend, and then things fell apart.

PROFESSOR: [INAUDIBLE]? Thanks.

STUDENT 5: This Is our game Build a Spaceship. It looks like this. You have your ship with a set of components of a bunch of components that you can add to the ship. You click and drag them onto the ship.

And then you send it out on a mission. After you go out on that mission, you'll get a log that looks like this. All this text is really small, so you can't see it. But it says things like, you met some bandits, you had a battle, you won and earned this much money.

Or you got hit by asteroids and lost this much health. And the point is that after you design your space ship and sent it out on this mission, you'll get all this feedback telling you how you ship did so that you can then update your ship and send it out again, and hopefully make even more money.

The goal of the game is to complete a series of missions that we have in the game currently, and make as much money as you can while doing it. Of course given more time, we would do things like add more components, upgrading your ship, and other tweaks like that. But this is the core of the game right here.

So what went right on our game? We made a prototype really early, which was great. That helped us all get on the same page and understand what we're talking about when we're talking about the game.

There's was point before that where we had all these cool ideas from brainstorming, and a vague idea, a personal idea, really, of what the game would be. And that made it really difficult to communicate. So once we had that down, everything just became way easier.

We did a lot of UI testing. Even before we were sure about the game would specifically be, we knew that was going to involve adding components to a ship. And so we knew we could UI test that and see how people manage with different ways of adding those kind of components, or customizing their ship.

Hex Flixel, we found it really simple to work with actually. And whenever we needed to add more screens or make changes the game, we all had a pretty intuitive understanding of how that would go. That might also be an artifact of coming over from Phaser, which is very similarly structured.

And on our team, we got lucky because everybody had coding experience. And it made it a lot easier because we were all speaking the same language. And so on a time constraint project like this, it meant that when we talked, we were more efficient about it.

That's not to say that there is a place for people who don't have coding experience on these teams. It's just that when we only have two weeks to get things done, the speed was a huge help.

What went wrong was communicating our progress on the game. We had a lot of problems where we wouldn't talk about what was that done. We didn't know what was even in the game because somethings weren't clear yet.

Like there was one part where we didn't know that we could actually add components to ship because somebody had added that in but not actually told us. And the UI wasn't there yet to actually make it clear.

We also run into problems with heroic efforts where the night before something was due, somebody would like to come in and put in all this effort. And we didn't know what they were doing, and we didn't know what was getting done because we just weren't communicating about that.

A problem that's related to this is that we didn't assigned tasks well or take ownership of what we were doing, or assign responsibility between people. And so we ran into problems where things just wouldn't happen for a long spurts of time.

And then we'd run into the heroic effort problem at the end where we're all jumping in to make things happen. We also ran into problems where sometimes people didn't push commit for an entire day and we had no idea what the state of the game actually wa So what we learned from this, and what we would do differently next time is first we'd keep track of our progress and make sure that it's contiguous, whether it's using Trello, or emails, or any other sort of solution for it, it would be really important to make sure we all know what the state game is, and what's being worked on.

We should come up with standards for how we're going to email and meet. We talked about this, and said it would be a good idea, but then we didn't actually do it. So it would be good to have a schedule of when your team is going to meet, how they're going to email and why they're going to email, if it's a daily update of what you're doing, or if it's every time you push a commit.

And also coming up with standards for how you're going to Git. Are you going to use feature branches, and all these kind of things, or are you going to do it all on master? And are you going to push every time you make a new commit? Or are we going to push at a set time every day so that we can track it all at once?

If would be good to know who's doing what. That comes in with the idea of communication and tracking progress. What we did at first was we had specific domains that people were working on. Jeremy was working on the UI, Rodrigo was working on the ship model.

And this made it really easy to assign tasks and to make sure that things were getting done in the beginning. But then in the end, when we had some tasks that were kind of in the middle and we didn't specifically say what was going to happen, we ended up with this last minute scramble of, OK, I'll take this thing. Actually I'll take this thing. Somebody else is coming in.

And it made a lot more difficult to track what was actually getting done. You can also give tasks to people. We were kind of reluctant to do that at first. But we got better and it, and it was actually super helpful to just be like, hey, you take this. And then it's completely clear what happening.

And the very last thing to do with this is to just ask what's happening. It's good to get some reassurance that something actually is happening if you're not hearing anything about it. So you can just ask someone. Hey, what are you working on? Or hey, is anybody working on making this component up here?

Then you just get an answer. And you get a lot of peace of mind from that. It's good to set up specific times to work together. We didn't do this enough, but it would've been great if we had. And like I said, we made a prototype pretty early on.

But I think we could have made one even earlier. We found that it didn't limit our creativity or our ability to talk about the game. Instead it just gave us a platform to work off of. So we could build a basic prototype with some idea of a core mechanic, and then continue to brainstorm and expand from there.

And that's basically what we learned from this game. And moving forward, we're looking forward to implementing this on project 4. Any questions?

AUDIENCE: The site's solving problems with HaxeFlixel all on your own, did you find any online resources that turned out to be helpful? Or did you just [INAUDIBLE]?

STUDENT 5: The main problem that we ran into with HaxeFlixel was we were trying to build an HTML5, and the text just wasn't working. And we found nothing about it. We found one page by HaxeFlixel that said, sometimes we have problems with text. Try doing this.

That didn't work. And nobody else has an answer for it. I don't know if anybody else did.

AUDIENCE: Basically you have to read the Flixel documentation and ignore the HaxeFlixel documentation. [INAUDIBLE] identical and the static typing does save you a little bit. And you have to jump into the source occasionally. There's nothing wrong with that.

STUDENT 5: Anything else?

AUDIENCE: Thanks.

STUDENT 6: So we did Looking for Deena. And we have some screenshots of the games in case any of you didn't get to play it or see it. So it's just a search screen.

The first thing-- so the game is kind of in two-- you have to do two different things. The first thing you do is you choose which planet you're going to go to. And you can't really read it, but they all different distance stats as well as stat games that each planet will give you.

Then you have to navigate through an asteroid fields, which depending on how far along you are in the game, makes it harder as you go along. But hopefully you have those stat games that should make it easier to actually go through it. You're looking for Deena. And you can lose and win.

So what was right and what was wrong is we did communicate a lot. And by a lot, I mean from midnight to like this class, there's 108 emails. And that was just today.

So we communicated a lot. But we didn't communicate really effectively. There were a lot of people saying like, this what I'm doing, this is what I'm doing, this is what I'm doing, this is done. I submitted this.

But then going through those hundreds of emails trying to figure out, oh wait, who said they were doing this, who said this was submitted, was really hard. And so we didn't have those daily scrum meetings that we talked about. And I'm realizing those would be really useful to have somebody say like,

OK, this is what everybody's done. This is what everybody's going to do. This is what we've submitted. Having that one thing somewhere where everyone can view it easily would make it a lot easier than trying to go through email and figuring out who did what and what went wrong.

One other thing we did right was we went in smaller group. So people were working on the design, just those people met. And then people working on the code, just those people met, which was really useful for trying to meet. Instead of having seven people meet, you only had like three or four. And so much easier to arrange those meetings.

We really divided the tasks effectively. Everybody was doing something. And that's what the last point is. Everybody tried to make sure they were always doing something and contributing to the project. No one was just sitting there wondering, what do I do. Everyone tried to constantly be doing something.

Another thing that went wrong is that we worked in bursts. People were really busy. And then the night before we assigned an internal deadline, everyone's was like, oh OK, let's work on this right now.

And so then it was just people staying up all night to try to finish something. Which things got done, but sometimes it's like, did we do this the best way we could. Was everything optimized?

And we weren't really sure because everything was done in short bursts, instead of like a little bit of every day. And do you guys want to talk about Unity?

STUDENT 7: Yeah. As people have said, Unity is annoying because it has all these binary files that you cannot merge. So if two people were-- we had to basically always keep track of, I'm working on this scene. No one else touch it. Because if two people work on it, someone is going to lose everything in it, which is really annoying.

Emails worked for that. And so that way you could say, I finished working on this scene. Someone else can touch it now. So that was sort of helpful.

STUDENT 8: [INAUDIBLE] spits up like five of them. And you're like, I think it's fine. But sometimes a conflict happens. And you're like, I don't know what to do with this. I think I can check all of them.

But then things break and you're [INAUDIBLE]. I feel like that scheme is weird in the scene because at least we tell each other, stop touching the thing, or touching the thing. But something you touch the thing and something else happens entirely. And you're like, OK.

 

STUDENT 7: I also want to point out how impossible it is to schedule anything for seven people. We wanted to meet on the weekend. And there was literally not a single period of time, not one hour that wasn't at 3:00 of 4:00 in the morning where everyone was asleep. It was impossible. It was insane.

STUDENT 6: Yeah, schedules are hard.

STUDENT 8: [INAUDIBLE].

STUDENT 6: Any questions?

AUDIENCE: You have two points about [INAUDIBLE] items up that appear to [INAUDIBLE].

STUDENT 6: So we did keep to deadlines. So what I was trying to say with that point is that we did kind of keep the deadlines where we worked in those bursts to get to the deadline. But then because it was such a long burst, by the end everyone was drained.

And if it was like, I'll do this, and this other little small thing, a lot of little small things didn't get done. And so things were kind of push back a little bit. And so this led to more bursts. And it was a really bad cycle that I think ended up happening.

AUDIENCE: Do you think if you planned for the bursts, it would be better? If you actually scheduled meetings at 3:00 before?

STUDENT 7: So I think we need more granularity in the deadlines. So we'd say, let's get this bucket of things done by this day. And that would-- people procrastinate. We have other work to do. Well, I have this other deadline for this other class is due first, and leave everything for this till later, until you're finished with every other class.

So if you leave smaller tasks, more spread out throughout the week, I think that would enforce a more, I'll work a little bit today and a little bit tomorrow, as opposed to I'll work a whole time two days from today, which is what ended up happening.

STUDENT 9: We also didn't have that [INAUDIBLE] scrum master or project manager who would reinforce those deadlines [INAUDIBLE].

STUDENT 6: Yeah, you would just get an email saying I have something due at midnight. I'll start working on this after midnight. So a lot of times that would happen, and things like got pushed back because that person didn't get that done. And so you kind of have to wait.

STUDENT 7: But I think we got it done.

STUDENT 6: But everything got done.

STUDENT 8: It's very cute. I feel like that's what [INAUDIBLE].

PROFESSOR 2: [INAUDIBLE] you can [INAUDIBLE] a lot if it wasn't well organized. Do you have any thoughts on how you might better organize your communications on the project? How do still have that good level of communication, but have it be something [INAUDIBLE]?

STUDENT 7: So I think a big problem we had is we had just one enormous email thread, which became huge and monolithic and impossible to look through after a certain point. I think it would have more helpful to break up into smaller email threads.

So like people that were working on a specific feature in code, not everyone needs to receive all those emails. So it would have been, I think, really helpful for the future to maybe organize it in the send that if me and Jenny are working on something, we email each other a lot.

And at the end of the day, we send one email. Here are the details that everyone needs to know. You don't need to receive the 10,000 emails we sent before that.

So I have to say, keep everyone in the loop. Don't leave people out of the loop. But keep little pockets of communication so everyone's not flooded with all this stuff.

STUDENT 6: And even having the designated scrum master, I think, would help with that a lot. Because then it's not even they're sending it out to the group email thread. They're sending it to the scrum master and the scrum master makes one thing.

It would be really tiresome to do that every day though. So maybe every other day or something. I'm not really sure how to break that up. Because it seems like you'll just end up having a lot of things, like a lot of reports. Report this was done this day, this was done on this day.

PROFESSOR 2: Did you [INAUDIBLE] place to track where what tasks were done [INAUDIBLE]?

STUDENT 6: We had the Google Doc with the change log.

PROFESSOR 2: You did the change log. But were people updating, changing, task lists or anything like that?

STUDENT 7: I think that was mostly done in like-- so we'd say, these are the sets of tasks that we want to finish today, or something. And then I, for example, I'm going to work on this. [INAUDIBLE]. I'm going to work on this scene. No one touch it. OK, I'm done working on the scene. And then once everyone finished working on all the scenes, then we'd go back [INAUDIBLE].

STUDENT 8: It does feel like we probably could have done some weird joint thing where the sprint tasks list keep track of bigger things. And then we have some kind of chat email system going on where we should stay in contact, especially with [INAUDIBLE].

At the same time, it's a little bit like , hm, what level of tasks, size, goes into the sprint task list? Because [INAUDIBLE] something really small, it's like yeah, this is what we spent the last two hours doing. [INAUDIBLE].

AUDIENCE: [INAUDIBLE].

STUDENT 8: [INAUDIBLE] task [INAUDIBLE] is hard.

AUDIENCE: But what really [INAUDIBLE]. That's what, if you can figure out a way to have something [INAUDIBLE], whether it's just a list [INAUDIBLE] where you can say, hey, I finished this task, can sum it up [INAUDIBLE] task was based on that. Or if you can go to [INAUDIBLE] troubleshooting or something.

AUDIENCE: Thank you.

STUDENT 10: Hi. So I'm going to be talking about Score High. This is actually our start screen. So just in case you don't remember what Score High is, it was a game where you played as an MIT student.

You went around to different buildings, did your homework assignments, ate, slept, and basically just tried to survive school. So I'm going to start off by talking about what went poorly. And the first thing we had an issue with was direction.

So this time, we didn't have a paper prototype. We had an idea that we wanted to do. But it ended up changing a lot right from the start. And it became really difficult to stay on topic because we didn't really know what we were doing.

And very much related to that, we then had issues with scope. We started off with a lot of unrelated features and a lot of components. And even now in our final game, there are a lot of components and the way they interact is complicated sometimes.

And then finally, I think every single team has mentioned this, just planning ahead, and getting work done earlier, and planning time to work together-- the issues we had especially that came up later were a lot of issues with midterms, things going wrong, everything that could go wrong kind of went wrong. And if we had started earlier, we wouldn't have had-- we would have been able to deal with those situations better.

So based on that, what was well? Well, the great thing is that we did start right away just setting up everything we needed to work. We set up our email thread, our Google Drive folder. We decided on Unity first meeting, and we set up the GitHub project right away so that we could all collaborate.

And the nice thing was in our Google Drive folder we put our task list. We really utilized that. And our email thread, like other teams said, it did get a little long and complex. But it was just so nice to have. And later on, we actually also got a group text messaging service. So that works really well dealing with that last minute hustle kind of stuff.

The next thing I went really well is I told you that our scope was way out there. We realized that very quickly, and we just started cutting, cutting, cutting. So we cut items. We cut interactive AI characters. We cut playable quizzes. We just cut everything that wasn't key.

Because our game, even without all the things, already had a lot of components. And then once we have a playable game, the next thing we did was we looked into feedback. So one of the main feedbacks we got was our game was not visually cohesive. It did not make sense.

The nice thing about Score High was that because you're playing as an MIT student, you're just getting work done, people understood how to play and what they were supposed to do. But they didn't understand that. So if you look at the thing on the left, you're probably all just staring at it being like, what's that. The rectangles are buildings, and the bottom's the stats bar, on the right is the schedule.

It's confusing. People didn't notice the stat bars, or they thought they were buildings, and things like that. So we responded to that right away. And we said, we need to clarify this. We need to separate the status, separate the schedule, and make the map very clear, and pretty, and easy to get around. So that was one thing we responded to, and I think it went well.

The next thing that we responded to feedback was we really listened to players, not only big picture, but on smaller things. Players wanted WASD, so we put WASD. They wanted a clear way to leave buildings.

They wanted to know what was going on when they were in a building. So we actually inserted a progress bar that says, what's going on this building, how it's affecting you. And then to leave, instead of pressing space bar, which people found unintuitive, they press a button that says leave-- much more intuitive.

Now given all that, we did make a really good game. But there are definitely some things we would change if we were to do it again. As I mentioned before, start with something simpler. We did not design the game around the scope of the project. And if we were to do this again, we definitely would.

We tried to bite off more than we could chew. And related to that, minimize the number of components and understand how they will interact. Because especially if you're trying to break down tasks, people need to know what has to be conveyed between different components.

Plan for the worst. Midterms suck. People get sick, or go out of town. And laptops break. Literally all of these things happened to us. We're still waiting to hear, is the laptop working. We don't know. Somebody's laptop broke last night and they were working on something and finishing it up. And suddenly all that work's gone.

So as I said, start earlier, plan for the worst, and just get things done. Finally, it worked out really well. And thanks for listening. Any questions? Any questions?

AUDIENCE: This was Unity?

STUDENT 10: Yeah, Unity. I'm going to take that as no questions.

PROFESSOR 1: Great. Thank you.

STUDENT 10: Beautiful.

PROFESSOR 1: Thank you so much. And actually round of applause for everyone here. You actually did a really great job. I think we're going to give you more detailed feedback in a few days. But I think one thing we heard definitely is by working in these large teams, you're coming across these issues that you don't initially-- you still need tools to get over some of the management issues you're finding out, the communication issues you having, the scheduling issues you're having.

Part of this is just experience. That's kind of why we just throw you in the deep end, is just to figure out what are all the problems. So that we could then talk about and have some common things to talk, how we're going to solve those things. Looking at the schedule, we'll probably end up moving a couple things earlier. Did you have a comment?

PROFESSOR 2: I just wanted to make one comment. It's possible your groups might be slightly larger for the next project. I know. But you've got a lot more time because you've got seven to eight weeks.

And what I really want to encourage you guys to do is if you realize you're having communication and organization problems with your group, if you're not sure how to organize things, or if it's not working, stop by the office and talk to us. I don't think we said this clearly enough in the previous projects.

But yes, our goal is, in fact, to throw you out into the deep end. But we're not trying to throw you out in the deep end without at least a floaty to hold onto, or a safety rope or something. We are happy to sit down and talk with you, a small member of your group, or your whole group about how to come up with some individualized solutions to your team's communication and organizational problems. OK?

PROFESSOR 3: That's just a reminder, if you don't know where our office is, it's in the syllabus. It's in building 26 on the ground floor. You can see our rooms all have the MIT Game, that logo on it. And what Rick was saying about tools, not all our tools are like mechanical tools.

Not all our tools are like are things that you put in a spreadsheet. The things like the meetings that we've been talking about, where you are actually supposed to talk to each other. It's important to actually talk to each other during those meetings, for instance.

Of course, if you don't have a way to be able to schedule those meetings because it's hard to get people together, you need to find a replacement to be able to have those opportunity to talk with each other. You can't just say, well, we don't have time to do this thing, therefore we're not going to do it.

However, this being the final project, you're going to have a lot of flexibility to try out different ways to communicate with your team. So what worked in your previous projects should give you a good basis on what you can do in the future, but may not necessarily work with your future team because it might be different groups of people.

And learn from the previous three projects about what worked. Try it out. And that doesn't work, try something different. You have time this time around. Although still, eight weeks goes by really, really, really fast. So don't over scope.

PROFESSOR 1: So we actually are running really short on time today. We've got a really long-- a lot of content that Pablo was going to go over with us. So let's take a five minute break. I'm actually going to skip the project 4 introduction. And I'll put the slides up on Stellar.

And I'll give that on Monday morning. It's really just me saying out loud what all the-- Monday class. Don't take everything I say literally. It's the spirit. Monday at 1 o'clock. So the slides will be up.

I'm really just going over what it actually says in the schedule by saying it out loud. So you can hear it and see it. But we'll do that on Monday. So take a break right now. And I'm going to get Pablo set up.

You can see some folks, Pablo?

PROFESSOR 4: I can in the distance, yes. Hello, everyone.

PROFESSOR 1: So let me crank up the volume. All right. the room is yours.

PROFESSOR 4: All right.

PROFESSOR 1: Whoa, loud.

PROFESSOR 4: Thank you again to all of you for still being there. Thank to the team in charge of the [INAUDIBLE] for persevering with the invitation on the guidance of how to use this time. I'm sure you, or at least some of you, should remember the slide that I hope is on the screen.

There is a comfort zone where people feel safe. And most often, where people are safe, not enough happens. And one of the things-- one of the reason why I hope we can work together is to see if we can create true games.

The magic circles that are slightly outside of the comfort zone of people will be a Red Cross volunteer, a Red Cross staff, a person who is a scholar, a donor, a government official to try to make something new happen. And that something new can be just understanding.

It can be about dialogue. It can be about perceptions, or it can be about some of the ingredients that eventually lead to action. So now let's see if this thing changes. Did you see a change in slide?

AUDIENCE: Yes.

PROFESSOR 4: Good. So let me move this thing. We're going to start by playing [INAUDIBLE]. I'm going to invite everyone to stand up. And Reid, can I ask you and someone to partner up with you to be in a place where I can see you.

PROFESSOR 1: OK.

PROFESSOR 4: Maybe Sarah, or whoever you choose.

PROFESSOR 3: I'll do it.

PROFESSOR 4: [INAUDIBLE].

PROFESSOR 1: Where are we in the camera? Hey, there we are.

PROFESSOR 4: [INAUDIBLE]

PROFESSOR 1: Stand.

PROFESSOR 4: So everybody find-- yeah, right. When I say stand up, I mean it. So everybody find a partner, shake hands with your partner.

PROFESSOR 1: Oh, no. Cutting out.

PROFESSOR 4: What you're going to do now is each one with two in the duo is going to [INAUDIBLE].

PROFESSOR 3: Oh, you've dropped out.

PROFESSOR 1: Oh no.

PROFESSOR 3: How's the network?

PROFESSOR 4: Uh oh.

PROFESSOR 1: Yeah, we're getting a little bit of network drops here.

PROFESSOR 4: OK, may I suggest the following then. If it is a matter of bandwidth, you can stop your video and that should work.

PROFESSOR 1: We'll do that.

PROFESSOR 4: You'll be in charge of through audio making sure I know--

PROFESSOR 1: Yeah, it dropped again.

PROFESSOR 4: But you're still there and kind of following. OK, can you hear me now?

PROFESSOR 1: We can hear you.

PROFESSOR 4: So each one of you is going to hold an imaginary deck of cards. Cards are number 1 to 10. And I want you to shuffle these imaginary cards. I want you to take the top half of the deck and swap it with your partner. And then you shuffle again, those imaginary cards. So you should have a lot of imaginary cards numbered 1 to 10 in random order.

If you're thinking, what does this have to do with Red Cross, we'll get there. So now, this is crucial. Each one of you is going to take the top imaginary card, make some body movement to reveal the moment when you're flipping it. And [INAUDIBLE] state that the number that is on the top card.

For example, [INAUDIBLE] as well so say your number at the same time.

PROFESSOR 3: 4.

PROFESSOR 1: 6. Oh hey, you don't have 10 fingers.

PROFESSOR 4: Let's try it again using body language to make sure it's simultaneous.

PROFESSOR 3: 1, 2, 3--

PROFESSOR 1: 10.

PROFESSOR 3: 5. 5.

PROFESSOR 4: All right. So I couldn't hear the number, but first of all, you don't need to say 1, 2, 3. You can use body language to make it happen simultaneously. It's to your advantage to make it as fast as possible.

Two things can happen. If the two players say different numbers, there's no consequence and you try again a different number--

PROFESSOR 1: Oh, no. The video is slowing down.

PROFESSOR 4: --or the same number, whichever you want, any-- [INAUDIBLE]. OK, it's the audio [INAUDIBLE].

PROFESSOR 1: Yeah, the audio is cutting out. And the video is pausing. Do you want to just switch back to me controlling the slides and you on audio only?

PROFESSOR 4: Sure.

PROFESSOR 1: OK, let's do that.

PROFESSOR 3: I think he can just turn off his--

PROFESSOR 1: So yeah, if you just go ahead and turn off your video, and I'll make sure I have slides.

PROFESSOR 4: All right, yes. Let me get back to this. How do I do it? There.

PROFESSOR 1: Cool. Let me go back to this.

PROFESSOR 4: So is the audio now better?

PROFESSOR 1: So far, yeah.

PROFESSOR 4: OK, good. So what I was going to say is that the two players are going to say numbers simultaneously. If the two numbers stated simultaneously are different, you keep going. You keep saying numbers at the same time. But if the two players say the same number at the same time, the first player to say "snap" takes all the imaginary cards and wins one imaginary point.

PROFESSOR 1: OK.

PROFESSOR 4: You keep going, OK? And you start again. The purpose is in one minute or less to snap as much as you can. Those are the rules. Shuffle your cards. Ready, set and go. You have less than a minute.

PROFESSOR 1: 5.

PROFESSOR 3: 4.

PROFESSOR 1: 6.

PROFESSOR 3: 2.

PROFESSOR 1: 10.

PROFESSOR 3: 7.

PROFESSOR 1: 8.

PROFESSOR 3: 3.

PROFESSOR 1: 3.

PROFESSOR 3: 9.

PROFESSOR 1: 2.

PROFESSOR 3: 12.

PROFESSOR 1: 1

PROFESSOR 3: 2.

PROFESSOR 1: 7.

PROFESSOR 3: 6.

PROFESSOR 1: 5.

PROFESSOR 3: 8.

PROFESSOR 1: 4.

PROFESSOR 3: 3.

PROFESSOR 1: 10.

PROFESSOR 3: 4.

PROFESSOR 1: 4.

PROFESSOR 3: 5.

PROFESSOR 1: 6.

PROFESSOR 3: 3.

PROFESSOR 1: 3.

PROFESSOR 3: 3.

PROFESSOR 1: Snap!

PROFESSOR 3: 3. OK, you got the point. 1.

PROFESSOR 1: 5.

PROFESSOR 3: 6.

PROFESSOR 1: 6

PROFESSOR 3: 2

PROFESSOR 1: 7.

PROFESSOR 3: 1.

PROFESSOR 1: 7

PROFESSOR 3: 2.

PROFESSOR 1: 8

PROFESSOR 3: 3.

PROFESSOR 1: 8.

PROFESSOR 3: 8, snap!

PROFESSOR 1: Ah, OK, you get a point.

PROFESSOR 3: All right.

PROFESSOR 1: 9.

PROFESSOR 3: 4.

PROFESSOR 1: 10.

PROFESSOR 3: 3

PROFESSOR 1: 4.

PROFESSOR 3: 8.

PROFESSOR 1: 7.

PROFESSOR 3: 6.

PROFESSOR 1: 6.

PROFESSOR 3: 2.

PROFESSOR 1: 3.

PROFESSOR 3: 1.

PROFESSOR 1: 4.

PROFESSOR 3: 1.

PROFESSOR 1: 5.

PROFESSOR 3: 5.

PROFESSOR 1: Snap!

PROFESSOR 3: Snap! All right, I think you got it.

PROFESSOR 1: OK.

PROFESSOR 3: All right.

PROFESSOR 1: 3.

PROFESSOR 3: 2.

PROFESSOR 1: 4.

PROFESSOR 3: 3.

PROFESSOR 1: 7.

PROFESSOR 3: 2.

PROFESSOR 1: 8.

PROFESSOR 3: 8.

PROFESSOR 1: Snap!

PROFESSOR 3: Ah, OK. You got two points.

PROFESSOR 1: OK.

PROFESSOR 3: All right, is that good? Or go again? OK.

PROFESSOR 1: [INAUDIBLE]. 5.

PROFESSOR 3: 5

PROFESSOR 1: 7.

PROFESSOR 3: 2.

PROFESSOR 1: 8.

PROFESSOR 3: 9.

PROFESSOR 1: 10.

PROFESSOR 3: 3.

PROFESSOR 1: 3.

PROFESSOR 3: 6.

PROFESSOR 1: 2.

PROFESSOR 3: 12. That's [INAUDIBLE].

PROFESSOR 1: 1.

PROFESSOR 3: 8.

PROFESSOR 1: 5.

PROFESSOR 3: 9.

PROFESSOR 1: 4.

PROFESSOR 3: 10

PROFESSOR 1: 3.

PROFESSOR 3: 4.

PROFESSOR 1: 2.

PROFESSOR 3: 5.

PROFESSOR 1: 5.

PROFESSOR 3: 6

PROFESSOR 1: 7.

PROFESSOR 3: 8.

PROFESSOR 1: 9.

PROFESSOR 3: 2.

PROFESSOR 1: 3.

PROFESSOR 3: 3.

PROFESSOR 1: Snap!

PROFESSOR 3: Ah. OK, [INAUDIBLE].

PROFESSOR 1: So I have four?

PROFESSOR 3: I think that you win. I think you just win this game.

[INTERPOSING VOICES]

 

PROFESSOR 1: Are you talking?

[INTERPOSING VOICES]

PROFESSOR 4: [INAUDIBLE].

PROFESSOR 1: OK, I can't hear you. Should I shut them up?

PROFESSOR 4: Yes, please.

PROFESSOR 1: OK. All right, can we hear you?

PROFESSOR 4: Well, I was actually trying to be heard for the past 30 seconds. OK, so what we're going to do now-- can you hear me?

PROFESSOR 3: Yeah.

PROFESSOR 1: Yes.

PROFESSOR 3: Yeah.

PROFESSOR 4: Good. What you are going to do now is to find-- we are going to play a second round with two minor differences. The first minor difference-- don't do it yet. But you have to shake hands with a different person. You will find a new partner.

PROFESSOR 1: OK.

PROFESSOR 4: The second difference is that instead of having numbers 1 through 10, you are going to have the names of animals.

AUDIENCE: What?

AUDIENCE: Holy crap.

PROFESSOR 4: Each one of you should know more than 10 animals. So it shouldn't be a problem. Find your partner. Shake hands.

PROFESSOR 3: Someone else?

PROFESSOR 4: Shuffle your deck. [INAUDIBLE].

PROFESSOR 3: Oh.

PROFESSOR 4: And I--

PROFESSOR 3: OK, you guys play.

PROFESSOR 4: --request you stop it in 30 seconds or less.

PROFESSOR 3: We're suppose to do somebody else, right?

PROFESSOR 1: Yeah.

PROFESSOR 4: So let's do anybody else. How about I play with you. You play Rick.

PROFESSOR 1: Go.

[INTERPOSING VOICES]

 

PROFESSOR 1: All it's 30 seconds. OK, all right, back to the screen. OK.

PROFESSOR 3: OK.

PROFESSOR 1: All right, Pablo, you're back.

PROFESSOR 3: This was harder.

AUDIENCE: Yeah.

PROFESSOR 4: So clearly I'm not in the room. Can you hear me guys?

AUDIENCE: Yeah.

PROFESSOR 4: Good. Even though I'm not in the room, I imagine that what usually happens may have happened again here. First of all, it seems much harder to snap. Second, more people find themselves going, ah, and not saying an animal. There was like clogging of the brain cells.

And then very interestingly, very often people don't listen to each other. So for example, the first time I played, I was saying, dog, cat, mouse, and my partner was saying, zebra, giraffe, lion. And it took us a long time to notice that we were in different universes, that we were never going to snap.

And then interestingly, when you finally say the same words, a lot of people don't snap. Their brain cells do not get in the right place. So when you play the next round, I want you to go back to your original partner.

And in your deck of cards, you are not going to have numbers 1 through 10. You are not going to have animals. You are going to have words or concepts that you associate with the Red Cross.

[INTERPOSING VOICES]

 

PROFESSOR 4: Whatever you want--

PROFESSOR 1: OK.

PROFESSOR 4: --it has to be short, three words or less.

PROFESSOR 3: OK.

PROFESSOR 4: And of course, you're trying to snap. So you have 10 seconds [INAUDIBLE].

PROFESSOR 3: OK, all right.

PROFESSOR 1: Yeah.

PROFESSOR 4: [INAUDIBLE].

PROFESSOR 1: OK, sure.

PROFESSOR 4: On your marks, ready, set, go.

[INTERPOSING VOICES]

 

PROFESSOR 3: You want to try this?

STUDENT 11: [INAUDIBLE].

PROFESSOR 3: OK. One--

STUDENT 11: I don't know anything about Red Cross.

PROFESSOR 3: Yeah. Health.

STUDENT 11: [INAUDIBLE].

PROFESSOR 3: [INAUDIBLE].

STUDENT 11: [INAUDIBLE]. Red.

PROFESSOR 3: Beds.

STUDENT 11: People.

PROFESSOR 3: People Oh, snap.

STUDENT 11: Snap. You got it.

PROFESSOR 1: All right, back to the screen.

PROFESSOR 3: OK, [INAUDIBLE].

PROFESSOR 1: All right, back to you, Pablo.

PROFESSOR 4: OK, thank you all. If what usually happens in this game happened in the room, first of all, it's even more difficult for people to come up with words. It's even more difficult to snap And much more than before, people are realizing in the process of trying to play this game, that they don't really know what they think about the subject matter we proposed in the third round of the game.

So what I'm going to invite you to do now is very quickly form groups of three. Don't start yet. Let me finish explain. Form groups of three.

PROFESSOR 1: Oh, no. Your audio just cut out and the video just cut out. Are you back?

PROFESSOR 4: I cannot hear.

PROFESSOR 1: Can you hear us now?

PROFESSOR 4: OK, now I can hear.

PROFESSOR 1: Yeah, yeah, the audio just cut out briefly. But you're back again.

PROFESSOR 4: OK, good. Now I'm back with audio and video?

PROFESSOR 1: You're back with audio. I don't see the video. But I've got the slide up.

PROFESSOR 4: So let me take video out of there. So what we are going to do now, if you can hear me--

PROFESSOR 1: Yes.

PROFESSOR 4: --is to form groups of about three people, [INAUDIBLE]. And you're going to, as a trio, write four terms, four things that you would have wanted to write in that last deck of cards. Is that clear? So it's not about numbers. It's not about animals. It's about words that are constantly associated with the Red Cross. Form a trio and write four things that you hope would be in the deck of cards so you can try to snap Go. You have three minutes.

PROFESSOR 3: Oh, OK. Everyone, gets four cards.

PROFESSOR 1: Actually, you can just use scrap paper too. This is just in case you don't have any.

[INTERPOSING VOICES]

 

PROFESSOR 3: Do you have enough cards? I've got a lot. I've got another deck here. Do you need some more cards? There's a pile here.

STUDENT 12: Thank you.

PROFESSOR 3: Yeah, there you go. Yeah.

[INTERPOSING VOICES]

 

PROFESSOR 3: Extras? Everyone has four, right? Oh, groups of three.

[INTERPOSING VOICES]

 

PROFESSOR 3: I gave you a few extra just in case you make a mistake.

PROFESSOR 4: Rick, can you hear me?

PROFESSOR 1: Yeah, I can hear you.

PROFESSOR 4: OK, so I want you to give them no more than 30 seconds left.

PROFESSOR 1: OK.

PROFESSOR 4: And let them know that time is running out.

PROFESSOR 1: All right, 30 seconds left.

PROFESSOR 4: And then, Rick, what [INAUDIBLE] going?

PROFESSOR 1: The slide is showing, yeah.

PROFESSOR 4: Sorry?

PROFESSOR 1: The slide?

PROFESSOR 4: No. Well, yeah, actually, [INAUDIBLE], no slide yet.

PROFESSOR 1: OK.

PROFESSOR 4: It's easier if you just do it.

PROFESSOR 1: OK.

PROFESSOR 4: What I want you to do is to pick some trio, ask the trio to choose one of the words [INAUDIBLE] they have on their cards and invite all the other groups to say "snap" if they wrote that exact term.

PROFESSOR 1: OK, did we get that? So one trio come up and give one of your terms. Just stand up and start over here. So what's one of your terms?

AUDIENCE: Disaster relief.

PROFESSOR 1: Disaster relief? Snap, snap. How many?

AUDIENCE: Snap.

PROFESSOR 1: Snap. Three. So we had four or five.

PROFESSOR 4: OK, now choose another trio.

PROFESSOR 1: OK, another one.

PROFESSOR 4: Another trio to say one of your words.

PROFESSOR 1: All right, term?

AUDIENCE: Red.

AUDIENCE: Snap.

AUDIENCE: Snap.

AUDIENCE: [INAUDIBLE].

AUDIENCE: Red

PROFESSOR 1: What was the word?

AUDIENCE: Red.

AUDIENCE: Red.

PROFESSOR 1: Red? All right.

PROFESSOR 4: OK, so do the same with a few more trios, maybe three or four more trios.

PROFESSOR 1: OK.

AUDIENCE: Blood donations.

PROFESSOR 1: What's that?

AUDIENCE: Blood donations.

PROFESSOR 1: Blood donations.

AUDIENCE: Snap.

AUDIENCE: Snap.

PROFESSOR 1: Snap, snap.

AUDIENCE: Snap.

PROFESSOR 1: Snap, snap, snap. OK, another trio. Yeah.

AUDIENCE: Aid.

PROFESSOR 1: Aid?

AUDIENCE: Snap.

AUDIENCE: Snap.

PROFESSOR 1: Snap, snap, snap. All right, another one.

AUDIENCE: CPR.

PROFESSOR 1: CPR?

AUDIENCE: Ooh.

PROFESSOR 1: No CPR?

PROFESSOR 4: Interesting. No snapping with that one, huh?

PROFESSOR 1: OK.

PROFESSOR 4: OK. So there are two reason why I wanted to do this. Thank you all very much. If we had the time, we would play this game in a version that has winners and losers, where we would eliminate the most and the least snaps. And the second most and second least snaps are the winners, for example. So you have to choose which of your cards to say, and so on.

There are two reasons why I wanted to share this with you. One is to re-energize the room and bring it back into the game zone. And the second one-- it's the flavor of one of the games that I hope maybe some you will consider doing.

When we play this game in the context of [INAUDIBLE], for example, we play [INAUDIBLE], first with numbers, then with animals, and then we with the subject matter of the course, which can be climate change. It can be humanitarian, law. It can be [INAUDIBLE]. It can be shelter. It can be urban risk.

And people come up with words. And they write them down. And we keep those papers. And then after [INAUDIBLE], which can be an hour, or a day, or a week, we [INAUDIBLE]. And we ask them to form different trios and to write the words that they [INAUDIBLE]. And that collection allows us to compare the before and the after on how the thinking changed.

[INAUDIBLE], did you show the slide that has the two printouts?

PROFESSOR 1: Yeah, I got that.

PROFESSOR 4: So [INAUDIBLE] and change this here. This is where we played about insurance. The one on the left was the before. And you see [INAUDIBLE] and [INAUDIBLE], premium, accident, disaster.

When we played the game afterwards, there were more nuanced terms. There was [INAUDIBLE] collected. There was buffered. There was future. There was return. There was long term. And this was very difficult for us to see how the thinking changed as a result of the session.

So moving on to the next slide that says choices for your game project, these are the six choices that I want to make available to you. The zero one is to create a digital version of the game that could be played along the lines of what you just did, but for us an accelerated collection of data, so that everyone can see at the same time what just happened. I'll explain it more later.

Then in the list, you see UNICEF Ghana. And this is about cholera, a waterborne disease that is very tough. And invite two groups if possible to take this one, because it's an important one to us. And it's about helping schoolchildren in West Africa to manage health risks.

The next one is about linking early warning forecasts with early action, decisions that can help save lives. Since it is 75 in Boston or Cambridge today, we thought it would be relevant to say that we wanted to focus on heat waves. We could make it about hurricanes. We could make it about volcanic eruptions. We could make it about many things. But we invite heat waves, because there are a few reasons that make it useful to us.

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.

The fourth one is Ebola. As you can imagine, this is a very challenging time for my colleagues. And maybe some of you can give a hand. And the last one involves adaptation to climate change. I think you may have met [INAUDIBLE], my partner. He designed [INAUDIBLE] project for an organization called Plan International, focused on work with children [INAUDIBLE].

So moving on to the next slide, before we go into the details of each one of those potential topics, I wanted to show you some thoughts about why digital games for these things. As you remember, hopefully, from the previous visit to MIT, the vast majority of our games have been non-digital. We've played them face to face. They have been very good for what thew were intended to do. But they were reaching a very small group of people, only those who were here.

Recently, we designed-- or recently collaborated in the design of our first digital game that was to be used in a MOOC with [INAUDIBLE]. And it reached 35,000 people, which I'm pretty sure has doubled the number of people that, since the beginning of my work with games, have been playing games that are non-digital. There's clearly [INAUDIBLE] to many, many people.

And we're thinking of Red Cross staff, colleagues of mine who have a job, because this is their managers, [INAUDIBLE], whatever it may be. There's also Red Cross volunteers, people who are not paid [INAUDIBLE] some work. It could be digital games that people at risk, people who would make some decisions to save their lives or save the lives of their neighbors.

It could be about youth and the schoolchildren, who maybe don't know something could learn through a game, or had a [INAUDIBLE] that could inspire through digital games. And there's also the bigger interpretations, especially now in a time where there's crowd funding, there is people who have the ability to act in [INAUDIBLE] number of little things and make them bigger.

[INAUDIBLE] is that games, including digital games and [INAUDIBLE] of the many ingredients needed to support a bigger change. We are not widely optimistic. It's not that we believe that someone lives their life in a certain way, and then they play a game, and boom, they're a different person, and they change their behavior.

Maybe that can happen. But we are aware that it takes more than a simple game to play to change minds. But we believe that games can help invite people to change behavior [INAUDIBLE].

It can be about creating awareness. It can be about engaging their desire, their want to learn more. It can be about a way give them interest, the appetite. Or it can be about inspiring people to take something that [INAUDIBLE] they already do and put it into motion, [INAUDIBLE].

Importantly, because of [INAUDIBLE]-- sorry-- last bullet. There's so much hope in digital technology, in people who can program, in people who have cell phones and [INAUDIBLE] Africa. And we see a lot of room for growth within our team designing and deploying digital games, particularly with UNICEF, but also with many examples of organizations [INAUDIBLE].

So moving on, I should probably come to the next one. Rick, would you like to either inject anything or invite questions at this stage before moving to the details of each game?

PROFESSOR 1: Sure. So yeah, are there questions about the target audience or the reasons for digital games before we move on? Yeah, one question?

AUDIENCE: Will we be able to play test with our target audience?

PROFESSOR 1: So play testing with the target audience-- are any of these folks in the Boston area that we could invite in for a play test session?

PROFESSOR 4: Almost certainly not. So what we can do is to play the games with people who are as close as we can get. So you know, schoolchildren [INAUDIBLE], most of them are different from children in West Africa. But I imagine that [INAUDIBLE]. There are a lot [INAUDIBLE] prototype for Ghana if you play it with children in Cambridge or [INAUDIBLE].

PROFESSOR 1: OK.

PROFESSOR 4: Having said that, I may be able to get colleagues in developing countries to download your code and play in [INAUDIBLE]. So [INAUDIBLE] on the possibility for play test with the target audience. But it is in the nature of this work to work for the benefit of developing countries.

So we'll have to accept that there is going to be a limited ability to play test. And that's something that can happen in the early phases of the project design. Basically, we could do it if you had the budget for a planet ticket. And it might be hard.

PROFESSOR 1: Was there another question I saw? Yeah.

AUDIENCE: Are you envisioning this being used as a one on one thing, where one person is playing the game? Or are you envisioning this being used as sort of an alternative to a presentation, similar to the games that we've seen here.

PROFESSOR 4: Yeah, it depends on the game. Generally speaking, mostly because of the [INAUDIBLE] in your ability to spend student time on both the games, we are sticking to ideas that can be implemented for one player with one computer or one device, [INAUDIBLE]--

PROFESSOR 1: Yeah.

PROFESSOR 4: --which can happen in the house, happen in the street when they're waiting for the bus. Or it can happen in a group, in the context of a [INAUDIBLE]. But we decided to [INAUDIBLE] multiplayer variable for more sophisticated endeavors.

PROFESSOR 1: Yeah. So yeah, when I talk further about the constraints on Monday, I'll be mentioning that you could do a single player or multiplayer game. But it will be a single device, no networking. And we are asking you to think about the spectator experience.

So what does it look like to be looking over the shoulder? What does it look like to be looking down on the table, if it's an iPad game or a tablet game? What does it like if somebody's playing the game on a screen like this? Consider one of those. And design it towards one of those. Yeah?

AUDIENCE: So by schoolchildren, is this elementary, middle, or high school? And also, can we assume they speak English?

PROFESSOR 1: So for schoolchildren, is there a particular age range, elementary, middle, or high? And is there an English language assumption going on?

PROFESSOR 4: Yes. So yes to English. And it will be [INAUDIBLE] official language is [INAUDIBLE]. So children go to school and learn at some age. And different products have different age ranges. But generally speaking, it's roughly the ones that are schoolchildren are not [INAUDIBLE]. So we'll get to that in the details for each game.

PROFESSOR 1: OK.

PROFESSOR 4: So moving on, if you want to press the slide for the [INAUDIBLE].

PROFESSOR 1: Yeah.

PROFESSOR 4: Thumbs up.

PROFESSOR 1: Yeah.

PROFESSOR 4: Those of you who were at the game's initial [INAUDIBLE] may remember the game where you all standing, and there was a die, [INAUDIBLE]. And if there was a 6, you had to do the umbrella. Otherwise, you had to do thumbs up. Or if you push again, [INAUDIBLE] sitting [INAUDIBLE] on the cement, and [INAUDIBLE].

PROFESSOR 1: Yes.

PROFESSOR 4: Those are the two basic [INAUDIBLE] that we generally remember things. You either do the usual, or do something new. And what we want is to [INAUDIBLE] a player the idea that you can't make wrong decisions without negative consequences. But it's really hard to know whether the decision is the right one or the wrong one before the disaster [INAUDIBLE].

[INAUDIBLE] most of you in the process of designing games will digitally incarnate some form of mechanic that [INAUDIBLE] that. The player is going to say, do I do the usual thumbs up or do I start [INAUDIBLE] the umbrella.

It will depend, of course. If it's a game about health, an umbrella won't be it, right? It will be some other image. But you get the point. It's about the repetitive act.

The next slide, which I also showed the previous group, this is more what we want. We want players to experience an aha moment, a moment of discovery that is the result of the process where they go though some not knowing what the next choice is. Otherwise, it would be too obvious. It would be [INAUDIBLE]. And [INAUDIBLE]. So good luck to all of you in coming up with an [INAUDIBLE] balance because huh and aha.

So moving on to the next one, this is about the first [INAUDIBLE]. It is in the context of this game that you just played. As I mentioned, when we played with 200 people, we can very quickly match all the cards [INAUDIBLE] by groups of three. And we can quickly enter them into a computer connected to internet, [INAUDIBLE] before and after, so people can see at the end of the workshop how their own thinking has changed.

Now, when we went through the activity of Rick pointing to a geometric, choosing a word like [INAUDIBLE], and other people saying [INAUDIBLE]. If you have 50 people in the room, it becomes much more difficult. Because if you're doing [INAUDIBLE], it becomes boring.

So what I ask you to consider is to create a digital tool that can be embedded or utilized or employed to [INAUDIBLE], so that we can collect and process information of what people are thinking. So you'll be face to face, just like you were then.

But I imagine that your interface, this could be made with 3,000 people [INAUDIBLE]. And then each [INAUDIBLE] works. And there's some game mechanic that creates an incentive and pitches [INAUDIBLE] at least [INAUDIBLE] of the time that helps people visualize their result.

And that helps make them analyze the data, to assess the input to monitor or to evaluate, and eventually to [INAUDIBLE] this animation of this [INAUDIBLE] concepting. But folks, you have no idea how much [INAUDIBLE] was shouting at the first round.

[INAUDIBLE]. And you were so energized. That's great. We love that. But we need to channel that so it becomes more useful to the subject. So the chances [INAUDIBLE], if you deliver something, and gain a product life that works, it's near guaranteed that we will use it.

If your tool helps us collect information in a somewhat playful way, and share it, and think about it, we're going to use it. And we're going to use it in five continents, starting the day after you [INAUDIBLE]. And there are researchers for this. There are documents that cover [INAUDIBLE] called data [INAUDIBLE] initiative. And you can also consult with me and [INAUDIBLE]. I should be here some of the time if you have any questions about it. [INAUDIBLE] like what we did for a tool similar to this one.

PROFESSOR 1: Was that a question?

PROFESSOR 4: I asked if you prefer that we move on to the next game idea, or if we pause and invite for questions.

PROFESSOR 1: Yeah, let's do questions after each idea, just really briefly. So any questions about this game? Yeah?

AUDIENCE: I thought we were not supposed to make anything that has to do with a network.

PROFESSOR 1: Yes. So in this game, there is a little bit a networking going on. If you were to do this game, it would mean it's not a multiplayer networking experience. But you are transmitting data to some kind of server.

So that's where this one gets hairy. It looks like a simple design, but it's actually a bigger-- there's a bigger back end to this one.

PROFESSOR 3: This is possibly, just by looking at it fully, it's possibly, technically, the most difficult one. Because it looks like it's still a networking game, even though we are encouraging you to do single players, single device.

PROFESSOR 1: And designing for touch is very difficult too. It just kind of it gets big. Any other questions?

PROFESSOR 3: There probably is a middle ground where you can think of, all right, what can be done with a single computer that would still make it easier for someone like Pablo to be able to run this in a workshop, for instance. Even just making his job slightly easier. Remember, we just played this game with imaginary things.

What can we do that doesn't required the players to have a device, but speeds up the process from a central computer to be able to say collective data? I don't know what that would look like. That would be more of a design challenge, rather than a technical challenge, but possibly more feasible for the size of this class.

PROFESSOR 4: [INAUDIBLE] the results are shared in real time. But if people have a cell phone, they can just send an email to the words to some address. And then some [INAUDIBLE] someone punched buttons these skills then. [INAUDIBLE].

Write down [INAUDIBLE] we don't understand the [INAUDIBLE]. So as it was said before, anything [INAUDIBLE] that you may have to an [INAUDIBLE] experience, our to improve a [INAUDIBLE], would be appreciated. If no group chooses this one, no problem.

PROFESSOR 1: So let's move one. Actually Pablo, can you turn off the screen sharing. Maybe that will speed up the--

PROFESSOR 4: Oh, I wasn't aware that I wasn't sharing.

PROFESSOR 1: Yeah, I just noticed it too.

PROFESSOR 4: Here it says I am not sharing. Weird. Let me go to this. Stop sharing screen, good.

PROFESSOR 1: There we go. So let's go to the next one.

PROFESSOR 4: The next one is the important one. It's the UNICEF Ghana. UNICEF is the most loved UN agency. Well, I don't have [INAUDIBLE]. Generally speaking, it's fun for a very well [INAUDIBLE] agency. It works with children and education and it does very good [INAUDIBLE] work.

And the team in Ghana has decided to reach out to [INAUDIBLE]. Originally it was in the context of cholera. But they also have some money for Ebola and cholera. And they want us to design games for school children that would help them becoming familiar with an improvement instrument of risks [INAUDIBLE].

I have no contract yet. But it's very likely that this relationship will grow, and will grow in time, and will grow in size, and will be able to get into the digital very soon. So the context is that cholera is a waterborne disease and is on the rise, in part because of [INAUDIBLE], in part because of the organization, in part because of the changing character of flooding, access to water, and so on.

It's almost [INAUDIBLE] risk of getting cholera in countries that the disease is epidemic. There are [INAUDIBLE] million cases every year. And if you've never experienced it, I can assure you, it leads to a very miserable experience. It's a [INAUDIBLE] disease.

And of course it changes from one year to the next. But there's 100,000 people dying out of cholera every year. And that's not good. And importantly, many of those deaths are avoidable if certain measures are taken.

Some of those measures are difficult. For example, providing clean water [INAUDIBLE]-- that is not something you can do in five minutes. But other things are important and manageable. For example, how [INAUDIBLE] and protection of water sources, or basic hygiene and using soap-- many of those are simple.

So we have a money project-- work with some children in Ghana. Rick will have all details of the project and description. The purpose is to help reduce the risk of waterborne disease, in particular, cholera. The chances of risk are very likely [INAUDIBLE] something to be further developed.

I would be very surprised between and December if [INAUDIBLE] something [INAUDIBLE] thousands and thousands of children. But if any of you have the [INAUDIBLE] clean, clear, useful game [INAUDIBLE], then maybe we can become direct [INAUDIBLE] or someone could be hired with money [INAUDIBLE].

There's the cholera toolkit, which if you pick-- show the next slide. You see a [INAUDIBLE]. There's a chapter 1 program shown. There are many stages. There's the situation of preventing how to coordinate, how to prepare community aspects, all sorts of things.

The toolkit [INAUDIBLE] is extremely rich and detailed. And we are now conversing with-- actually, we need two days. We should be getting from them, which are the thing that the [INAUDIBLE] practice.

So who ever ends up taking this challenge, and we hope it will be two groups, it's going to be something that very directly capable of [INAUDIBLE] class. And that must feel good for whoever successfully takes on that.

I do not remember the age group. But I'm pretty sure it was less than 18 and more than 10. But it may be more narrow than that. I can't remember.

Ghana is an English speaking country. It in [INAUDIBLE] East Africa. In terms of [INAUDIBLE], the UNICEF team works with [INAUDIBLE] games. I'm going to pause here and invite for questions.

PROFESSOR 1: Any questions about this one? OK, no questions on this one.

PROFESSOR 4: Very good. Was I very boring or very clear? Moving on to the next one. If you're having [INAUDIBLE] slide show, you can see through the text?

PROFESSOR 1: Yeah.

PROFESSOR 4: Good. So this one is linking early warning with early action. Science [INAUDIBLE] progress of something [INAUDIBLE] likely to accompany [INAUDIBLE] future. And there are timescales that are going to be at the seasonal level, like El Nino, and weeks to months.

We're more likely to focus on it hours to days. And in the meantime, in the case of [INAUDIBLE] that's very useful, but there is a lot being done. In the case of heatwaves, that's not very much lower. An issue with heatwaves is on one hand because of global warming and the changing climate, the recent heatwaves is very steep [INAUDIBLE].

You need to remember from almost a decade ago, Netherlands, France, Belgium, they have tens of thousands of people die because of the heat. And most of those people die for very, very avoidable reasons.

So if you're elderly, or have respiratory problems, you have certain legal health condition, very simple things like being in a colder room with your condition or drinking more than you want, that alone can be enough.

Construction workers [INAUDIBLE] sports collapse. All you have to do is to suspend the competition, or to [INAUDIBLE]. So it's very [INAUDIBLE] and consistently take people by surprise. So the purpose of these games will be to support Red Cross, especially as a [INAUDIBLE]. So they can learn what are the simple actions taken to save lives, not only at home but more importantly, the lives of [INAUDIBLE] members of the community.

The chance for the [INAUDIBLE] also is pretty big. But it's a little bit more of a timeline. So it will begin-- we start looking in January. We will need some [INAUDIBLE]. But there are some institutional needs to embed.

Once they exist, it has to go through Red Cross channels, which can be more complicated than going in through school children, where if it is picked, it goes viral quickly. But it's still a very good one. Again, it's one that can lead to saving real lives.

And there plenty of resources within the Red Cross and beyond. Importantly, there is a master's student at Harvard who is doing her entire thesis on this. And we're going to have at least one, maybe two, hack-a-thons dealing with heatwave risk.

The Harvard student, her name is Elle. She's really great fun. And she would be a collaborator. And this will have a lot of chances of growth. If you did see a photo from the Netherlands heatwave, and Red Cross volunteer helping an elderly lady just hydrate, and do that lady did not die, whereas tens of thousands did.

Can you come up with a game that helps people make such simple decisions? And I'm sure there's a way to make it fun. So overview-- one or two questions?

PROFESSOR 1: Any questions on this one? So the target audience on this one's different. It's Red Cross volunteers and staffers. It's probably as part of their training?

PROFESSOR 4: Correct. So the way we envision this-- actually I dind't mention-- the way you envisions this one is to have the game as ready, deployable but on the shelf. And then when there's a forecast of a heatwave likely to happen over the coming six days, then we blast the game to the Red Cross volunteers.

So they become very quickly familiar with the very core aspect of it, of course complemented with others like maybe face to face training, or mainly sending documents to read But this would be potentially very easy to adapt or translate to many languages.

And again, Chicago, Boston-- there's plenty of places even in the US. This is the one that would be easiest to play test locally because we can-- And the profile of a Red Cross volunteer is not necessarily too different from the profile of university students who are engaged in do-good activities.

PROFESSOR 1: OK, on to the next one.

PROFESSOR 4: 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?

PROFESSOR 1: Yes.

PROFESSOR 4: 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 a hurricane, flood, 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. And the funding mechanism exists.

There is another pot of money which is for a normal days. The Red Cross has vehicles. The vehicles needs maintenance. They need to change tires. You need to buy a new computer. You need to pay rent and the electricity bills. You need to train staff.

So on a normal day, you have a budget for either maintenance, or development of new projects, or writing proposals, and so on. And when that pot of money exists, we called it the annual appeal. Every year, we appeal for help. And people or donors, or governments give us some money.

What does not exists is what the drawing of the cartoon depicts, which is when there is a signal from science that a disasters, that something bad is likely to happen soon. We don't have money to fund action before the disaster, after the forecast.

So if you click to see the text, the context is that there that missing money part. We have money for after a disaster, we have money for everyone all 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 scientist 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 above the ground. The boat is unstable.

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 your own means, with your 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 nuanced in how it's implemented. There is a pot of money. It's like a bank account.

You need to have a threshold of disaster risk that needs to be exceeded. So it can not be two drops of rain. It has to be a lot of rain. It can not be some wind. It has to be a hurricane 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 sent to a colleague because it can work for a broad audience digitally.

Ideally we would reach those who can contribute either money or decisions, muscle power. The chances of embrace for this one are not as high as on the previous one. But if it were to happen, it'll have the highest impact. Because right now there's billions of dollars being spent in the two extremes.

And in the small fraction where spent investigating that precious window of opportunity-- when you see that fuse getting close, that time of effort can really have a very, very high impact. There's a link to a journal article that should be very clear for MIT students.

We also have some simpler readings and journal [INAUDIBLE] I have been engaged within and are 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 1: Any questions on this one? So one thing, when we first started designing this class, this is actually the problem that we're most interested in, mainly because the other problems, we just hadn't heard about since. Cholera was a recent proposal that was asked for, and Ebola, of course, very, very recent as well.

So if you really enjoyed some of the challenges from projects 2 and 3, and you really took on the planning aspects, the trade offs aspects of those two games, if you're looking at trying to communicate to another person how these probabilities works, this is probably a really good project you might be interested in.

PROFESSOR 4: And I should say also I'm working with a few MIT teams, including the Humanitarian Response Lab, including the Environmental Engineering. We have two generations of three students plus one professor going 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 been meaning 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 launch it a bit. Good. Then we'll move on.

Number 4, Ebola. And I have to be very candid. I come from climate research, climate and disasters. And as far as we know, Ebola does not have much of a climate signal. But, as I'm sure you know, it's a very importantly thing.

And the idea for bringing this up is that one of my [INAUDIBLE] colleagues, Steven Ryan one day sent a message saying, tonight I'm arriving in Liberia to work for a month with a Red Cross national team that is doing it's best to respond to the Ebola outbreak. And guess what?

What they're doing, as its best, is not enough. Steven is a communications specialist. As you can imagine, I feel phenomenal admiration and respect for his dangerous choice to go to the place where people are in very serious trouble to try to help.

And that made me think, well, maybe we can help. So I sent him an email, and he kindly responded saying, yes, they're keen on the possibility of a game. Bear in mind that because of the cycle of the disease, by December chances are that either it became a complete pandemic, or they [INAUDIBLE] is completely gone.

So we are not going to make a game to be played in the equivalent situation as the situation now. It would be more of a game about an awareness of how it works and how it can be prevent in a hopefully less than complete crisis mode.

But nonetheless, Steven and one of his colleagues were very graceful to offer themselves to be the subject matter experts and to help, should a team choose Ebola-- please no more than one team. There's someone on the other side of Atlantic Ocean that is going to try to engage. In this one, John and I do not have expertise.

I imagine it is possible to find expertise in the Boston area with so many phenomenal hospitals and so on. But it's outside of my control to offer reliable support when it comes to subject matter. I'm sure that there's plenty of documents from the CDC and from health practitioners that can help you design a game.

But whoever chooses this, it'll be heroic. It can be really useful. But you have to be most prepared to work autonomously. Any questions?

PROFESSOR 1: Any? [INAUDIBLE].

PROFESSOR 4: Are you guys there?

PROFESSOR 1: Sorry, I had the microphone muted. No questions on this one.

PROFESSOR 4: So moving on to the last one. If [INAUDIBLE] hasn't joined yet, then I'll do my best to explain.

PROFESSOR 1: Yup, I haven't seen her yet.

PROFESSOR 4: So this is a project that is being led by two of my colleagues, including [INAUDIBLE]. So forgive my ignorance. And it's very similar in its nature to the UNICEF one.

The difference is that the UNICEF project is for small children about a very specific health condition called cholera. Whereas this one is for a partner called Plan International. It's an NGO that works with children. They're very good.

They work a lot on the rights of children. They are about empowerment. And they work intelligently. And the Asian team has reached out to the planning center. And I don't if you can read the words, but in summary we want a game to help children in Asia understand climate change and what can be done to adapt to climate change.

Plan International seeks to partner with the Red Cross [INAUDIBLE] Planning Center to develop a participatory learning game for children in Asia, focus on Southeast Asia. So all the way from [INAUDIBLE] Cambodia, et cetera, that would strengthen their understanding of local climate change impacts, and help them develop a [INAUDIBLE] what they and their community can do to adapt and increase their resilience.

The project will include the [INAUDIBLE] game package, testing, and a training officer [INAUDIBLE]. The current project does not include a digital component because there wasn't enough money. But like the UNICEF one, this is an area that inevitably has to grow.

So if any of you comes up with a prototype that is sufficiently playable to capture something about climate change, there's generally two [INAUDIBLE] ideas that children can benefit from learning. One is that the trends of change are dangerous. [INAUDIBLE] sea level rise, like drying of some sources of drinking water, as well as the changing pattern of extreme events, which can be about rainfall, can be about temperature, can be about the winds and cyclones.

And so children who have not lived long, and therefore don't have much of a memory, are likely to have to confront information about things, extreme events, disasters that they've never experienced, but they have to do something about. So the game is not about one specific threat, but is more about the concept of adaptation to planet change, which of course can be embedded into a specific manifestation of planet change, like sea level rise, or like changing rainfall patterns.

There was a more clearly defined age group for this one, which unfortunately I don't have off the top of my head. But [INAUDIBLE] will be sending the materials to the team. So within 24 hours, I pray that you will have all the ingredients you need.

I know I didn't share too much. But are there any questions about what I could share?

PROFESSOR 1: Any questions about this one? No questions on this one.

PROFESSOR 4: OK. Then move onto the next slide. We have about 50 minutes left [INAUDIBLE]. And based on some questions and comments, I'd like to get a [INAUDIBLE] front room.

You have all choices here. The first one was snap. I need a digital tool to enhance the snap experience of collecting and processing information. Then we have the UNICEF Ghana, Cholera, where we hope we can get two groups because this is a big one. Then we have linking early warning and early action maybe focusing on heatwaves.

Then we have the more sophisticated, conceptually, [INAUDIBLE] forecast-based financing, funding mechanisms for disaster preparedness before the disaster, after the forecast. And then we have Ebola, where there's not much I can offer other than if you make a game, we can try to hook you up with people.

And if you come up with a good game, it can be really useful. And the final one is adaptation to climate change to be played by children in Southeast Asia so that they understand climate change.

Here's what I propose. We're going to give you guys 30 seconds. Each one of you choose one or two secretly based on what [INAUDIBLE] which is completely incomplete information. But that's the way it is.

Given what you've heard, choose one or two of those in the come 10, 15 seconds. I'll give you that time. Thanks for your patience.

PROFESSOR 1: Not a problem.

PROFESSOR 4: And so what we're going to do now is-- you're all sitting I imagine. Actually Rick, can you show the room?

PROFESSOR 1: Let me go back to the Skype and turn on our video.

PROFESSOR 4: So what I want to do is [INAUDIBLE], and if that number of your chosen one, I want you to do two things. One is to stand up, the other to shout snap. But I cannot see everyone. I cannot hear everyone. But it will give me a flavor of proportion.

So item 0, if you're ready to [INAUDIBLE] stand up, [INAUDIBLE].

AUDIENCE: Snap.

PROFESSOR 4: All right, so we've got maybe one in four [INAUDIBLE]. Excellent. You may sit down. Number 1, if it's of your liking, do it?

AUDIENCE: Snap.

PROFESSOR 4: All right. Good. This one, [INAUDIBLE] all of you guys on a group because I don't see enough for two groups. [INAUDIBLE].

Then next one now, for two. If you're going to do, do it.

AUDIENCE: Snap.

PROFESSOR 4: All right. This one seems popular. Number 3, go.

AUDIENCE: Snap.

PROFESSOR 4: Thank you. Number 4, show it.

PROFESSOR 1: 4 was the funding one?

PROFESSOR 4: Yes.

AUDIENCE: Three was the funding one.

[INTERPOSING VOICES]

PROFESSOR 1: Yup, you're right. I'm wrong. Yeah, we're counting from 0. 4 is Ebola. So nobody stood up for this one.

PROFESSOR 4: OK. And if [INAUDIBLE] do the last one, number 5. Go for it.

AUDIENCE: Snap.

PROFESSOR 4: OK, so we're focused then. I don't know, Rick and team, what you had in mind for this time. But given that we went relatively fast, what we could do is you could point to different places of the room and talk [INAUDIBLE] 0 middle, left is 1, and so on.

And invite people to just answer with your feet. Which is the location they most want to go to? So we get a sense of how many people want to engage in which game.

PROFESSOR 1: OK. So we've got it on the board. Cholera here, Ebola here, early warning here. These are actually behind you, so I'm going to have to rotate the computer. Snap over there, adaptation here, and disaster prep funding, the forecast-based funding over here.

PROFESSOR 3: Let's draw out the numbers as well.

PROFESSOR 1: Oh yeah, I'll put the numbers up.

PROFESSOR 3: So snap was 0, cholera was 1, early warning was 2, funding was 3, Ebola was 4, and adaptation to climate change, 5.

PROFESSOR 4: So answer with your feet. You can not stay sitting for [INAUDIBLE]. And now Rick and team, I'm going to invite you, because you know best what is required for each group, be it finance grouping, in terms of quantity of people, in terms of profile [INAUDIBLE], there won't be code geeks in one, and then narrative geeks on the other.

If you understand this, at least what happens now is in now way definitive. But it's to get a sense [INAUDIBLE].

PROFESSOR 1: Yeah. So actually this leads really well into what we're about to do. We're going to do some brainstorming on these topics. So we're going to first have each of the groups just do a little bit of a quick brainstorming about the topic that they're standing with right now.

And then midway through, we're going to invite you to go over to a new group to talk about a different project if you're interested in talking about that other project. On Monday, we're going to actually form the team and make sure all the teams meet our requirements.

But it's basically seven to eight people per team. We're hoping for eight people per team, hopefully not more than that. But we'll figure that out as we go. And over the weekend, we'll be using the mailing list to talk about the projects.

So I'm actually going to let-- we're going to start off with this brainstorming. We're going to take a break, we're going to do some more brainstorming. And then I will more clearly outline how the mechanism is going to work between now and Monday.

PROFESSOR 4: Do you need me to stay online.

PROFESSOR 1: No. What we would like is-- are you going to be on email between now and Monday?

PROFESSOR 4: Yes, but only with very limited ability to read and respond. So make sure to make the subject line very clear and the questions as snappy and answerable as possible.

PROFESSOR 1: And you don't mind if give all the teams your email address?

PROFESSOR 4: No mind-- but teams, please, please, please, I beg you, consolidate your questions. Be very efficient with your writing. Because if I get too many emails or too wordy, excessive verbosity, I will not be able to get it.

PROFESSOR 1: So I'll figure out a mechanism--

PROFESSOR 4: [INAUDIBLE] fine, a channel within each group to communicate and consolidate.

PROFESSOR 1: So I'll figure out a mechanism to make sure you're not overloaded with email, and to make sure everyone gets the benefits of those emails to you.

PROFESSOR 4: Good. And I suggest that you always copy [INAUDIBLE]. All right, so good luck to you all. Thanks again for your time and inspiration. And I wish you good luck [INAUDIBLE].

PROFESSOR 1: OK. Thank you Pablo. OK so you're in your groups. I have paper for people who are not on chalkboards. Do we have nobody for Ebola?

PROFESSOR 3: No one.

PROFESSOR 1: Then let's give snap the Ebola-- actually you're pretty big. Let's not. These two groups are pretty big. Let's give them space to spread out.

So what we're going to do is just a really quick brainstorm. Five minutes-- just choose one person to be a secretary. Have them come up. You've heard a little bit about the topics. You haven't done any of the reading yet.

We're going to have all that reading available for you on Stellar right now for you to read over the weekend. It's a lot of it. We don't expect you to read all of it. But we do expect you to look at it.

Based on what you understand, what kind of mechanics could come out of these kind of topics? Just based on the word cholera, based on the word early warning, early action, what kind of game mechanics pop out of that? And just through them on the board.

So disaster prep-- let me hand these off to those two.

PROFESSOR 3: To disaster prep, or to more than one group?

PROFESSOR 1: One to one, and one to the other.

PROFESSOR 3: We had a question like that, by the way. Rick, we have questions in the back.

PROFESSOR 1: Yeah, one second. What's the question? From who?

PROFESSOR 3: Let's stick it up on the wall?

PROFESSOR 1: What's up?

PROFESSOR 3: You guys probably need the stand.

STUDENT 13: What game engines would-- is it the same as other previous ones?

PROFESSOR 1: Same as previous ones. We'll talk about the constraints on Monday. Don't worry about the constraints right now. Right now just focus on game mechanics.

STUDENT 13: [INAUDIBLE] mobile [INAUDIBLE].

PROFESSOR 1: Yeah, so keep it blue sky. You can be mobile. You can be on tablets, you could be a computer. It could be single player, it could be multiplayer. Just don't do multiplayer networking. That's it.

STUDENT 13: Our game has--

PROFESSOR 1: What's that? Our game's definition is [INAUDIBLE].

PROFESSOR 1: Then what are the ways you're going to get around that like we talked about?

STUDENT 13: Without doing multiplayer?

PROFESSOR 1: Without doing multiple devices connecting to a single server. There's other ways. Don't even think about it for this brainstorming. Just don't worry about it for now. Here we go. Pass these out. All right, so five minutes, go.

[INTERPOSING VOICES]

 

PROFESSOR 1: This is in case my wife sends pictures. So I have another group that we work with is doing an EdX course.

[INTERPOSING VOICES]

 

PROFESSOR 1: We've done about 15 minutes of really quick and dirty brainstorming. Somebody from your group shout out one or two really, really interesting idea that you're really excited about. Just one person, one group, interesting ideas, this group go.

STUDENT 14: Spatial placement of wells affecting where cholera spreads.

PROFESSOR 1: So spatial placement of wells affecting where cholera spreads?

STUDENT 14: Yeah.

PROFESSOR 1: OK. So a spatial puzzle kind of game.

STUDENT 14: Exactly.

PROFESSOR 1: One more idea?

STUDENT 15: Animal crossing with cholera and puzzles.

PROFESSOR 1: Yes, animal crossing. I'd think about the scope on that one.

STUDENT 16: Playing as a heatwave.

PROFESSOR 1: Playing as the heatwave, you are the heatwave, cool. One other idea?

STUDENT 17: Playing as a Red Cross volunteer, managing resources.

PROFESSOR 1: OK, not as cool. Heatwave [INAUDIBLE] volunteer. Over here.

STUDENT 18: You're on a tiny island and you live on the island and you do stuff on the island. But your island is shrinking. So you have to collect resources on your island to move to the bigger island.

The bigger island is shrinking too because the water keeps going up. So you hop, and hop, and hop, and you arrive at the mainland. Yay, everyone's saved! Except the mainland is a giant island too. Whaa, whaa, whaa.

PROFESSOR 1: Whaa, whaa, climate change. Cool. Thank you. Another idea, or is that the big one?

STUDENT 19: The decision between chopping forests and to build more buildings for faster development, or to keep the forest air help make climate change less severe.

PROFESSOR 1: Cool. So one's kind of, you don't have much action. The world is going around you. This one is kind of, you have action. The decisions you make are going to affect things. Cool.

This group here? This was snap right, this group? One or two ideas?

STUDENT 20: Well, so I was thinking about not just choosing words, but given a scenario, making a particular decision can vary in two decisions other people made given that exact same set of [INAUDIBLE].

PROFESSOR 1: OK, so really thinking about how you're going to make this simple decision, or this simple interaction that the game has, make it a little bit more complex and really kind of bring the decision making out in the forefront-- is that kind of what it sounds like? Right? Yeah, what's up?

STUDENT 21: The was I understood the game, or the description for snap is that it's more of a data collection method, like collecting what people--

PROFESSOR 1: That's at least the purpose they want, is they want that data. Well they want to collect that data. But they also want to reflect that data back. So it's a little bit of a visualization. It's actually a of a visualization, as much as it is collection. Are those the only groups, or the only concepts?

Oh yeah, disaster preparedness. Everybody's disappeared. Anybody from that group want to run over to the sheet and say an idea or two? Or you just kind of--

STUDENT 22: I think we just got stuck on the brainstorming because the program is not as easy.

PROFESSOR 1: So it's hard. It's going to be a hard one.

STUDENT 23: One idea we came up with was building an infrastructure and you would decide whether to keep expanding or to reinforce the structure. And that way, you would oh, are you preparing for before the disaster or after the disaster. Did you have something to add?

STUDENT 24: I was just going to say we felt like we needed to do more reading to understand exactly what [INAUDIBLE].

PROFESSOR 1: But something about there is something that can be built to spend that money on. So it's not just about collecting the money, it's that money's going to go somewhere. Which I remember him saying at least-- I don't know if it was a meeting with me, or if it was one of the first times he came to class to talk. But I remember that came up.

Take a quick couple minutes, one person from each group make a copy of all the ideas you have on the board somehow, like a photograph, or-- actually just take a photograph of it, and then come back to your seats. We've got two more slides, then we're going to release you.

[INTERPOSING VOICES]

 

PROFESSOR 1: So after you've taken your captures, sit down. What next? I'm going to stand in front because I can't see what my slides say. So today we brainstormed in groups on these topics.

Between now and Monday, what we'd like you to do is use the mailing list, the videogames@mit.edu at mailing list to form teams. In class on Monday, we will actually also set aside time in the beginning of class to make sure that all these teams get formed. And we're going to do some more brainstorming and some more pitching on Monday.

And I'll go into more detail about the requirements for the project 4. But make sure you read the project 4 assignment. That's basically all I'm going to be doing is just saying out loud what it says in there.

So before next class, do these things. Read the material in Stellar. All the topics have some material in Stellar. The Ebola topic did not, the snap topic did not, but cholera has the tool kit that he'd that he mentioned up there.

Early warning, early action has a like a task force guideline, like a idea of world disasters from 2009, I think. And then another journal article. Disaster prep funding has that forecast-based funding journal article attached to it.

Adaptation for climate change, we don't have materials yet for that. But that should be coming in today. And that'll be put up into Stellar. That's all of that, right? So when you're in your groups, think about these questions. And think about these questions until Monday.

Did you actually have eight people interested in your topic when you were in your group together, like think back about the brainstorming. Did you see seven other individuals interested in the topic? If you did, you can probably make a game based on that topic.

If you didn't, it's going to be difficult to find people for your team. So really use the mailing list and try to figure out ways to use the mailing to try to attract people to your topic. If there's something about like the game design that you came up, a personal reason why you'd like to see this game get made, throw it to the mailing list.

If you really don't care about the topic so much or any of these topics, but you really want to do programming, you really want to do art, you really want to do code, whatever you want to do, if that's the thing that you're most interested in, that game engine you want to use, throw an email to the class to say, hey, use me. Here's what I'm interested in doing. Put me on your team, basically.

If you're more interested in the mechanic design over the topic, that's also OK. So you might not be interested in the topic, but you're interested in some of these mechanics that we've been talking about in class, or some of the mechanics that you heard mentioned in the group brainstorms, so mention that in mailing list.

Again, team information will be finalized on Monday. And if you are undecided, I'm just going to stick you in a team. That's the worst thing that could happen.

Because if I just put you in a team, I'm not thinking about who you're going to work best with. I'm not thinking about what game engine you're working on. I'm not thinking about is whether or not you're interested in the topic or not.

I'm just grabbing you, and sticking you on a team. So do all the work for me, so I don't have to do that. And if you do just want me to do that, that's OK. I like rolling dice. Do we have any questions about this, any concerns about this? Yes.

STUDENT 25: Are you targeting five teams?

PROFESSOR 1: No, I'm targeting teams of eight. So that's five teams, but it could be four teams if we need more people on the teams. I would recommend 10 being your biggest cap. In the past, we have seen 10 person teams work-ish.

They failed everywhere you think they failed, communication largely, scheduling largely. The one thing they didn't have that I think you're more prepared to do, if you were in a big team like that, is that they didn't understand how to break out the strike groups, into strike teams, how to separate tasks and form into smaller groups.

I've actually seen you all do this on these previous two projects. So if you do find yourself in a large team, think about how you're going to break the work up into the small tasks, into these bigger, modular kind of things. Especially think about why you're in this class.

What did you expect to get out of this class? What do you expect to get out of this final project? If you wanted to do some really big tech thing, there are some ideas out here that require some heavy tech lifting. If you're in designer, there's some really, really challenging design issues, especially with that forecast-based funding.

I'm really leaving that up to you. But I'm going to make sure that all the teams have eight people. Any other questions?

PROFESSOR 3: Just one statement [INAUDIBLE]. Especially with the snap team, I do realize that as presented to you today, it really does seem like a networking game. That really does seem like a game that will involve a lot of networking. And of course, we've spent the entire semester so far telling you, oh good lord, don't do that.

So it could be a huge tech challenge, or it could be a huge design challenge. The huge design challenge is how do you accomplish everything that we think we need networking to accomplish without networking. Or it could be a tech challenge that's, screw it, we're going to do networking.

Then it becomes what's the least brittle way to accomplish that. The problem with networking and that particular game is that to require networking means that you need to play this game in a room with networking. Which means if you take it to a room without Wi-Fi, for instance, that means it's got to be something that's going to work over a phone system, or it's going to require short messages, or something ridiculous.

And if you don't have networking, it's going to be like, what are you going to be doing. Are you going to point a camera in a room and do image capture, or something? It's like some crazy things-- are you going to do manual data entry? That's actually a possibility.

Anything that you can come up with that makes that game that we played in class slightly easier might be beneficial for Pablo. And he's guaranteed that he will use it as soon as you provide it. So that's an incentive right there.

But it is possibly, despite how simple that game is, possibly one of the toughest design challenges that I can see on the board today.

PROFESSOR 1: Up until now, we've been really strict in allowing you to use specific tools, use specific methods. We're going to start easing up. But if you break any of the rules, you need to tell us why. That's all we ask.

If you are going to use multiplayer, tell us why. If you're not going to use one of these game engines that we've been practicing on for this semester, really, you really need to convince us. So use the office hours like [? Sarah ?] suggested. Use the mailing list.

Talk to us during class. I've already had quite a few students talk to me individually, and talk to them individually about these kinds of thing. The rules are there to be broken. But don't break all of them at once. Break one.

PROFESSOR 3: If you're going to get rid of like the task list or something like that, what are you replacing it with? Tell us if you're going to be not doing daily scrums because it doesn't work for your team. What are you replacing that communication strategy with?

Because it's clearly there for a particular reason. Hopefully you've seen the reason, even if you haven't necessarily managed to make it work on a previous team. So what are you going to do in its place? Sarah, did you want to--

PROFESSOR 2: I think you guys covered it all. About all I can do is restate the [INAUDIBLE] about breaking rules. And it's break rules with care. We didn't give them to you just to be arbitrary. We gave them to you in our experience of watching a lot of students make a lot of games, and make a lot of mistakes.

These are the big pits that people dig themselves in and then climb down and wonder what the heck they're doing in. So if you're going to break a rule, have a plan for it . Come and talk to us about whether or not you think your plan will work. We are here to try and support, and give you advice, and help out.

PROFESSOR 3: I think it's fair to say that we've seen every single rule that we provided actually successfully broken in every single year. Not all the time--

PROFESSOR 1: Except for that bad year.

PROFESSOR 3: The what?

PROFESSOR 1: Except for that bad year.

PROFESSOR 3: Except for that one bad year where every project was crap.

PROFESSOR 2: Don't be that year.

PROFESSOR 1: No, you're not that year.

PROFESSOR 2: You're not that year.

PROFESSOR 1: And Paulina was in the class last year. So if you're looking for student level, what was it like during this project, talk to Paulina. She can help you out. She can give you some tips. And talk to each other. That's why we do all these presentations. Yes.

STUDENT 26: What level of polishedness [INAUDIBLE]?

PROFESSOR 1: We're going to talk about that through for the rest of the semester. What does polish mean? Polished, to our eyes-- I'll talk about this on Monday. But basically what we're asking for is the games you've made these past two projects, that's about the scope you should have think for project 4.

So if you thinking about that kind of scope, but then you have four times the time, what are you applying that time towards? Polish and making sure the user experience is easy to use-- it doesn't crash, it doesn't break. A player can start playing and figure out through the systems of the game how it works, what the keys are.

You've got good credit screens. We're not necessarily asking for an art, sound, or music polish. We're not asking for indie level art. We're asking for just a level below that. A unified level of polish-- so everything in the game has the same amount of time, care, effort being put into it.

PROFESSOR 3: It doesn't feel uneven and bumpy. It doesn't feel like, here's this awesome soundtrack with this really, really terrible art. Or here's this really bleepy, 8-bit thing with gorgeous, hand-painted scenery. That's not cohesive. We want everything to look like it's on an even level of quality.

PROFESSOR 1: This might be a preview for future lectures, but play Ponycorns. Look up the term Ponycorn. It's a game made by a five-year-old and her father. That is actually a high level of polish that I've seen happen in this class. If it happens with your project, it would be really great. Yes, Sissy's Magical Ponycorn Adventure.

PROFESSOR 2: The key thing to note here is that all the assets were created by the five year old. And I believe the story was also written by the five year old.

PROFESSOR 1: And the sounds.

PROFESSOR 2: And the sounds were done by her. And her father just did all the coding and put it all together.

PROFESSOR 1: What's that?

STUDENT 27: $3,199 in donations to date.

PROFESSOR 2: If you can draw as well as a five year old, you can make good assets for you game.

PROFESSOR 1: So we've got nine minutes left for the rest of class. Capture all the ideas that you wrote down and mail them to videogames@mit.edu. So whoever took a capture of each of these things, just turn it into a text file, and mail it. Yeah?

STUDENT 28: Somebody created a Google spreadsheet. Can we all just put our pictures in there?

PROFESSOR 1: That's fine.

STUDENT 28: So we don't get million emails.

PROFESSOR 1: Absolutely.

PROFESSOR 3: Also there are a couple of students who aren't in class today. So they may need some-- you might need to sort of explain to them what happened today and bring them up to speed, especially if you are like dormmates, or hallmates or something like that. Please help them along and help them get ready so that by Monday-- get the conversation going on online so that they can at least have a clue of which team to join on Monday.

PROFESSOR 1: The rest of the time is yours.