Session 26: Final Presentation Rehearsal

• 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: So we want to maximize time today, both to make sure that we're doing-- all of the presentations get good feedback, but also so you have time afterwards to make some changes. So, if you haven't signed in yet, come on down sign up while I talk. Just get that out of the way really quick. Schedule for today is, we're going to probably be done with rehearsals by 2:30.

After 2:30 we are going to have Luke from OpenCourseWare interviewing teams and producers from teams about the class. So, we're thinking about how many minutes per team?

LUKE: Not too long. 10 to 15, casual chat.

PROFESSOR 1: Yep, casual chat is optional, but I would appreciate it if at least people who did production and Scrum Master roles would talk to him. But it could be the entire team talking with him, and maybe one or two people dominating the conversation. That's OK. The goal for this is for people who are looking at the OpenCourseWare site, particularly teachers who might want to use these materials in their classes, to find out from the student perspective what students got out of the class. Because it's kind of like student evaluations. We're going to be out of the room for that period of time. So that means after 2:30 we're out of the room, Luke's doing interviews, and your teams are doing whatever teamwork you need to do to get ready for the demonstrations and presentations on Wednesday.

PROFESSOR 2: Whatever you say to the camera, we will not even get a chance to see it before we give you grades. So you can whale on if you'd like.

PROFESSOR 1: Please do. Or at least, please be honest-- let's try for that.

I should also note, student evaluations are available online. Please fill those out. We're going to-- actually it's a great period of time from 3:00 to 4:00 in class today to just open up your browser and fill out your student evaluation, right here and now so that you get that out of the way. And again, that feedback's going to be really helpful for us. It's going to change how we teach the course in the next year. We change it every year based on feedback we get from students. So topics you thought you wanted to hear more about, topics you thought we covered too much, whatever feedback you have for us, do let us know.

Last announcement we have a guest here, [? Leigh, ?] from Odyssey magazine.

GUEST SPEAKER: It's a kid's science magazine for kids aged 9 to 14. And we're doing an issue devoted to gaming. And [INAUDIBLE] graciously allowed me to come and observe you guys as you rehearse your presentations. And I'm going to be taking some pictures, and I may ask some questions. I have some photo releases I'm going to need you to sign if I use your photos. So I'll pass those around. The good news is, if you don't want me to use a photo of you, don't sign it. Because I can't use your picture without it. So that's just an easy way to handle that. So, I'm just going to pass a pile of these around. And if you're willing to let me use your photograph, fill one out. Thank you.

PROFESSOR 1: OK. All right, so for our order of presentations just for today, not necessarily for Wednesday-- we'll figure out the actual order by the end the class today. We're going to start with Heat Wave, then Hello Waves, then SNAP!, then saving Gora Gora, then Cholera Control.

What we're asking you to do is come up, plug-in the computer that's going to be used to demonstrate your game and make sure your game works on the projector. The display resolution the native display resolution is 1280 by 1024. If you're doing a 4 3, or 1280 by 768 if you're doing widescreen. It shouldn't make a huge difference for your slides, but it might be a problem for your game. So, make sure you're coming up, doing a quick two- or three-minute check to make sure the game works. Afterwards, plug-in your slide presentation, and we'll just go step by step.

One thing I'd like to know from each team is how many speakers do you think you're going to have-- how many main speakers you have in your presentations. So, starting with Heat Wave, how many speakers do you have? One. Hello Waves? Two. SNAP!?

AUDIENCE: Two.

PROFESSOR 1: Saving Gora Gora?

AUDIENCE: Five.

PROFESSOR 1: Five. And Cholera Control?

AUDIENCE: One for now, maybe two. Not sure.

PROFESSOR 1: So, for Heat Waves, Hello Waves, SNAP! And Cholera Control-- actually for all of you, whoever is doing the most speaking, strap this little thing on. For everybody else, when you speak, make sure you are standing on the normal spot in front of this, so that the microphone can capture you. If you have-- for volume control, it is over here. Hopefully you've used this before. It's set at about midway. Take a note of all the different settings you are using when you're plugging in your stuff to the projector, so we can make things go fast on Wednesday. Any questions? All right take four more minutes in your teams to get yourself ready, and Heat Wave, please come up at 1:15 to plug-in your game.

AUDIENCE: [INAUDIBLE]

PROFESSOR 1: No, so time yourself with the clock. Take a note of your own time. We're not enforcing time limit right now. We're concentrating on content.

GUEST SPEAKER: Well, hello, my name is Mary [? from Providence ?] and today I'm representing team Heat Wave. We made a game about heat waves, not surprisingly. And these are the people on our team. I'll talk a little bit more about that in a minute. So, first of all, our game was about heat waves, and the main goal our game was to educate Red Cross workers about what to do when a heat wave was upcoming or was currently in progress. How do you prepare for it, and also what do you do to deal with it. And while we focused on these goals, our design goals were more specifically usability, play--

AUDIENCE: [INAUDIBLE]

GUEST SPEAKER: OK. How did I get that far without someone pointing that out to me?

AUDIENCE: [INAUDIBLE]

GUEST SPEAKER: OK, we're going to start over if that's OK. Do you mind? I really didn't get that far in, so that's OK. Heat waves-- oh, but now I can't see the slides. OK. Heat Waves, this is our team. Heat Waves is a game to talk and explain to Red Cross workers what to do in order to both prepare for heat waves, and also what to do once you're in a heat wave. And that was the purpose of our game. And while we had those goals for our game educationally, our goals overall for the design process were playability, usability, and education. Usability was first, because if the game isn't usable, no one's going to use it. Same with playability, if you can't play through the game, then it's kind of useless. And finally, our main goal was education, because we really wanted this game to serve a purpose, which was to educate people.

For our design process, we did the same process that most of the people in this class did. We started off with brainstorming. Then we went into team formation, responsibilities breakdown, and then just constantly updating, using Trello and different Scrum features. I'm going to talk about all of these in a little bit more depth.

So first of all, brainstorming, we started off right on the get-go, drawing on the board. What do we want this game to look like? What are going to be the main parts of it? And we actually settled on a somewhat complicated design, with the main screen a dialogue system, and then kind of an options menu.

And once we had this, we actually formed our team. This is our team minus-- I don't think Joe's in this picture because he was sick that day. And one thing you notice is we had a team of nine people. So it was a lot of people doing a lot of stuff. So we had to really deal with that. And one way we dealt with that was using Scrum. We had a lot of emails. But the way we managed that is, we learned from previous times that if you have one giant email thread it gets overwhelming, you don't see everything. So we separated it, had a couple different email threads based on different topics and subgroups.

And then also we updated our Trello. One thing we realized really quickly is that Trello is not so good for listing every single Scrum. So you kind of have to have a to-do, a done, and a working on right now, just for future reference. And that's kind of how we organized ourselves later on. And then just because it's Scrum, it's an iterative process, which is the picture.

Next, we had a lot of group meetings. And something we spent not as much time in class because we spent a lot of time outside of class. We had a bunch of meetings where we had snacks, and we would all just sit around for like three, four hours, and work. And those were really productive times for us, because it was a time where everyone who was there was really dedicated to fixing bug after bug, issue after issue, getting things done. And they were really what made our game come together as much as it did.

So, focus test, we ran four focus tests. And each of our focus tests had a different theme. So once we had our team together and we were building the game, there were different things working at different times. So for the first focus test, we had a low-fidelity prototype that with digital, and it was a Python game. And we've tested concept-- I'll talk a little bit more about that in a second. The second one we tested our initial unity game, and we looked for over-arching issues. The third test, we worked on visuals, just how can we emotionally resonate with our audience. And the fourth test was game balancing, because at the end of the day, once you have everything together, it's really easy to ignore if the game is balanced or not.

So the first test we ran was a concept of general mechanics. So as I said earlier, our general focus was education. It was our big goal, and we wanted to make sure the type of game we were building could really convey information and teach the audience about something. So if any of you played our Python test game, you would remember that you basically had a bunch of people you could choose to talk to. And if you talked to them, you could offer them water, tell them to go inside. And they'd either listen to you or ignore you. And you just went that way in loops until either everyone fainted or everyone went inside.

And what we learned from that was, first of all, it worked. People were noticing, OK, I'm going to focus on the drunk guy, I'm going to focus on the older person, try to get them water first. Because they faint more quickly. And the other thing we noticed right away is something we did try to try to make this game more lively, is we had fun dialogue. So for example, the first quote up there was like a more factual, drinking water even when you're not too thirsty is important in this type of heat. That's a very true fact about heat waves. You're just supposed to drink more water than you need to. And then the second one is just more fun trying to make it more lively, hide your wife, hide your [? kill, ?] it's heat wave. So that's something we experimented with early-on, having fun or dialogue to kind of increase the excitingness of the game.

So, the second focus task we really were looking for overarching issues, and it was our first unity-based game, so we are working with issues with our dialogue system, issues with how is the playability. Does this concept of interacting and thinking about education still work in this unity-based game, where it's less of like a, oh, there's just these old person or young person, which one do I choose? Instead now you have these figures. And we tested this out a little bit. We found the educational aspect was still coming through, but we had a lot of playability and usability issues. So, we needed to majorly revamp that.

So then we got our focus test three, where we focused on the visuals. So once we went through play test two, we realized, OK, we can fix a lot of this usability stuff. And now we want to see, can we make this game emotionally resonate with the players. And make it feel like less of just kind of like, I'm sitting there looking at this red screen and it's like, argh. So we had this, and what we were looking to talk to people about was the different characters, were they still prioritizing in this scene. And it turns out they weren't, because those labels didn't move with the people. And even if the labels had moved, people said the labels were too small to read, they were confusing-- really should just get rid of them, and instead either add little icons or caricatures of different types of people in order to choose who to help. So those were the kinds of questions we asked. And we actually showed them a sample artwork of a redone homeless person drawing. And people said that, that was a lot more informative and that way we didn't have to have like little text that no one could read. So focus test 3 was really about the visuals, and we really re-did a lot of our visuals based on that. Sorry, this mouse is a little non-responsive.

Finally, focus test four-- I think you all probably had one of these-- was just game balancing. The end condition of our game is basically when people faint, how many people have fainted. And if a certain number of people have fainted, then we stop the game. And the problems with that was that it was, at first, there was too many people, and everybody was dying right away. And then we instead of ramped up the number of people, and then there was an issue where, you were fine, you were fine, you were fine, and then suddenly everyone died on the fourth day. Because there were suddenly 100 people, and you could not help them all. So focus test four really focused on that, and trying to balance the game out.

Along the way, we made some bad choices. Every team does. And the main ones we made was, we decided to depend on external code. And while we thought it would allow us to make a more complicated game, we didn't really foresee how much we would have to adjust ourselves around the external code. It's a two-way street. And so it kind of impeded our progress sometimes. It added a lot more complexity, things that we weren't expecting. And then the other thing we made a mistake on, which I'd like to emphasize, is we focused on education, which was a great thing to do, but we forgot to focus on fun. And one thing we did to compensate for it, as I mentioned, is add that dialogue, that banter, that makes something that's kind of dull a little more interesting. But even so, I think one thing that if we went back and we did things differently, we'd focus on fun as a number-one priority, along with playability, usability, and education. So ours became a pretty standard learning game, as we talked about them.

Good choices, we had a lot of group meetings with snacks, great idea. Turns out people come if you have snacks. Just if you were wondering. And then we prioritize. So everybody prioritized. But one thing we had to deal with, because we had such a large team, was not everyone was available at the same time. So it was really prioritizing not only based on what needed to be done but even if something kind of had already been assigned who can actually work on this right now and get it done, and like when are they going to get it done. So we really worked with that and kept iterating and figuring out, based on what needed to get done right now, who was going to do it.

So the game itself is composed of really three screens but a couple of them have sub-components. So, the Start screen with an instruction screen; the main game, which has the daytime screen and a newspaper scene in it, which is like the end of each day you see that; and then the end screen, just you can take a look at all of these. So originally, this was our start screen. Main feedback with that was, it was not pretty, and it was not informative. So when we redid it, we added an instruction screen, which is actually still having a little bit of bugs with the readability. But what we did was we added a way for players who didn't play the game before to find out what they actually needed to do. And then the actual game, the original, we had-- I showed you on our focus test two and then our focus test three with the people moving, but the labels not moving. We really iterated the main game to make that as usable as possible.

And our final result-- well this is actually in progress. So one thing we updated in progress that I almost forgot to mention, was that we saw in focus test two and focus test three that visuals really important. And one thing we weren't displaying at all that was very educationally important, that Pablo actually mentioned, was that as people are about to faint, they usually get sick. If you see somebody who's about to faint, they'll like start sweating, and turn red, and all this stuff. And in our game, they just kind of keeled over and died. So, we needed a way to implement that. But we couldn't necessarily like draw a million different character art. So, we decided on the simple solution was just to add a little-- that little circle, like the thing above their heads, you can all see it with the exclamation point. And that was something we did in progress.

And finally we integrated that with the new character art, and this is the final game-- I don't know what those squares are, they're not in our game. But you can see the people are a lot more descriptive. I think that's pretty obviously that's an old person, they have a walker. And we had to rely on these caricatures of people, which really worked out in terms of like getting visual feedback when we talked to people. They were much more responsive to this than like labels or even like little symbols. They really liked the art.

And finally-- not finally, but the other part of our main game was the newspaper scene. And initially we just had a lot of information displayed, and no one actually read it, because they didn't think they could do anything about it. And they also just didn't like looking at it. It was confusing. So we re-did that, and so made it a little more visually appealing. And something we did that I didn't mention on the previous side about the main scene, is that we actually added more longer-term options. So this was more relevant as you were playing. Because if it was cooler on a day, you could start installing umbrellas. And then you would actually be like, OK, well, it's actually 115 today, so I'm not going to install any umbrellas, I'm just going to try to give people water.

And then finally-- so originally at the end of our game, as you can see, there was no end scene. And that's kind of important. So, people really wanted feedback as to-- they didn't just want the game to restart, they wanted to know how they did. Even if it's educational, part of that fun that was something we obviously didn't focus on, was just knowing, oh, I actually did pretty well. This many people-- like I lasted this many days, or this many people like went inside because of me. And that's because we weren't focusing on fun, we didn't even think about the importance of an end screen. Right? So, when we re-did it, we added this end screen, and it tells you how long you survived. So, two hours, five days, you can get a sense of how long can I keep it up and make sure everybody was working out well. So that's our whole game.

And looking back at this whole process, something we've discussed as a team that we would do differently, is passion. So one thing about heat waves we all thought initially, oh, it's such cool topic, heat waves, it gets hot. And then we read about it, and it was actually a surprisingly simple phenomenon. It gets hot, people drink water, go inside, and that's about it. There's not really a lot of complexity to the issue. And so a lot of us lost our passion very early on. And I think if we were going to do this again, we'd somehow incorporate something in addition to the heat waves that would make us more passionate about the game.

The other thing we'd do differently is accountability. Just making sure that-- with such a large team you have to really keep track of everyone doing everything. We really focused on prioritizing who was like actually had time to give and making sure they got tasked on-- which worked out really well. But at the same time, there were people who sometimes were kind of lost and didn't know where the game was going. Because we weren't always on the same page with such a large team, nine people's a lot. But it still worked out really well. And I'd say that given everything, we did pretty well with it.

And if we were going to do more features, something we talked about was more long-term options, people like those. They made it more fun, because you had more of an optimization problem if you had more long-term choices. Those were kind of hard to think of, because in heat waves there aren't that many. Like you can install an AC unit, and then maybe a water fountain. But we were thinking maybe we can make this a bigger scope game, add multiple environments so you have more long-term options. And really build up the complexity over time, so this game can be more realistic of a community as a whole instead of a single environment. And that's really what we wanted to do. Thank you so much. Are there any questions?

[APPLAUSE]

PROFESSOR 1: Oh, so comments about presentation. Anybody up there? Yes, so can you load up your game make sure your game works? Can somebody come down here from the team and do that? And you can answer questions while we-- so feedback from us then about the presentation. The main question I had-- like you covered a whole bunch of stuff, which is really good-- the things we're asking for, what went right, what went wrong, you did in a different format, but you got to it, and that was fine, that was good. The one thing I would have loved more information on, if you can fit it, is the external code issue. Specifically, what was the external code, why was it in there, what did you think it was going to help you with? And then what did end up like-- just a couple lines of those details about

GUEST SPEAKER: More specific.

PROFESSOR 1: More specific.

GUEST SPEAKER: Yes, definitely. [INAUDIBLE]

PROFESSOR 1: And really what is it giving you that basic unity wasn't giving you.

GUEST SPEAKER: OK, absolutely. [INAUDIBLE]

PROFESSOR 2: Let's see, I like the structure, as [? Rick ?] said, you got to everything. But actually the way how you structured it also works really well for all the points that you intended to hit. If we are following this particular order of presentation--

PROFESSOR 1: We're not necessarily, we're going to figure out what the order is after we do the all.

PROFESSOR 2: Whoever goes first will probably need to explain who Pablo is to the audience.

GUEST SPEAKER: Oh, sorry--

PROFESSOR 2: No, no, no, it's not something that you would necessarily have expected. But whoever goes first on Wednesday, if you talk about any of the clients, you have to assume that your audience doesn't know who the clients are. And different teams had different clients that they were talking to, too. So do just explain [INAUDIBLE]

PROFESSOR 1: We'll introduce-- basically we're making games about the topic, but your specific topic--

GUEST SPEAKER: If I have to mention Pablo, I should say who it is, or I shouldn't mention him directly.

PROFESSOR 1: Yes.

PROFESSOR 2: Yes, or just give his name and who he is, that will do wonders. Something for anybody who's using Google Presentations, Google Slides or whatever that thing is called, I think the Ask button brings up your notes. So if you have notes-- I wasn't sure if you were relying on--

GUEST SPEAKER: No, I just wanted to be able to see the slides. That's why [INAUDIBLE]

PROFESSOR 2: You also get a little preview slide. So if you hit the Ask button, you bring that up. Also it automatically brings up the, "Google Drive is using full screen, click this to make it disappear." And that's really distracting. So whoever is using Google drives, make sure you do that. And you may want to use the keyboard, because the mouse was not--

GUEST SPEAKER: It was flipping out.

PROFESSOR 2: Yes, it was there was not cooperating.

GUEST SPEAKER: I brought it for the actual game play, but we're not playing the game today.

PROFESSOR 2: OK, so recharge, and if it starts to give you that same problem, for the slides at least, you may want to just avoid using the mouse.

PROFESSOR 1: Actually, putting it in mirror mode, too, instead of two screens, would at least give you a full-screen version of the slides. The speaker notes give you a very tiny version of the slides.

PROFESSOR 2: Yes, it was very hard to see, actually. So mirroring your screen back and forth will also make it so that you don't every have to do that.

GUEST SPEAKER: Can you write that down?

PROFESSOR 2: I can email this actually, at least these notes. At the beginning of your presentation. If you can just-- when you introduce that your game's about heat waves, before you go into the things that you did, if you can just very briefly talk about what Red Cross workers have to do in heat waves.

GUEST SPEAKER: OK, yeah.

PROFESSOR 2: Yeah, of course, if that's after you demonstrate your game, then that may not be so necessary. But just to give people an-- just to make sure that before you start talking about this is what your team did, just give people an idea of this is what you're going to do in the game.

PROFESSOR 1: And you all have a choice of demoing the game before the presentation or after. It's whatever works best for your presentation.

PROFESSOR 2: So if you're showing the game first you may not need to describe this, but it if you're showing the game after your talk then you definitely need to explain that. When you say, "over-arching issues," as a bullet point, that tells me nothing. It's like, you had a big issue. But then later on of course you went into detail and talked-- oh, it was about dialogue, it was about learning, and stuff like that. I think the first time you introduce a bullet point, say over-arching issues, and you say, such as, the dialogue, bugs, and the learning, very quickly, just so that bullet point means something.

[? Rick ?] had already mentioned the thing about external code. When you talked about how you swapped your art assets, and you said, we talked to people about the art. Did you the mean play testers, or did you mean your client, or did you mean your team members? Right? They're all people, so which people? Yeah. I was assuming play testers based on the context. And finally, this has nothing to do the presentation. Does the game still use Fahrenheit?

GUEST SPEAKER: Can we change that?

PROFESSOR: What was the question?

GUEST SPEAKER: Fahrenheit? I don't think we have changed--

PROFESSOR: The game is still on Fahrenheit.

GUEST SPEAKER: It's still on Fahrenheit.

PROFESSOR: OK.

GUEST SPEAKER: We can change that today.

PROFESSOR: It's a bit risky to change it at this point. You might want to list that on your things to change in the future maybe, just add [INAUDIBLE].

PROFESSOR: That's enough.

PROFESSOR: Yeah, that's enough. I wouldn't touch the code.

PROFESSOR: Don't touch the code. Please don't touch the code.

PROFESSOR: Yeah. Just acknowledge that, because that was one of the big pieces of feedback, is that only the US uses Fahrenheit.

GUEST SPEAKER: Yeah.

[INAUDIBLE]?

PROFESSOR:

PROFESSOR: I'm not following, so he got [INAUDIBLE].

PROFESSOR: Sorry.

PROFESSOR: No.

PROFESSOR: So make sure it actually plays. So you're going to demonstrate it in unity rather than as a web hosted version?

GUEST SPEAKER: We might do a [INAUDIBLE] version, but we haven't had luck yet.

PROFESSOR: OK, cool.

GUEST SPEAKER: We're meeting after class.

PROFESSOR: Great. But it looks like whatever you're going to run it in, it's going to work at that resolution. And is there audio for it?

GUEST SPEAKER: Yeah. There is. But it's not playing right now.

PROFESSOR: OK. Oh, there's some.

GUEST SPEAKER: One of the things got lost, apparently.

PROFESSOR: So at least it's not muted.

GUEST SPEAKER: I'm sorry.

PROFESSOR: It looks like heartburn. It looks like it ate something bad.

GUEST SPEAKER: Thank you so much.

PROFESSOR: Thank you.

[APPLAUSE]

PROFESSOR: And thank you for being first.

PROFESSOR: Yeah.

PROFESSOR: I'll email you the notes.

PROFESSOR: "Hello Waves," come on down.

GUEST SPEAKER: So it's a little light on there, but our game is "Hello Waves." It's a game about forecast based financing that we're developing for the Red Cross. The idea of forecast based financing is using the idea of a forecast about the future in order to make decisions that are more effective than just reacting to disasters when they happen. So I'd like to show you a play through of our game. It should open up. Great. And let me turn on the sound.

[CLASSICAL MUSIC PLAYING]

 

So this is "Hello Waves." Here are the instructions. We would have done a tutorial if we had enough time, but this gets the idea across, and designing a good tutorial that actually teaches the player well is hard to do in a logical flow. So we have these instructions that explain how to play, what the point of the game is, and a couple of tips about how the game works. So if we go into the play screen, you see something similar to what we showed you a couple weeks ago, where you have all these different toys out there, castles.

And as you go through the days, you'll see a forecast of what the water level's going to be at over time. And so you can see that right now. They're gathering candy. The water level changed. This character is underwater, and so he takes damage. And so what you actually want to do is you want to move toys out of the water so that they don't get damaged. However, they can only move one castle over at a time. So because we didn't think ahead well enough, we'll see that this truck will actually take damage on the next term, because he's underwater.

Actually, he ended up not underwater. We got lucky there. But theoretically, he would have. And so as you go through it, the end goal of the game is to build a castle. And so every toy when they're home can either choose between gathering candy to feed evacuated toys or building the castle to reach your end goal of the game. And then the idea of the forecast is that you want to use the forecast in order to know how much candy you're going to need over the next couple of days and to use it to know when you're going to need to evaporate various toys from their variously hidden homes.

So back to the presentation. Full screen. So we had a couple of challenges in the design process. The first and the major one is really that we were trying to teach about forecast based financing, which was a bit of an abstract topic. It's a little different than just thinking long term, because you have to use the idea of there's some information we know about the future that we want to use to make optimal decisions, or at least decisions based on some idea of the risk that's out there. But we also wanted to avoid things like just pushing a button to win, where you have all the information you ever need, and there's just one option that you know you're going to pick every time. And the game has no thought whatsoever.

And we also needed to think about how we were going to communicate the forecast to the player so that they could then use that to make decisions. One of the problems that we also ran into related to this was that we focused a lot on the idea forecast based financing as the topic, and then tried to build a game built on top of that topic instead of building a game that used forecast based financing. So that held us back a lot in the beginning when we were trying to come up with ideas. We also had a really difficult initial target audience of policymakers-- 50, 60-year-old government officials, or people at NGOs who were going to be using forecast to make decisions of some sort.

And it was supposed to teach them about how they can use forecast to make these decisions, except this was a really difficult audience, because they don't generally play games. And they don't have a lot of time to learn about this kind of thing. And so we couldn't really expect to get them to sit down for a long period of time and play around with our game. In order to deal with these problems, we came up with a couple solutions. The first thing was that we had no idea what kind of game would work, or would make sense, or anything like that. So what we did is we just broke our team up into multiple groups and came up with a bunch of different prototypes.

On paper, we had two different prototypes. One that focused on the idea of managing a city, and its resources, and its response to disasters, versus focusing on individual people, and how you're going to move them around to keep them safe from the disasters. And then we went into a whole bunch of different digital prototypes-- one that was a text based game about managing a city. We had one that looked like this, where you had two different cities, and you were specifying what workers were going to do, or when they would leave the city in order to stay safe.

And then we would take the different ideas that we were learning from both of these prototypes, combine them together, take things out. And our final prototype actually uses ideas from all of these. Another solution that we got lucky with is when Pablo came to play our game, he told us that we actually shouldn't focus on the policymakers, because he wasn't confident that he could actually get them to play the game. And so we switched our target to being grade schoolers, which is why you saw the cutesy art with the beach and the toys.

This actually made it a lot easier for us, because we could target people who probably had some experience with games, or at least wanted to do something fun, and would be curious to learn about our topic.

GUEST SPEAKER: So for our development process-- or I can just speak here, right?

Yeah. You can speak right from there. That's fine.

GUEST SPEAKER: So another big issue, another set of challenges that we ran into was through our development process. And so we had initially issues with communication and facilitation. Our team had a wide variety of experiences and backgrounds. Some were hardcore gamers, some mostly mobile gamers. And so there were initially a lot of disagreements on what level of game we wanted to create, and what sort of game, casual versus hardcore that we wanted to create. And so we needed to overcome challenges of facilitation and communication within our team.

Another major challenge in our development process that we had to face came from our design issues, where for a very long time, we had a vague vision of what to do. We didn't know what kind of game we wanted to make, and so we purposely tried to keep our game ideas vague as we built prototypes. But then we ran into issues where we would have solutions. But no consensus on which solution was best, and where we went for long periods of time without having a clear direction of where we wanted our final game to be.

So our solutions for the challenges proposed by development were a team structure. And so we structured our team loosely into three subteams-- a production subteam, which would take care of production, like the deliverables, and making sure that all the game ideas are being communicated properly. A technical team, which worked primarily with the code and making sure the game got done, and then a user experience team, which handled art, UI, and sound. And so we kept our responsibilities flexible.

So as team members got busy over the semester, or as changing conditions, lots of different people contributing, responsibilities were able to easily flow between teams and team members. And additionally, another idea we started with in the beginning with the idea of sub-team leaders. [INAUDIBLE] the two people marked with the l's. But that was an idea we later abandoned in favor of just having a more flexible team structure, or a flat team structure. Another solution for helping our development process was the use of good code practices.

And I cannot emphasize enough that this really helped speed up our development, because we didn't run into trouble with code. It was mostly with design. So we used Yeoman, which is a JavaScript module system. And basically, it allowed our code to be interoperable. We can write one module separately from another module. So that solved a lot of issues with dependencies, or people working in parallel, because it allowed people to work in parallel without overriding each other's code.

We also used good code practice with state machines and NBC, which is motor vehicle control. And so we had a very object oriented code, very modular. And when we did need to change our code, rip it all out and put it back in, it actually didn't turn out to be too painful, because we just had to switch a couple objects around. And then one final solution that we used for our development processes were Slack and Scrum.

So Slack is like a modernized IRC chat room, and it's very feature rich. It has a lot of integrations with GitHub, and Google Drive, and things like that. And so that real time communication actually made it so that we didn't really have to meet outside of class too often. If someone was working, we would just email out saying, I'm on the Slack. And then people could meet on the slack. And it was full featured enough. We could send attachments and things like that.

Most of our communication in person communication could be done in class. And in class, we adopted a daily Scrum format, where we simply said what we had done since the previous class and what our goals were until next class. So in the end though, we did have to cut some features. These features mainly were the idea of again, a tutorial, or multiple levels, simply because they'd just be too much content that we need to play test in order to make sure that it was a consistent quality got our message across, and also, trying to add more individuality to the toys that you saw.

They have different graphics, but that's as much as we could do, given the time constraints. So kindly just bring it back. And our three worst decisions were first, we did end up spending a lot of time on code and assets that never got used. We maybe used 10% to 20% of our final work in our final project. Actually, maybe that is a bit overkill.

But maybe 30% of our final code and assets in our final project. This really was due to this second bad decision, that we kept the game and its direction too vague for too long. We always were holding out that oh, maybe we'll be able to come up with a better game idea. Or maybe we'll find some magic solution to how we can make forecast based financing into a game. And because of this mindset, we'd spent probably the first half of the project just staying too vague, and that hurt us in the end, because we spent so much time going in all these different directions.

And really, the decision that captured those first two though is the fact that we tried to make a game on top of forecast based financing. So we had forecast based financing. And we were like, how can we scan this as a game? Whereas once we switched that mindset and thought, let's have a game, and how can we put forecast based financing into it? I think that was the moment that we then came together as a team and really started making the final game that we wanted.

So our best decision.

GUEST SPEAKER: So one of our best decisions was that we chose good tools at the beginning, which meant that as we went through all these different prototypes, we actually didn't have to completely rewrite our game. We could pull out the way that workers worked. In one game, we could pull out the view that we were using in another game. And then we could just combine them together, and that allowed us to move quickly whenever we were changing our prototype.

We also weren't afraid to trust each other, both, in terms of what everyone was working on, but also, in terms of the decisions that we were making. And so when we said that we had to throw something out, we all understood that it was for the good of the project. And we didn't have a lot of complaining or hurt feelings when something didn't get put in, or when we decided to throw out our assets or code. And when we got to the end, we had been through enough of this vagueness that we were all frustrated with it. And we realized that we had an idea that we all liked, and we really got on board with it and made it happen.

Once we started working on our final idea, we saw that it worked. Basically, every decision from that point on was how do we make this game better? And we were all on board with that vision.

Thank you. Any questions?

[APPLAUSE]

 

[? PROFESSOR: Anyone in the ?] audience have [INAUDIBLE] first before--

AUDIENCE: We can't see [INAUDIBLE] across the [? room. ?]

GUEST SPEAKER: Yeah. We'll have to make all of our slides darker.

PROFESSOR: Yeah. Yellow and white.

PROFESSOR: Yeah. Like the yellow and white on your early screen, I was doing this on [INAUDIBLE]. I realize that's the game, not the presentation. But wow.

PROFESSOR: It's also a little faded in the game itself. It could be the display resolution you're using, so after class, after we're done with everything, try different resolutions. See if it makes a difference.

GUEST SPEAKER: Yeah. That's be great.

PROFESSOR: The music in the game development was too high. It was overpowering your voice. So I think you were almost hollering just to be able to be heard. It doesn't need to be that loud. So you can just crank down the volume right down on the computer or on the controls over there. Something that I had a question for. You don't have to answer it today. But you might want to put it in your presentation.

How long was the design of what you eventually established on the table before you decided that this was the thing you were going for? Because I'm assuming it was one of your vague-- it came up during your vague idea phase. And you're implying that you were in that mode for too long. But I don't know how long it was on the table, or was it only something you figured out at the end of the vague idea phase?

Because otherwise, you wouldn't have been able to switch to this idea if it was not on the table in the first place. And how did you decide this was it, that the same household game was going to be-- I understand-- I think you very clearly explained the benefits of deciding this was it. But how did you come to the conclusion that it was? That's stuff I wanted to hear more about.

But you don't have to answer it now.

PROFESSOR: Yeah. And just a little bit of specificity. You mentioned you spent too long on that design phase. I wonder how long that was.

GUEST SPEAKER: OK.

PROFESSOR: You said Pablo switched your target audience for you, telling us whether that was because of the game that he saw, or because of something else. If you know that information, throw it in there. If you don't know that information, that's fine. Knowing why you dropped the team lead-- you mentioned you dropped it, but you didn't exactly say why again. Really quick, we weren't getting [? blah ?] out of it, or the flexibility was more, whatever.

And defining your terms. You were saying things like casual versus hardcore. Give a little bit a definition of what you mean by that. It means different things for everybody. So what is your use of that?

PROFESSOR: I think he specifically said hardcore and mobile. But there are hardcore mobile players out there.

PROFESSOR: And casual can be considered a version of hardcore, just in a different way. So just be a little more clear, because I think you were talking about the target audience, and the kind of players, and the kind of games they might play. So just be a little bit more focused on what exactly you mean by that.

GUEST SPEAKER: OK.

PROFESSOR: That's it for me.

PROFESSOR: So we can start testing for observations in the young man who's not relaying [INAUDIBLE] module frame [INAUDIBLE]. It's just a system to generate the project, and it posts in the front [INAUDIBLE]. So again, just show that.

GUEST SPEAKER: OK.

PROFESSOR: So that's a terminology issue then.

PROFESSOR: Yeah.

PROFESSOR: Clearly, it worked out for your team, so we're not saying, don't mention Yeoman. It was clearly a good thing. But just check your definition of what it is, because it'll be more helpful for other people to understand what it is so that they can think about whether the want to use it in the future.

PROFESSOR: So your demo-- you spent about three minutes doing it. We are going to have a player from [INAUDIBLE] play your game live, without getting a lot of help. You can talk over it. You can, after a while, start helping them. We want to see them at least just start playing it on their own. Decide when you're going to put that demo in. You could actually combine them both together if you do it at the beginning or end. But if you do that, give the player a little bit of time before you start talking.

GUEST SPEAKER: OK. Sure.

PROFESSOR: That's all I got.

PROFESSOR: Great. Thanks.

[APPLAUSE]

PROFESSOR: Snap, come on down.

GUEST SPEAKER: Hi everyone. I'm part of the Snap team, and this Sabrina, who will talk about the front end aspects. I'll talk about the back end aspects. So I think we actually wanted to start with a demo of the game, and we'll do a real demo right now. So could everybody go to snapgame.org?

GUEST SPEAKER: You should turn on your volume, as well. It'll be interesting to see [INAUDIBLE].

GUEST SPEAKER: Oh, nice. My screen's hidden. And I will also play the game. Everybody ready who wants to play? So the way this game works is I'll explain it again, in case anybody hasn't heard this before. We're going to give you a topic, and then you're going to enter words related to that topic. Whenever you enter the same word that somebody else entered, you'll get a point, which we call a snap.

And the topic is algorithms. And you can cheat by looking at my screen, but please don't. I have no idea how I'm doing.

AUDIENCE: Oh, no. What happened?

GUEST SPEAKER: What happened? Oh. Oops.

AUDIENCE: We found a UI bug.

GUEST SPEAKER: I think it's this resolution. Probably. I did test this. I'm sorry. I never entered this many words. I can't scroll. I think we're going to stop this one. Wow. That was impressive. Justin won, followed by Rodrigo, and Rachel.

[APPLAUSE]

 

This is what you guys submitted.

[LAUGHTER]

 

This is a very MIT heavy. Domain.

GUEST SPEAKER: Someone put [? socks. ?]

GUEST SPEAKER: So that's our game. So the way we did this project was we split up into back end and front end teams from the very beginning. This was a bit of a challenge for new features, because initially, we both were really highly interdependent. But eventually, it became really nice, because it was simpler to manage a front end and a back end team individually, and they generally didn't need to talk to each other once the back end was off the ground.

I think that structuring our team with more individual roles, besides just having generally back end and front end people would have been helpful. UI design was something that we didn't think about early on enough, and that's why the UI is not as polished as it could have been. We could have had somebody just dedicated to taking information between the back end and front end, say, documenting the back end and making sure everybody knew how it worked. We also definitely had problems with paperwork, which would have been nice to have somebody who was really on top of that.

And then the game design, as well, was something. In addition to UI design, we also could have had somebody just looking at the game and thinking about the core game concepts, things like scoring and what we're going to display to players. We did a pretty good job with planning. We used Asana and Asana worked really well for us. It was quite flexible, let us manage independent task lists for front end and back end, which we think worked well all the way from the beginning to the end.

So separating out the task lists we liked, Asana we liked. Our project had a lot of dependencies, and this was something that Scrum inherently had a problem with, and our tools also had a problem with. It was hard to know, for example, when a task on the front end and back end were dependent. There wasn't a good way to encode that and see that the back end needed to get something done more quickly, because the front end could use it. We also had trouble just creating tasks.

I think that there was a diffusion of responsibility as to who would be creating tasks and who would be assigning them. Once the task got assigned, then it went pretty well. But we had trouble just getting all our tasks listed out. I think the core of all these problems was really getting people invested in the project and making sure that they treated it as a priority and really spent some effort on it. Want to talk about this?

GUEST SPEAKER: Sure. So we also used Slack for communicating as a team. And I think it was really helpful. I liked the fact that we could have multiple channels so that people working mainly on the front end didn't have to get all the communication going on with the back end. And then we also had channels for our Asana and GitHub so we could see what was going on with that. Some problems though where I feel like people weren't as active as they could have been-- I feel like maybe everyone should have downloaded the mobile app, or at least signed up for notifications so that everyone's aware constantly of what was going on.

And if someone mentioned them in a post. They were quickly able to respond and get back to them. And that's the main thing that I think we could improve upon if we use this in the future.

GUEST SPEAKER: So going a little bit specifically into the back end, what went right for us was definitely our technology. We used node.js as the server and socket.io to do the two way communication so that you could receive snaps from other players. And we deployed on heroku. All those three things worked really well. We had no problems with them. And the design of the back end also went pretty well.

It's a pretty simple server to implement, and we did a good job of figuring out what it needed to support. We didn't document as well as we could have, in terms of what is the published API that the front end should be using. So in socket.io, you send all these events, and the names and the formats of the events were not well documented for a long time. There wasn't a lot that I would change on how the back end was structured and how it went. But I think maybe we had too many people working on it for the small amount of work that it was, and it would have helped if people more people had worked on the front end.

That's also part of finalizing and freezing. If we had just finalized and frozen the back end, then we could've stopped worrying about it and just moved on. Networking was explicitly forbidden in the rules of the class, which we did break, and we intentionally broke it quite early on. Networking really didn't give us very many problems. We had a couple heroku issues, where we had to quickly do a deploy, or there was a bug, such as the one you just saw. But really, heroku went really well for us, and you could easily roll back.

And heroku gives you good documentation on what code exactly ran every single time. We actually have been deploying to the client. The client has been using this for a while now. These are some of the tests they've run. And you can see that they're quite different, in terms of how many teams there were, how long they went. I'm not really sure what the really long games were like. We still need to talk to Pablo about his feedback for those.

But indeed, there were words being submitted for those entire three hours. And just to give you a sense, I'd actually like to show one of these word clouds. So these are much more serious topics than algorithms, where actually, looking at the words will give you a sense of what people are thinking about a topic that you care about. So for example, I think I'll just include screenshots of those, because that doesn't work very well. So here, the topic of this conference is zero poverty, zero emissions within a generation.

And you can see, education seems to be a big theme in this conference. I can tell that just by looking at the word clouds, of several of them, actually. And a lot of our effort ended up being focused on the client, as opposed to the class. I think that's part of what made our paperwork fall behind, is that I've been working a lot on supporting these runs that happened in the past four days, as opposed to the deliverables of the class, because I thought that this was important.

It's part of why we have snapgame.org.

GUEST SPEAKER: Developing the back end, we were really successful. But I felt when it came to the front end, we struggled a little bit. I think a main challenge was the game is game that was intentionally made to play person to person, and have that communication. And representing that in a digital game was a big challenge that we had to do. So in our first design, we decided we were going to use Phaser, and it looked something like this. And obviously, Phaser wasn't even really being used, so what was the point?

So we dropped Phaser, and then we went to just using Bootstrap. Here, we're just using Bootstrap in JavaScript to handle all the input from the users. And then in our final design with as you saw, the dots and the drawing, we're using a JavaScript library called 2JS. So what went right was I think we had really good people to do UI design. But we didn't really begin thinking about that until later. And it took us a really long time to be able to represent the game in a really good way to the user. There were a lot of challenges we faced in doing that.

So I will come back to this. Some of the first ideas that we had for how we're going to represent the information to the player was by using a word cloud that we used on the end, but blurring out the words until they actually submitted a word. Then we would display it. But this is actually really, really challenging, and so we didn't want to spend our time doing something like that.

Then we considered having some sort of line where you're racing against the other players to get to the top. But this isn't entirely interesting, so we considered including both of them. But then again, the word cloud, we ended up deciding that was too difficult. So we came up with the idea of everyone's a dot, and your score would be represented by how big your dot is.

But if you're playing with 100 people, this is just unreasonable. And so then we finally came up with this last idea, which is nearly complete, where the height of your dot represents where you are in relation to the max score. And the lines are representing snap connections that are going along with the other players. So basically, I think for future projects for the front end, we definitely need to think about design sooner. This process happened really slowly and really close to the end.

We were very focused on the functionality of our game and the mechanics, and not a lot about the player's interaction with the game. It would have been awesome if we did some prototyping early on, because we had some other ideas. And we just never put them into fruition, and we never tested them out. So it would have been interesting to make those and see what users thought of them.

GUEST SPEAKER: So I think working with a large group was definitely difficult. And splitting it up was a good idea. But I think that having more responsibility and roles within those people would have been very helpful. We also should have thought about design sooner. I think also, from Miriam's presentation, the idea that we should have thought about the game and making it fun was something we should have focused on, as opposed to just thinking about porting a game that we had seen.

We really should have focused on what makes this a fun game, and what could we do to improve it? Because the core game can be done very quickly, and within the first couple weeks, we had the core concept done. So I think more quickly, we could have figured out, what feedback should we give to players? How can we make it more competitive, which I think it makes it more interesting as a game, as opposed to as a tool to collect data?

That's all we have. Are there any questions?

[APPLAUSE]

 

PROFESSOR: Anybody else from the class? Any suggestions? No? Well, we've got some. You want to go first?

PROFESSOR: So one thing that I noticed was there was a screen where you had the [INAUDIBLE] didn't future. That made no sense to me at all. I stared at that slide for a while. And then I heard what you were talking about, and then ah--what worked, what didn't, what are we going to do in the future. I can see how you might do it, because it fits with the snap theme of having just a single word.

But wow, that was really confusing.

PROFESSOR: Oh, that's why all [INAUDIBLE] are in small letters.

PROFESSOR: Yeah. It took me a while to realize what was going on. I'm guessing that. I don't know for sure.

PROFESSOR: Is that what you were going for?

GUEST SPEAKER: Not really. It was just for consistency.

PROFESSOR: OK.

PROFESSOR: Slightly more clarity would be helpful. You talked about the task diffusion, having a hard time getting tasks assigned. But when you talked about dividing your team into groups, you didn't talk about what the structure was running those groups or anything. You didn't have any of that was what was going on. But you might want to be maybe more explicit about that.

PROFESSOR: Yeah, like how did somebody take a task from Asana, by the way.

PROFESSOR: Yeah.

PROFESSOR: Was there a process for that? Did that actually happen that way? Or was it an assignment?

PROFESSOR: Yeah. Was there one person generating tasks? Or did the groups generate tasks collectively? That sort of thing. I think that's most of what I have.

PROFESSOR: So first of all, the demo for the game probably is what we're going to have to do on the real day itself, because it's such a large scale game. So it's not going to be like two people playing the game. So we can probably run the demo pretty much the way that you did.

GUEST SPEAKER: [INAUDIBLE] that's what we were [INAUDIBLE].

PROFESSOR: Is that the way that they do it when they run it?

GUEST SPEAKER: It depends. So Pablo has been actually doing a limited number of words. And only at the World Bank are they doing it like the way we are doing it, where everybody's submitting. And that, they haven't done yet. That's actually this afternoon.

PROFESSOR: You might want to talk a little bit about the history of this game. Everyone in this room right now has played the original game.

PROFESSOR: Absolutely.

PROFESSOR: Yeah. Similar to some of the things. I have it-- why are all your subheadings in small letters? Because it really, really threw me. Now, maybe it was unintended to make it look like your game [? snap, ?] but it actually does make it hard to read, your slides. All caps would be even easier than all small letters. There's one slide where you talk about adding roles for specific game design, UI, and everything.

But the heading just says, future. The big takeaway is more specific roles. You'll see it. So that should be on your slide. Your slides move really fast on average. And some of your slides are more word-heavy than others.

GUEST SPEAKER: OK.

PROFESSOR: So for the ones that are word heavy, them up a little longer, or make them less wordy. One or the other. Otherwise, I'm trying to read everything, and I can't even listen to what you're saying before the next slide changes. When you described the mobile app, I'm assuming you meant an Asana mobile app?

GUEST SPEAKER: The slack mobile app, yeah.

PROFESSOR: The slack mobile app, OK. Just be specific, because it wasn't entirely clear what you meant by that. So yes, put screenshots into your presentation instead of switching windows. That will just make things easier. There are maybe people in the audience who actually haven't used Phaser or know what Phaser is. So when you say, Phaser clearly isn't doing anything useful, well, they don't know what Phaser does.

So just explain. Phaser's a sprite-based game engine. We have no sprites, something like that. Two points about the game itself. First of all, how do you tell which dart is yours?

GUEST SPEAKER: It's the green one.

PROFESSOR: OK. I think because of the peripheral vision, I really did not even notice there was a green dot.

GUEST SPEAKER: Yeah.

PROFESSOR: So maybe it's just my eyes or something.

PROFESSOR: I didn't see it either.

PROFESSOR: OK. How many people actually noticed a green dot?

PROFESSOR: [INAUDIBLE] mine was so small.

AUDIENCE: There was a random green dot in the screen, and I couldn't do anything to it, so I kept [INAUDIBLE].

PROFESSOR: There is a green dot on screen, and it's really hard to see a green dot. There's something about the way how the human vision works on that.

GUEST SPEAKER: I think it's also because there are so many people.

PROFESSOR: Yeah.

GUEST SPEAKER: We've never tested with more than five people, and there are a lot of dots on screen when I don't know how many people were in that game--

PROFESSOR: I think it's cool that there is a dot that is yours, and that it has a meaning to it. But just being aware that that dot even exists and is different from the dots is more challenging than you might have realized.

GUEST SPEAKER: Yeah.

PROFESSOR: And then finally, one thing about the networking thing. it's actually really, really neat that [? Heroku ?] and [INAUDIBLE] seems to have solved problems that we traditionally, in this class, have just derailed entire teams. So it's a possibility that you just have an awesome team.

GUEST SPEAKER: Yeah. I think one thing I forgot to mention is that we have a lot of experience in all of these technologies. And so that helped.

PROFESSOR: What happens if somebody who doesn't know anything about node.js or hiroku decides, they're going to make a networking game?

GUEST SPEAKER: I have no idea.

PROFESSOR: So you might want to talk about that.

PROFESSOR: Mine, to reiterate-- client support versus class deliverables was a good point. Speak more about the client, and what you did for them, and what their role was on the team. It sounds like they had a more active role. And dependencies-- when you talk about dependencies and scrum, having difficulty with that, absolutely true. What did you do to get past it? Explain that.

Or if you didn't do anything to get past it, say that. But say whatever it is, rather than-- you do a lot of [INAUDIBLE] does this. But you don't go into the how. So go a little bit into the how for at least that point. Thank you.

[APPLAUSE]

PROFESSOR: Would you need a break? Or are we good on time?

PROFESSOR: No, let's just hammer through them.

PROFESSOR: All right. "Saving Gora Gora?"

PROFESSOR: "Saving Gora Gora," come on down.

GUEST SPEAKER: So we're the "Saving Gora Gora" team, us plus some devs in the audience. And I'm Liz, and I'll be starting you guys off. So quick overview of our game's goals coming into the project. We wanted to inform players about a cholera, and specifically, the causes, and the systems, and the prevention of the disease. And our audience, we wanted to narrow that down really early.

Specifically, we were more interested in targeting the younger age range of 8 to 13. And we had specific issues of that, which we'll talk about later on. And mainly, we wanted to have all these education goals and audience goals; be a part of a fun game, basically, like we wanted our game to be fun, and not one of those educational games they play, and then you fall asleep, and it's basically a poster.

A quick overview of what the game ended up looking like. This is "Saving Gora Gora." It's a children's game, and you are visiting a village of animals which is falling ill. And as a player, your goal is to help figure out what is causing the illness and trying to defend the character in the game, which we'll talk about now. A big part of our game is narrative, which is why we're going to do the demo later, because we wanted to ease you into the narrative without having you read all the text.

Everyone in Gora Gora is sick. We have this monster that is being blamed for it. He is totally a cool guy though, and he wants you to help you prove his innocence. You're Kojo. You're a little bunny kid, and you need to work with the town to prove to the town that it's not Sal that's making everybody sick. It's actually cholera. Basic gameplay is you're the main character.

This is Kojo. And you'll unlock minigames by exploring the map. Each minigame will give you a clue to prove that Sal is innocent, and your ultimate goal is to convince the mayor that Sal is a cool guy, and he shouldn't be in that cage that you see in the background.

GUEST SPEAKER: So our first minigame was about water filtration. And the basis of the minigame is that friends and neighbors in the village are bringing water to Kojo's mom, because they don't know whether it's safe to drink or not. So the goal of the game is to have the player decide whether each water source is safe to drink from. And along the process of developing that minigame, we had to actually iterate over the physical design of the minigame quite a bit, because our first idea was since it's water filtration, we wanted to make it perhaps a facility.

But we realized that wasn't relatable. It wasn't culturally relevant to all the kids who would be playing this game, so then our final design ended up being outside a home, as you can see in the background. So a couple other challenges we had. First, we had it working in real time, where the player had to rush to get things done in the minigame. But we thought that that took away from the overall purpose of teaching the kids, so we made it a lot more relaxed, a lot less time constrained, and allowed player to play at their own pace.

And lastly, we wanted to make sure that the game was clear. The game plan was clear. But we didn't want to make it too text heavy. And we considered making a tutorial, but we didn't have enough time to actually implement that, so we added some instruction text boxes on an overlay to just try to get the player a brief overview. And then during the game, they're also able to go back into these instructions and reread it so it becomes more clear.

GUEST SPEAKER: So the next minigame is a water collection game, where Kojo, the main player, needs to help his friend find a safe water source, since you have to go look for water and figure out where to drink, or where to get it. He basically helps his friend choose where to get the water from. So they basically show you a village map, and you would choose which places on the village map you would want to get the water from.

In terms of challenges and how I started developing the game, we wanted to make sure it was "fail-safe" so that even if the player chose the wrong choice, then they would get feedback. They would learn why that wasn't the right choice, and then be able to continue playing the game until they made the right choice. Originally, we did have an excreter. You had to find where you would also excrete.

But we cut that feature pretty early on, since we thought it was less crucial, and we wanted to focus on water. And then other challenges were, as Kevin said, we had some cultural issues, in terms of design, so we revamped our images. And also, we wanted to provide more feedback to the player as they were playing. So throughout our development process, we added things like helper texts and more explanations about why you did or didn't do things correctly.

GUEST SPEAKER: Our third minigame is focused around understanding the symptoms of cholera and understanding how important it is to act early on these symptoms. So in the game, the doctor of the village, Dr. Quasi, is very busy, and he can't go out into the village to help patients, because he has so many patients that are coming to him already. So he asks Kojo to go help him find sick patients to go talk to his friends and see if they have any of these symptoms, tell them to come to the clinic so that they can get treated.

During the development of this game, we initially started off with the idea that you'd be helping the doctor diagnose patients at the hospital. But then we realized that this would quickly turn into a quiz and wouldn't be as engaging or as fun. And it would essentially be the same as reading off of a pamphlet. So we wanted to add more of a game aspect to it, so we decided to make it such that you are going out and trying to find people, and suggesting to them that they go to the doctor's office. And then another one of the cultural things that we ran into is initially, you're playing as a kid. But we initially had it such that you're going around and talking to some of the adults.

And as Pablo pointed out to us, there's a much stricter social hierarchy in Ghana, and it might seem appropriate that we are suggesting to kids that they demand that their parents go to the doctor's office, because that's not something that would necessarily happen in the Ghana social structure. So we decided to change that around to you're talking to your friends, who are the same age as you. And you're talking to your friends, and you're having them go to the doctor's office. Some of the challenges we ran into, since this is a very conversation based game, making sure that the dialogue UI was understandable, and that you knew when you had choices available to you, to choose, and when you were talking, versus the other person was talking.

This was something that we had to integrate over multiple times. And finally, making sure that the dialogue was age appropriate. Since these kids don't speak English as their primary language and they're children, we wanted to make sure that the dialogue was simple enough for the children to understand-- but also, still had the meaning behind it so that they realized what actions they were taking through their dialogue. And now, we're going to start our demonstration.

GUEST SPEAKER: So it starts out with the monster hiding. And the monster is hiding from Kojo. And Kojo's like, why are you hiding? And so you see, people are blaming him for everyone's sickness. And so you say you'll help and you know who to talk to. But then when you bring him to the mayor, he's locked up by the mayor. And you're trying to convince the mayor that he's not the actual monster.

So you can see the beginning dialogue really sets up the scene for the story. And now, as Kojo, I'll say, I don't know, but I'll figure it out. And so now that you're in the town, you can explore the town. And you might be able to talk to some of the people. And so the people around town will give you things that will help you. So this dog is giving you matches.

And you might figure out later, oh. And now, you see of matches in your inventory, and you might be able to use that later. So for example, we can also click on the different buildings. And now, we realize that your friend is missing a bucket. So you tell them you'll go look for it. And we see that oh, the monkey has a bucket.

So then you can get the bucket from the monkey. And then now, you can go back and tell your friend, oh. You found the bucket. And so this brings you to one of the minigames, the collection minigame. And you can see, you can drag the bowl to different locations. And you can also click on the locations to see what they are. And you might say, I'm done. But it looks like this water spot is rusty.

So that's where the fail safe part comes in. And if you eventually drag it to a good source of water, it'll say, thanks. And you've acquired a clue. So then the next minigame, as Kevin was talking about, is you have to purify water. And so as you see, there's a lot of help or text to help you get started. And you can just drag the water. It says it's discolored, so I think we'll have to boil it. And eventually, the game, you have to figure out what to do with all the water and collect enough water.

And so I think we'll just cut that short, since we're a little short on time, and then we'll show the rest of the game for the final presentation.

GUEST SPEAKER: So in terms of like too technical challenges we ran into first is like the states and stays there, obviously, there are six of these are and we have to find a way to work around keeping a lot of paired data, in terms of clues and which games you had completed, what dialogues you were on, which dialogue should show up. So that was something-- that was a little bit of a challenge that we figured out. And then additionally, balancing difficulty with accessibility.

So we mitigated that by using things like helper texts, and using a hand cursor when you're allowed to click on things-- stuff like that.

GUEST SPEAKER: So one of the other biggest problems that we had, or I would say, the biggest problem we had is that our target audience and [INAUDIBLE] are completely two separate groups. We're targetting 8 to 13-year-olds in Ghana. We're college students in the United States. There's this complete different culture. And so we had to do a lot of research to make sure that our game was connecting to this audience. I think we did a good job. I think we could do a better job. We don't know.

We didn't get to play-test with our target audience. So unfortunately, we aren't 100% sure that this game's going to connect to these people. And another challenge is playing meaningful-- again, just because [INAUDIBLE]. So things that went wrong. Our communication was really good, but we never talked about deadlines for things. We would say, oh, we will have this done by the end of the week.

But then somebody would need [INAUDIBLE] assets, and it wouldn't be done. Sorry. Or we would want to play test the game at a certain date, and there wasn't a running game at the time. So I think one of the things that we had a problem with, just making deadlines, making sure people were doing things on a timely manner. And then we were having good communication, just not constant communication.

We were using several tools, but unfortunately, I think that's the next slide. We were using Trello, meeting weekly. We did use Slack. Unfortunately, not everyone was on Slack. Not everyone was using Trello, and not everyone was able to go to the meetings, and so sometimes, we would communicate with three fourths of the team, but there would be people that were completely out of the loop.

So things that went right. We did separate our team into basically two different sub-teams. There were four people coding, and then me and Liz were doing the art. She was doing character art. I was doing background art and all of the other assets. Then we'd have someone doing the [INAUDIBLE].

And so just by separating the team, it made things a little easier. You didn't have eight people touching code and breaking things or five different people making the art for something and having completely different styles.

We had a meeting every week, pretty much. Not everyone was always there, but it was very useful to just get up to date on what everyone was doing.

And then something that we did early was just cut a few features. We cut a fourth mini game that was picture matchmaking, which didn't really make sense, so we just completely cut it. Just cutting things like choosing where to dispose of your waste, something that we did early on that helped us.

So then moving forward, things that we would want to do is just test the game more. We would have loved to find someone familiar with our target audience or to play test with our target audience just to make the game better. Then changing things like difficulty and making sure the game is culturally relevant. I know I would want to play test more and then change some of the elements that I don't think are too great right now.

And then even going further, just expanding the game and making it more interesting, having more mini games and having more, an interesting mystery, rather than little paragraphs. That's all.

[APPLAUSE]

RICK EBERHARDT: Thanks. Any questions? Comments? I didn't think so.

OK. The demo that you did mid-presentation, you might want to rethink how you do that. Again, you're going to have somebody playing the game anyway. Maybe you could put some of that description while they're playing the game. Maybe you just demonstrate the map and say, here's a mini game, and then you'll see these mini games in play.

Or if what you're trying to do is help us understand what the games are, just give us a screenshot. That's probably enough. I don't think we needed it when we were watching the presentation to understand what you were talking about. I think you did a pretty good job of that when you were talking about individual things.

And then my big question, what I'd like to know more, is you mentioned the big thing as being the research you did for cultural appropriateness, what was it? Tell us what you did in the presentation. Maybe even give it its own slide. I think it's pretty important.

ANDREW GRANT: The social hierarchy example was a very good, specific example. We need more of those. So what changes you actually had to make once you realized that was a problem. You've got it in this umbrella category of cultural issues, but the specific stuff is really cool.

RICK EBERHARDT: That's it for me.

ANDREW GRANT: Sara?

SARA VERNILLI: No. I think Rick actually got most of what I was--

ANDREW GRANT: You might want to move the Tools slide before What Went Wrong because all the way things worked out, you just covered that first. The water filtration picture, where you say you can see it in the background, no. We can't see it the background. The background for that particular slide was totally invisible on this projector, so increase the contrast on that image or actually put it in as an inset.

You two need to warm up before you present. Your voices get louder as you speak, so practice outside of something. Warm it up and you're more audible.

This is more of a game design thing. There is a bucket right next to the well while you are trying to find a bucket, and every player is going to say, why isn't that bucket just good enough? Stick a hole in the bucket or something, whatever is the easiest way to solve that problem. That's pretty much all I had.

RICK EBERHARDT: OK. Thank you.

[APPLAUSE]

All right. Last up, Cholera Control.

STUDENT 2: Hi, everybody. We're Cholera Control. We're going to make this really simple. Our game was about cholera and it is a strategy game. You have to sort of manage many villages and try to tell them what they should implement in order to help prevent cholera within their village. And so we're going to just go through what went right, what went wrong, what we learned, and any future changes we would make.

So firstly, what went right. What happened over the course of the class is we simplified the game, and that was one of the best decisions we made that was really hard to do. Adjusting scope is really challenging because there are a lot of things you want to have in your game, you want to happen, but when you realize you just can't do it, it's like a load off your shoulders and you can really focus on the things that are important.

One of the things we did simplify is what the player can do. They have less actions, and we'll show that when we have some screenshots, but they're more meaningful. What the player is doing has a bigger effect on the game, and so they don't feel like they're just clicking buttons. They're actually thinking. They're strategizing rather than just, oh, I need to click these as fast as I can. And it's also more fun for the player. There's not too many. There's just enough.

The iteration was really one of the other things that went really right. It was the best experience in the class as a whole for changing the game is when you do that iteration, it feels really good when you look back and you see, wow, look how far our game has come. Look at the changes we've made. And comparing those really helps you realize the choices we made are good. Some of them are bad, but most of them are good. And we also had design meetings that were occasionally a struggle for everyone to attend, but when they did, they were really productive and really helped the group know what was going on, know what had to be done.

And lastly, the huge design change we did halfway through the eight weeks, this is what it originally looked like when we had a full digital prototype. It was really confusing. There are four villages. They had little bars over them. People didn't know what that meant. There's text in the top corner of the screen that you can't read and you couldn't even read when it was screen that told you your money and the population of each village, and then those two buttons that people weren't really sure were buttons, so that was really difficult.

This is what it looks like now. It's much clearer. There's a nice bar at the top telling you your money, how many days, and a nice little pause menu, and then there are only four villages. They take up the whole screen. It's very obvious that you want to click those. And also, there's a lot of indicators as to what's going on in each one.

Before, you had to click on each village and then up in the corner, that text would change to tell you what's going on in that village, and now, you can see it. It was a quick overview when you're watching. And so you have the population that's sick and that's not sick, and the green bar is healthy and red is infected, and then an arrow telling you the direction in which the infection rate is going, whether it's going towards more people getting healthy or more people getting sick.

And then you also have those little circles beneath each locality. We call them localities. It's a better term than "village." We wanted it to be very neutral, and that's what our clients told us we should use. And so below each locality are those four little bubbles that show what you've implemented there, and they count down. You might not be able to see it. It's a little small on this screen, but they count down and become less colored in or a little bit darker so you know how much longer it'll last.

And then for the menu of when you clicked a village, that's what it originally looked like. It was really hard to read. There were a lot of choices that you could do. We had eight, I think, is there, which at first, we were like, yeah, this is a strategy game. It's going to be really hard. There's going to be a lot of choices, a lot of things you can do, and this ended up being a very poor choice.

And so this is what it looks like now, where it's much clearer, first of all, how to close it, how to get back to the main screen, also what you can do. When you hover over something, in the Description box, its description pops up. If something's implemented, which nothing is in this locality, but if something was implemented, that circle would also be colored in and counting down to how long until you can implement it again.

So then what went wrong. First thing was coding. Working together is really hard. We learned this over the project. So we thought, OK, we'll divide everything up. We'll make it so everyone can work independently and make sure there aren't any real dependencies that are going to be roadblocks. But even doing that, it's still hard when you have to bring everything back together and there were just inconsistencies. People had different coding styles and merging just took a lot longer than it should have taken.

Motivation was also a really big problem. At the beginning of this project, people weren't really passionate about cholera or making a game about cholera, and even as we came up with designs and interesting choice and things we thought would be fun, that passion just didn't grow. It was always just like, I don't want to do this, which is really hard. I don't know how we could change that.

Also, the topic was really restrictive. It's something that probably that I'm guessing must happen a lot in the real world that sometimes you work on things that you don't want to work on, but you have to find a way to struggle through that.

We also had crunch problems. Our team was just a lot of crunches. There wasn't constant work. There was a lot of crunches. And so we had a lot of crunching right before a play testing class. We had a lot of crunching after Thanksgiving before now, and the work on the game was really low priority because everyone has other classes that they need to do things for. And so it is hard to tell people, no, you need to do this because they're like, I have a thesis project due. That's way more important than a project for this class.

And another thing that happened over time is that people weren't adhering to the communication we agreed on. We said, OK, we'll do emails and we'll use Gitter, which is sort of tied in with GitHub, and then people weren't on Gitter or they didn't reply to emails. And so whenever you sent out a message, it was like throwing it out into the ether and then hoping people would respond, which is really challenging. Sometimes you forget to log onto Gitter or you forget to look at an email until later, so it's difficult. It's something that happens, but it's a hard thing to deal with.

So then what we learned. Within game design, there's actually a lot we learned from this project. The biggest thing is that more complicated and more choices does not equal more fun. It can, and if you're making a really big strategy game like Civilization, I could see where you'd want to have the ability to do a lot of things, but in something simpler, you don't need to be able to do as many things. But if those things have meaning, which our choices now do, it's a lot more fun.

Play testing revealed that a lot of people didn't like having so many choices. They didn't know what to do. It was real time, so people were dying and they were like, I lost the game before I even felt like I started.

Design is very restrictive. You need to pay attention not only to what the client wants, but also who you're making this for. How accessible does it need to be? Who's the target audience?

And also, it's really hard as a designer to realize you need to put both the player and the client's needs before your own. You as a designer know, I have this grand vision of what our game should be, but then play testers say, we don't like your vision. You need to change it. It needs to do this. And your clients say, we don't like your vision either. It needs to change. You need to do this. And so doing that is very hard as a designer, but we learned to do it and the game was better as a result of it.

Some other things is none of us knew anything about cholera when we started, so we learned a lot about cholera. And it's surprising how easy it is if you just wash your hands. That's it. So if you're in Ghana, just wash your hands, guys. And probably don't drink infected water sources, but the big one is wash your hands.

And that also applies to a lot of other things. Pablo actually asked us to emphasize the washing your hands because Ebola also, it benefits if people wash your hands. It helps you so you don't catch other diseases.

And then about coding is tweening and other animation APIs make a game look more polished for little effort, which is something we didn't really implement until the end, and then when we did, we were like, wow, that looks a lot better.

And then future changes. So for just within the game, things that we never got to implement but we really would like to are subtle effects that would force people to change their strategy because sometimes it can get really easy, and so we'd want to make it so people who quickly figured out a strategy and then think, oh, we can win is we wanted to make some things that their strategy doesn't work anymore. So we originally we had the idea of a change in season, which is something we would like to do, but time constraints, or random events where there's maybe not a change in season, but there happened to be really heavy rain one day so everything flooded, so now all the water sources are more infected.

Also, multiple levels of difficulty. We did like simplifying it, but there are still some things we'd like to add, at least one more action and maybe a few more villages. So that's something that we would like to add if we had more time. And also, more advanced infection models. You can talk about the infection models if you want.

STUDENT 3: I'll chime in there. It turns out to be really, really hard to balance the spread of infection of a disease. It's almost impossible to make the game relatively simple at the beginning but then the right level of difficulty at the end because the nature of infection is that it's exponential. You change a parameter by nothing and it just swings the whole thing over and makes the game go from very easy to completely impossible.

So that made it really, really hard to balance. If I had more time, if I had a few more weeks to work on it, probably the things I'd want to work on would be work on something more advanced, like some more advanced mathematical models, as opposed to just a simple exponential model that we currently have, because that could make game balancing much easier. I had a really hard time balancing infection.

STUDENT 2: And lastly, some things we'd change for the class is we wished that we had something that enforced the sprint tasklist. We submitted it every week but we were never held to actually doing what we said we were going to do. So it felt just like, oh, it's something we have to do. We have to say we'll do things this week in order to be working on the game. So we wish there was something like the instructors asking, OK, can we see your completed sprint tasklist?

The restriction to the Red Cross topics was a huge constraint for the creative freedom, especially for the last project. So because all of us didn't really like the topic to begin with, it was a really long eight weeks. So we wish that we didn't have to do that, but I understand for this semester of this class, that was what happened.

And then another thing is that we wouldn't work on an educational game regarding an unknown culture for the final project because it was just really hard to understand, OK, what do people in Ghana find normal? What would they want in a game? Do they understand how this works? It's something that's even hard because there are a lot of assumptions people who have played games make about games that's really hard to get over. And so doing that for the final project that also has to be an educational game that also has to be about cholera, it's just like there's a lot of things piling up that made it really hard to do.

So any questions? And we'll also show a demo of the game, but if you guys want to ask any questions first.

[APPLAUSE]

 

Should we do demo first and then questions?

RICK EBERHARDT: Yeah, go ahead and demo.

ANDREW GRANT: Both on this screen and with some of the earlier teams, many of you are running off Mac and you are using a screen resolution that's better for your screen than for the projector. So it's actually rescaling it to fit the projector, which means actually, every pixel that you're drawing on screen is actually too small for the projector and things get blurred out. In the Screen Resolution Settings in System Preferences, you can actually select whether you are scaling it optimized for either display. I guess in this case, you are optimizing it for display.

RICK EBERHARDT: Which resolution are you using?

ANDREW GRANT: It looks like you're using 1600.

STUDENT 3: What's the best one?

RICK EBERHARDT: It's on the board right behind you. There's a wide screen and a four three version.

ANDREW GRANT: So check that because you're using a lot of visual detail when you're scaling it like that. It makes your games look worse. That looks way better.

RICK EBERHARDT: And the color scheme is going to be better, too.

ANDREW GRANT: Yeah. Your colors do look better as a result.

STUDENT 3: Cool. Awesome. So we still have a little bit of things to iron out, but the idea of the game is that you manage these villages. Cholera is spreading and you have to use various prevention measures to stop it from spreading further.

So when the game starts out, there's just one village. People were having difficulty figuring out that you could actually click it, so we made it do like that so you know you can click it. So you click it and then there's various options that you can use to stop the spread of cholera. So it's just the first village, so I'll just go with soap, which is the cheapest option, and that usually stops. I'll make it go faster.

The first village is sort of a tutorial. Once you've figured out how everything works and you're able to stop the infection there and you cure it, then a second village pops up. As the game goes on, more villages pop up, up to a total of four villages. Basically, at the beginning, it's quite easy. You can't really lose on the first village unless you sit and stare at it and do nothing for three minutes.

But the second village comes up and now you have to think about things, then you get an idea of how the game is actually played. By the time the third village comes up, you really need a strategy or you're going to lose. And the fourth village, it just gets really, really hard. Generally, most people actually fail in the third village, don't make it to the fourth one. I guess if you guys want to see more game play.

RICK EBERHARDT: Is there sound?

STUDENT 3: So we don't have sound right now. We're going to add that in today. So the three different options, basically, soap is the cheap, all around option because we want the takeaway of the game is soap is overpowering. These two options distinguish themselves in that water containers are good for stopping an infection from spreading but they don't cure anymore, and electrolytes don't stop anything from spreading but they immediately cure just a percentage of the infected population.

What we found is that I thought electrolytes weren't actually going to be fun, but then they are, because at the end of the game when the infection is all over the place and everyone's dying, you just keep spanning electrolytes. It has a cool down so you can't keep spanning, but you span it as much as you can to desperately stay alive. I don't know how far to actually take this.

RICK EBERHARDT: That's fine for us. A live player is going to play it on their own, so they'll be figuring stuff out. Again, give them a couple minutes, and then you can start talking if you'd like to talk over.

For the presentation itself, when you started out, we could use a little bit more context about what you're talking about. You kind of just throw us into what went right and one of the things that went right, so maybe telling us what you're going to talk about might be a way to give context for the full presentation.

STUDENT 2: Would starting with the game give a better idea?

RICK EBERHARDT: That would be good, especially if you're talking over the game and talking about some of the design. Then we can kind of call back.

SARA VERNILLI: Another context related issue is you refer to your client and you refer to the game and you refer to making the game about cholera but you don't actually explicitly state who your client is, what your game is for, what the goal you were trying to create your game for, what specifically it was. You could gather it from context, but it's a nice thing to have upfront.

ANDREW GRANT: So the early slides, they're pretty wordy. Both of you are actually really good speakers, so I feel like you can get a lot of those points in your actual verbal-- you did, in fact, get all those points across in your verbal things. The slides don't need to also restate every single thing. So stick to high level headers, but the way how you're actually presenting these points are coming across very clearly verbally and the words are starting to distract a little bit.

RICK EBERHARDT: Yeah. Each one of those could have been just one slide plus an image.

ANDREW GRANT: That becomes a backdrop to the things that you're actually saying, which are actually coming across quite clearly and you don't really need all of that additional visual noise, especially when you have sub-bullets, like you have a heading and then you have tiny little sub-bullets underneath. Those sub-bullets, just say them. Don't represent them.

The image of selecting which updates you have for each locality, right now you have the blank rectangle with mouseover text in it. Nothing is lit up. If you just replace that with a screenshot of something's lit up, something's not lit up with the mouseover text, that will be way more informative, that one slide alone.

When you talk about balancing the infection rate, that's a really good detail case example. I just want to call that out. That level of detail is neat because you're talking about really something very specific. Other things that you can talk about-- I'm trying to remember the way how you had set up a communication system of using email and Gitter, and this is what Gitter is, but people weren't responding.

That was good. That was very specific. That was like, this is the way how something specifically broke down. You can talk about how things eventually got resolved would be nice, but maybe it didn't get resolved, and you can say that, too. That level of specificity was nice.

SARA VERNILLI: One more. Specifically on the slides, you talked about how you did iteration. You talked about you made changes and you stayed very generic there. I think some actual specific examples we really would like to hear. What are some things that you dropped? What are some things that you had in the beginning but you changed a whole lot? They're in your end game but we don't recognize it from the beginning game because it got changed [? in right now. ?] You don't need a whole lot of examples, just one specific ones would tie it back.

ANDREW GRANT: Yeah. So if, in that particular section, you just added, here's a specific feature that got changed in this particular way, that's great because you clearly have that information.

RICK EBERHARDT: All right. Thank you.

[APPLAUSE]

 

So thank you all. Everyone, sorry we ran a little bit late, but timing wise, everything looks like it went out. Tech wise, it looks like we've got most of our stuff figured out.

A couple points of order. This did go long. It's probably going to go about full two hours on Wednesday. Do you want to take a break midway through? Would you like an intermission midway through? I'm seeing some nods, so we're going to put an intermission midway through.

Lastly, based on the number of speakers that we've got and the topic matter that we're talking about, I think what we're going to do is start with Snap because everybody will have their computers out from the get go and then we won't need that again afterwards. Just take care of that right there. You're going to have people playing live in the audience.

Then we're going to go to Hello Wave. Basically, we're going to swap Heat Wave and Snap and Saving Gora Gora and Cholera, swap those two. And for that, because we're going to have lots of speakers at the so that will just make it so that you're doing all the moving around. Cholera Control, you're going to have two people for that, so we're going to make sure we have two microphones for all of that.

We'll have the intermission right after Heat Wave. So that's about an hour and a half, and then we'll have another hour, and then that's the end of the class on Wednesday.

ANDREW GRANT: So that's the order of presentation right there.

RICK EBERHARDT: Yeah. One, two, three, four, five. There we go. Cool. I'm trying to think if there's anything else that I should get to before we release you. No. Student evaluations, web.mit.edu/studentevaluations. I'll write up the real URL right there. Please do that in class today if you could. Thank you so much. You actually are doing a really good job. I really like these presentations. I'm really excited to see what they're going to be like on Wednesday, and I was really happy to see working games today, so aces on you for that.