Session 27: Final Presentations

• 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: So to all of our guests, thank you for coming. This is the final presentations for CMS.611 crossed listed as 6.073 the Creating Video Games class. In this class, we have 40 students, learning how to make games and learning about the production process of making games.

So a lot of the things we're talking about in class, a little bit about design, but often also about how do you communicate as a team. How do you get work done on time and on schedule, as I overheard a lot of things happening this last week.

Every year, we choose a client to make games for. This year, we were very blessed to have the Red Cross/Red Crescent Climate Centre, in Pablo Suarez. As our common client, he presented a number of different games, ideas, and topics ideas to the class. The class formed teams about those for the final projects. And that's what we're going to be seeing today.

Our order of presentations are going to be over here. So we're going to have three presentations. Each presentation is about 20 minutes plus another 10 for Q&A and then just tech switches.

We'll have the intermission after Heatwaves is finished. And then we've got two more. Cholera, I did not write down the full name for your game. Your team, Lauren. What is the full name for your game?

LAUREN: Cholera Control.

PROFESSOR: Cholera Control. Make a note of that. So they and [INAUDIBLE] will be last. I also wanted to mention to all the students here, if you're interested in continuing your education on game development, as you can see, spring is loaded with game courses. CMS.301, which is taught by Sara and Michael in the back-- hi, Michael.

MICHAEL: Hi.

PROFESSOR: It is an introduction to game design methods. In particular, it's unpacking the idea of prototyping [INAUDIBLE] for digital games. And the lessons learned there can be applied to pretty much any kind of designer, but they're focusing on game design methods.

CMS.608, Phillip and I teach, is board game and card game design. It's structured, actually, very similar to this class with a few small projects and then a final project at the end that you spend about half the semester on. And those, of course, are non-digital games, so board games, card games. We've had people do live action RPGs and tabletop RPGs, role-playing games for that class.

The next two courses, CMS.610, Art, Science, and Business Video Games, and CMS.617, Advanced Game Studio, also built on the team building aspect but not as harshly as we do. You won't be in eight-person teams, unless you really want to. Teams tend to be about four to five people for those classes, and actually as low as three in some cases for 617.

Right now in the catalog, they both look like they're being taught on Thursday. We are trying to move 617 to Tuesday. So I'll send out an announcement about that.

And then lastly, if you liked creating the specific games you made in class this semester, these kind of educational games, or do you want to know more about how games are used in education, how to make games for education and how to simulations in particular for education, CMS.590 cross-listed I think-- I didn't look up the number-- but my memory said 11.129 is Computer Games and Simulation for Investigation and Education, tion.

That is taught-- last year, it was taught by Scot Osterweil and Jason Haas with Eric Klopfer is the faculty on that course. A really great course, I highly recommend it. You can look up the syllabus in OCW if you want to know more about it. And with that, we are going to start with Snap.

TEJ CHAJED: All right, hi, everybody. I'm Tej, and I'm from the Snap team. We're going to start off with a demo of our game. So the way our game works is it's called Snap and everybody participates from their own computer.

We'll give you a topic, and then you'll enter words related to that topic. And whenever you get the same word as somebody else, you'll get a point. So it's pretty simple. So we'll invite you to join us at snapgame.org.

We'll be showing the moderator interface. So normally, you wouldn't be seeing this. The moderator would do it on their own. But we'd like to show this, because it is a part of our game.

All right, and the topic we'll be doing today, to mix it up from last time, is video games. And we'll run the game for about two minutes this time.

All right, so I have no idea how long it's been. But I'm going to give a countdown, and I'm going to stop the game. 10, 9, 8, 7, 6, 5, 4, 3, 2, 1. And that's a game.

Congratulations, Julia, and Kevin in second place. This is what you guys invented. Thank you, guys, for playing Snap. That was [INAUDIBLE].

AUDIENCE: Luigi [? book. ?]

AUDIENCE: What was that?

AUDIENCE: Luigi.

TEJ CHAJED: All right, so as you can see, this gives you an idea of what you were thinking about, what you think about when you think video games, which not surprisingly right now is Snap. And with that, we've given a feel for the moderator interface. And hopefully, you got a chance to play the game and see what the player sees. And we'll start the presentation.

So this game was made for the Red Cross. Pablo actually helped co-develop this game. And he presented it to us as a face-to-face game that they play at conferences. He provided feedback and guidance.

And in our project, in particular, the client was extremely helpful in giving us an idea of what they wanted and also helping us run the game in their actual settings. So we were able to see what this looks like with the players that we expect to play with.

For our organization of our project, we split up into backend and frontend teams. The backend worked on both the server and also the moderator interface you saw here and to word cloud, for example.

This split was challenging for new features, especially, because features would be interdependent or frontend couldn't do anything until there was a backend. And there was a communication gap throughout. When we needed to add a new feature, the API between the backend and frontend wasn't necessarily well-documented.

But overall, we think that it led to simpler management within the teams. We didn't have a lot of organization within each team. There wasn't a lot of explicit organization. But it did help to know that a smaller set of people would be working on the frontend or the backend at any given time.

In the future, I think we would have gone even more specific in our roles. Like a few roles that we thought would have been important include a UI designer. This would have made sure that UI design saw some first class love from the beginning and would have made sure that we actually focused on UI from the beginning.

It also would have helped to have somebody communicating between the teams. This person may have done some documentation or may have simply just made sure that the frontend knew what the backend was working on and the backend knew what the frontend needed, so we could prioritize well between the teams.

It also would have helped to have somebody dedicated to paperwork. This would have helped both in submitting class paperwork and also just doing the documentation that we needed, both for ourselves and the class.

And finally, somebody working on game design would have helped us develop more iterations early on and think more about the game aspects that go beyond what we already knew the game would look like based on the game of Snap we played from the clients.

As far as technology for our organization, we used Asana to organize our tasks. Asana worked really well for us. In particular, it let us split the task lists for the frontend and backend. This was useful, because generally, the frontend didn't need to touch the backend tasks and vice versa.

But on the other hand, we had a hard time encoding task dependencies. This was particularly a problem for a feature that crossed both the backend and frontend, where some API was needed on the backend and then was also needed on the frontend. And you couldn't do one without the other.

We also had trouble with task creation. And this basically meant that people didn't create tasks. And part of this was that we didn't have a specific role for creating the tasks. And so, because of the diffusion of responsibility, nobody would go through and list out everything that needed to be done.

To improve that in the future, we'd like to get people more invested. Part of this was that people had a lot of other classes. And it would have helped if people both explicitly said how much they were going to commit to the class and also we made it easier for people to contribute with the small amount of time that they had available.

SABRINA DRAMMIS: So for communication, our group used an instant messaging application called Slack. And this was really great for us, because it allowed us to separate into different channels. As you see here, we have frontend and backend as two different channels and then a general channel where everyone can communicate.

And this let the frontend people work on their thing separately from the backend, not needing to know exactly what was going on. But they could go look, if they needed to reference some conversation there. The bad part about this was that people weren't always online and responsive right away.

And I think we could of made this not a problem, if we required everyone in our project to download the mobile application. That way, they would get a notification immediately when they were mentioned. And they would be more likely to respond quicker.

TEJ CHAJED: On the backend, generally things went really well. Our technology, in particular, worked really well for us. We used node.js for the server, and socket.io for two-way communication with the browser, and Heroku to do deployment.

We were explicitly forbidden from using networking in this class, which we violated from the beginning. But I think that our experience with networking and all three of these technologies really helped make that possible. We already knew how to use them. And that helped us both debug issues and understand what we were working with.

On the other hand, the backend it seemed had too much manpower. This manifested itself as a problem on the frontend, where sometimes we felt like we didn't have enough people. We could have had fewer people working on the backend, which would have made sure that it was a small unified code base, and we could quickly finalize the backend and just move on.

We actually deployed the application, and the client has been using what we showed. This is actually a quite early deployment on November 18 in Berlin with some students there. And you can see the words that they generated.

Here are some other deployments. One of the things that made this class-- what was challenging for us is that we had to manage both client expectations and the course expectations.

So because they were asking us to do these runs, it seemed important to us to support these runs. And it was hard to balance doing this and also during the tasks that the course required of us and needed for us to do.

SABRINA DRAMMIS: So I'm going to talk a little bit about our frontend design and that process. So initially, when we started the project, we had this idea that people would be represented as a car and they would be racing other players. So we thought it would be a great idea to use Phaser, which is a sprite-based game framework.

But as you see here, we didn't go through with the car idea. And we had no sprites. But we still used Phaser to make this, our first design iteration. And we realized we didn't really want that type of look for our game. We needed something more professional and more abstract that could be used in any sort of setting that Pablo, our client, may use it.

So we completely scrapped Phaser. And we redid our frontend design, deciding to just use Bootstrap and CoffeeScript. And this was our second design.

As you can see here, it's just very typical Bootstrap styling, if you've ever used Bootstrap before. So we tried to add a little bit of flavor. And we also needed a better way to kind of represent how the game is progressing to the player. We currently had no idea for that in this design.

So then we came up with the final design that you guys played, our theme of having blue. And then we created this visualization to the right, where each player is represented by a dot. And snaps are represented by lines being drawn to dots. And your height is representative of your score in relation to all the other players.

So how we kind of got to this final visualization idea was an interesting process. First, we thought it'd be really cool to have a word cloud on the frontend, as well as the back end. But a player would only be able to see the words that they had submitted. All the other words would be blurred out.

But this didn't really convey to the player where they were in relation to all the other players. So there wasn't any sort of competitiveness. So we came up with this idea of having a race line, where all the players would be on the line and the height would represent their score and their position.

And then we thought, well, we can put these both together. But we investigated the word cloud. And we realized it'd be extremely difficult to blur out these words. And it wasn't really going to be the best use of our time.

So then we came up with this idea of using dots to represent players. And we thought it'd be cool if the size of your dot represented your score. But the use case for our application could involve 100 players or even more.

So a lot of growing large dots could really clutter our UI, so we needed to rethink this. And this is when we finally ended up deciding on height representing score.

So I think we had really good UI designers. And they were really quick. Once we thought of ideas, we were quick being able to implement it. But the bad part was that we were really late in coming up with design decisions.

We didn't start thinking about how we wanted to convey the game to the player and how we wanted to make the player feel about the game until really late in the project. We focused more on what the client needed as far as mechanics and not really what the player was getting out of the game.

So in the future, definitely we need to think about design right from the get-go. And we need to start prototyping all the ideas that we have and testing them out more thoroughly.

TEJ CHAJED: So in summary, the high points of our project are that we did make the client happy. And they've been using our application and the game. And they really like the game.

We're glad that we focused on fun. The game has been fun throughout. And players seem to really enjoy it. And I think maybe this is just because of the core concept. And we're glad that, even though this is an educational game, it is intended for purposes honestly of data collection, people really enjoy playing it.

Unfortunately, we had slow design iteration. This prevented us from really fully realizing all the ideas that we had and figuring out which one would be best for players. In the future, we'd like to get people more invested to try to solve these issues and make sure that we best use our time and create the best product possible. And with that, we'll take questions.

AUDIENCE: [INAUDIBLE] Is there a maximum number of players?

TEJ CHAJED: We did some stress tests to see how much the backend on Heroku could support. And that seemed to work OK up to 150 players or teams. We are not really sure what the frontend might look like at 150 real players. That might be actually the limiting factor.

AUDIENCE: Is that 150 people playing the same session or in the multiple sessions 150 people?

TEJ CHAJED: We currently don't support multiple sessions. This is actually a request that the client repeatedly gave us. But we thought that it was just much simpler to avoid that for now, because it wasn't strictly necessary.

Most likely, the load on the backend would be the same, whether they were split into multiple sessions. But this is a solvable problem by getting a beefier backend.

AUDIENCE: I see. But right now, the backend supports 150 people logged in simultaneously.

TEJ CHAJED: About 150. We can obviously pay money to get better servers and then run with many more.

AUDIENCE: OK.

TEJ CHAJED: Any questions from the audience?

AUDIENCE: So you got some feedback from Pablo specifically from the moderator point of view. And I'm wondering whether you got any indication about what the players felt outside of this class plus your [INAUDIBLE]

TEJ CHAJED: Sure, I think we can both talk about our focus tests, where we played with players outside this class.

SABRINA DRAMMIS: Yeah, so one of the main things, I played with maybe a group of at most 10 people. And they knew each other, so they wanted to know who they were snapping with. And they wanted to see the names of all the dots, so they could know who they were beating or who they needed to catch up to.

But this would be unreasonable in a large environment, especially when all the people at the conference probably don't know each other. But I think that would be a really cool thing to do, if we continued working on this in the future.

TEJ CHAJED: And I also ran a similar test with people that knew each other. And they actually used it as part of their strategy. They knew what other players would be submitting for that topic. And they could use that to their advantage.

So, for example, we did a topic of systems papers. And we had a professor in the group, so his paper showed up a bunch. And I would echo what Sabrina said, that players really wanted more feedback around the actual players in the game, which we specifically didn't do, because the client didn't care. And in conferences, people don't generally know each other.

But I think that if we were to use this as a more popular game, then definitely focusing on players and getting more feedback, especially after the game is over. People wanted to know who they were snapping with. They wanted to see that graph, all those lines overlaid, so they could see who they were snapping with most often.

AUDIENCE: Does the team have any plans for this game after this class? I was wondering if you've ever had discussions yet.

TEJ CHAJED: I think we haven't discussed that yet. But I think definitely we're interested in it.

AUDIENCE: Thank you.

TEJ CHAJED: Thank you.

MATT: Hello. We are Hello waves. We're game about forecasting, specifically this idea called forecast-based financing of using forecast to make decisions about possible disasters in the future and how to prepare for them. We would actually like to start with a playthrough of our game. So if anybody would like to be a volunteer to try it out.

AUDIENCE: A guest from not our class, if one could please come down, Andrew.

AUDIENCE: Thank you for volunteering.

ANDREW: Hi, I'm Andrew.

AUDIENCE: Well, do you need a chair?

AUDIENCE: Here's one.

MATT: I'm not quite sure how to make that full screen. But anyways, this is our game. I'd recommend looking at the instructions first and reading through them. Thanks. And we'll keep the description minimal as you read through it just to sort of show the player's initial reaction to it.

ANDREW: Now, this is real, correct?

NORMAN: You're signed on?

MATT: Oh, is it? Oh.

NORMAN: Yeah, right. OK, sorry. Music.

MATT: Yeah, start up again. So as you can see, our game, as I said before, you control some toys on a day at the beach. And so by dragging and dropping them between the castles, you'll see that their statuses change and say that they want to move on their next turn, or that they want to be collecting-- or that they're going to be collecting candy, or anything like that.

And the game is turned based. So all the actions will resolve on the next turn.

ANDREW: Am I rating this race?

MATT: Yeah.

NORMAN: You can also access the help through the lower right corner as well.

MATT: And so when you go to the next turn, you'll see all the toys move as specified by the status bubble above their heads.

ANDREW: So I go to the next turn, or do I get a next turn?

MATT: But unfortunately, you'll find that when toys have been evacuated, they're unhappy and need candy to survive, so they'll all take damage.

ANDREW: They don't want you to evacuate.

MATT: You can try returning them to their homes.

NORMAN: And so you'll see that on this turn instead, now they have their statuses set to gathering candy, except for the dump truck, who is still evacuated.

ANDREW: Got you, OK. But he needs to be evacuated.

NORMAN: Exactly. And so the idea is that as a player plays through it, they get better at understanding how to use the forecast to make decisions about the future, both in terms of how much candy that they need to have stocked up in order to weather out the rising tides and also in terms of when they're going to need to move their workers out of-- their toys out of the areas that are in danger.

ANDREW: They're going to be really impacted.

MATT: I think you have those two guys.

ANDREW: Oh, they're in there? Is there a reminder of where they started?

MATT: Yeah, it's on the castle. It's actually blocked out right now, but toward the front of it. But there's a little shadow there, an imprint. Because he ran out of candy and then-- or actually, sorry, because he went to a place that was underwater, he took too much damage and then was swept away by the waves.

And so on the forecast, you can see that high water is coming for quite a while, which is going to be a danger for the toys, both in terms of possibly getting swept away and not having enough candy for all the toys that you're going to have to move out of the way.

ANDREW: [INAUDIBLE] this time.

NORMAN: Oh, he may be out of luck.

MATT: Yeah. And when you've lost two toys, you lose the game.

ANDREW: OK.

MATT: Thank you for playing. So that's Hello waves. So in our game, we had a few challenges to overcome. The first was that our game was based on forecast-based financing, which is a very abstract topic.

It's a pretty understandable idea of using information about the future and ideas of risk in order to decide where to allocate resources. But it's still a bit abstract. And building a game around it took a little bit of work.

It's useful to note that it's different than long-term planning. It's not just thinking about what will happen in the future, building a dam to prevent water or things like that. And it's actually about using the information you have to make the best decision for events that may be upcoming in the semi-near future.

We also wanted to avoid making a game that was overly preachy or simplified, where it was clear exactly how you're going to win. And you could just basically push the forecast-based financing button to win the game. We wanted players to actually think and understand the concepts there, instead of just coming up with the buzzword of forecast-based financing.

And finally, we had the challenge of actually communicating that forecast to players in a way that they would be able to understand and then make use of. You could see in that game that we had water levels and it would show on the map. And we found that players were pretty good at using that in order to make decisions about what was going to happen in the future and how to allocate their resources.

The other big challenge that we had in the beginning was that our initial target audience was policymakers. Like for Snap, Pablo had come in and pitched us this game idea. And originally, he had wanted us to build a game for policymakers that would help them understand the benefits of forecast-based financing and, therefore, convince them that they should develop policies that would give resources to plans based on forecast-based financing.

So I would like to take you through a couple of our prototypes just to show you the evolution and comment sort of on our process. Actually, to preface that, we had a lot of prototypes, because of our idea was so abstract and because we weren't sure how to address our audience. So we built a lot of prototypes to start with.

We had ideas that ranged across sort of levels of scope of what you controlled, where you controlled entire cities or where you controlled individual workers and moved them around.

And then we would pull from all these different kinds of ideas what worked, what didn't, what did people understand, what confused them. And from that, we got a really good idea of what concepts helped people understand the idea and brought them into this final game that we ended up with.

So the project started on October 15. And this was our first prototype. It was a terminal-based game, where you had some kind of information about a future rainfall. And then you had to type in your commands of how you controlled different cities.

This, actually, people found it fun. But as you might expect, the feedback wasn't very good. And people didn't quite understand how to move forward with it. It put a lot of cognitive load on people.

So when we moved forward, we tried to give people more easily understandable actions to use. But the problem with this game was that it was time based and it updated every second. And so there are so numbers flying at people, like even MIT students who play tested it couldn't understand.

So we figured that people like policymakers, who didn't have much experience with games, really wouldn't be able to understand the game at all. So instead, we went to turn based. And that helped. But at the same time, it's tough to see on this projector, but we have a forecast underneath that says how much rainfall is expected.

And again, that wasn't understandable to people, because they couldn't understand what three inches of rainfall meant for their city. And they couldn't understand how that contributed to a possible disaster.

At this point, Pablo actually came by the class and played the game. And then he told us that he wasn't even sure that he could get policymakers to play the game, because they may not have enough time. Instead, he wanted us to switch to grade schoolers, because we could teach them something about forecast-based financing and help them understand as they grew up.

And this was great for us, because making a game that was serious, easy for somebody who didn't have experience with games to play, and also fun and engaging was too difficult for us actually. So moving to grade schoolers was awesome. He also suggested that we try to make the idea of rainfall or water levels more visceral. And that's when we came upon this idea of the rising waters.

Whenever players looked at this, they instantly understood the concept of the game. The feedback might not be there. The beautiful UI might not be there. But the idea of having cities with workers in them and a rising water level coming towards them, everybody understood that. And it made it a lot easier for players to reason about the game.

From there, we added things like nicer art, better feedback, which you can't quite see in the static picture, more improvements to how the forecast worked. And eventually, we ended up with our final version today.

NORMAN: So to talk a little bit about our actual development process, so our team was structured into three main subteams, production, which was in charge of managerial roles, deliverables, and play testing, and so there was a shared responsibility there; technical team, which was in charge of the bulk of the coding work; and a user experience team, which would be in charge of assets, UI design, and UI design.

We also initially envisioned subteam leaders, where we'd be kind of communicating through them. But we found the concept kind of redundant. And so we've worked pretty much with like a flat structure between the three teams.

So from the beginning, we encouraged good coding practice. And so we used good tools available to us. One of these is Yeoman, which is a JavaScript scaffolding framework. And this helped us out a lot by basically automating a lot of our JavaScript tasks and making our code modular.

We also used Phaser state machine, which is this kind of badly documented new feature in the Phaser game engine, which was the JavaScript game engine that we used. It's a bit badly documented. But it did save us a lot of headaches. And once we figured that out, that proved immensely helpful.

And we also used MVC, which is a computer software engineering term standing for Model View Controller. And again, by encouraging these good coding practices, we reduced dependencies and made sure that our team was productive.

In terms of communication, we also, similar to Snap, used Slack, which is kind of like a modernized chatrooms. It's very feature rich. And so you can share files, channels, and things like that.

And we also use the idea of the Daily Scrum. We implemented it in class. And we would say what we had done that class, what we would be doing, and what we wanted to do until next class.

And so now, the major challenges that we faced during the development process though where that our team members came from very different backgrounds and had very different preferences about games. Some of our team members are very hardcore StarCraft players and very good at RTS games, while other members of our team preferred like a more laid back mobile game Fruit Ninja kind of approach.

And so trying to mediate those two viewpoints and trying to create a game that would engage both types of gamers was a challenge that we had to overcome. And so another big challenge that we had in our development process, as you saw through our progression through our different prototypes, was that our direction was not very clear, until about halfway through the project.

And so partially because we had different ideas on what the game should look like and also partially because we had such an abstract idea of forecast-based financing that even we didn't have that good of a grasp on initially, it took us a while to really get settled on what we wanted to build.

And so this really challenged our development process and made us have to build a lot before we got something that we liked. And so eventually, we did end up having to cut some features of like multiple levels or like a guided tutorial for the player.

We thought that this would introduce too much new content that would need to be play tested, balanced, and tested to ensure consistency with the rest of our game, which we viewed as taking up too much time. And we also cut the idea of adding more individuality to the workers or to the toys that you saw, other than different graphics for each.

MATT: Some of the worst things that we did on our team is that we spent a lot of time on work that got thrown out entirely. All the prototypes we did, they were actually pretty useful, because of the things we learned about the concept and about how people would play the game.

But we did spend a lot of time on things like art or nitty gritty details that didn't really need to be figured out and that we could have put off until later in the project. We also kept the game direction too vague for too long. As Norman said, we spent a lot of time with that. And it probably ate up too much of our time.

Although it helped us learn, we could have moved faster in the beginning to get to a solid idea. Because once we got to a solid idea of the rising waters, our team started to centralize around it a lot better, because we could actually deal with something concrete. While we were dealing with the abstract ideas, everybody was all over the place and arguing about things that didn't quite line up.

And the worst decision of all that we started with and that sort of made the problem of going too vague and all these other things happen is that we were originally thinking, how do we skin forecast based financing as a game? How do we take this idea of using forecast to make decisions and then just gamify it, which we eventually realized wasn't fun and didn't help us actually come up with any ideas.

Instead when we flipped it and started talking about what game could we create and use forecast-based financing to improve it and teach players how to play the game and, therefore, allow them to come out of the game, having learned about forecast-based financing, the world sort of opened up. Everything became a lot more interesting. And we found that we started to move faster.

Some of the best decisions that we made, on the other hand, as Norman said, we had good tools, which meant that even when we threw out prototypes, although we wasted things like art resources and things like that, we actually didn't end up wasting very much code, because things like the idea of workers or cities could literally be pulled out of the old games we had, put into our new game, and then reworked to build our new structure.

We also weren't afraid to trust each other and throw out the things that didn't work. Once we started moving fast, we had a lot of ideas that would come out, and we would say, OK, this doesn't work. We're actually going to scrap it. Or we think that this isn't the direction we need to go in. And everybody was willing to go along with it.

It's not a good feeling to see your things thrown out. But everybody understood that was for the best of the game. And I really appreciate their understanding with everything too.

And part of that all comes down to the fact that we were on board with our final idea. We were all excited about the concept that we had. Part of that might have been the relief of coming to a concrete idea after spending so much time being vague. But once we had the concrete idea, we really moved fast and worked well around it. So thank you and any questions.

AUDIENCE: Who did your sound? It's awesome.

MATT: That was from our UI team.

AUDIENCE: Oh, [INAUDIBLE]. OK, I really liked it.

MATT: Thank you.

AUDIENCE: Where did you find it?

NORMAN: So it's on our credits page. Most of it was online. The credits page in our game.

AUDIENCE: And so you don't want to type it in.

MATT: It's a little small, I guess, up here.

AUDIENCE: Oh, OK, great.

MATT: But it looks--

AUDIENCE: [? Switch games. ?]

NORMAN: Yeah, "Hold My Hand," AGP by--

AUDIENCE: Would it be possible to do a [? shortened ?] URL of these?

MATT: For the game? Oh, yeah, sure. We can make a Bitly link, and we'll send it out to everyone.

AUDIENCE: Yeah, just to entire-- yeah.

MATT: That's a good call. Yes.

AUDIENCE: Having watched the early crash and burn playthrough, how often do people-- I don't know if you've actually had a lot of people to play your current version of your game. Do people usually take a playthrough or two before they start getting the concept?

MATT: Yes. That's why something like a tutorial would be really nice. Unfortunately, we didn't have the time to put it in.

AUDIENCE: Yeah, no. I was wondering how that-- OK.

MATT: Yeah, usually what happens is, even if after maybe a couple of turns of playing through they start to get the idea, the problem is that, as the water starts to rise, they haven't prepared enough. And so all their workers or the toys will starve or get carried away by the waves, which is a bit unfortunate and probably makes the players feel bad on the first time.

But then they-- it actually teaches them to think ahead about it. So the next playthrough, they're much more careful and understanding.

AUDIENCE: Yes, I was wondering if you were playing any other games or thinking about other games as the inspiration or thinking about how to deal with sort of getting the right level of strategic thinking in your game.

NORMAN: Well, so I guess in terms of early on. Because we had a very different idea of what we wanted to do early on in the process, we were thinking about games like Civilization and how did they communicate all these complex worker movements and managing multiple cities. But once we actually came up with this game concept, I think we had much, much smaller goals. And so did we have any specific game models, do you think?

MATT: There is none that I specifically think of. There were some things that we were sort of inspired by, standard tricks, like when you hover over one of the characters, they got bigger, some idea of showing off that this is clickable, things like that. But specific games themselves, not really.

AUDIENCE: I was just thinking it ended up being kind of war gamey. And I feel like there's a lot of war games that where I'd thinking a lot about getting that right level of I guess tactics rather than strategy. But, yeah, I guess it worked out kind of.

AUDIENCE: So you mentioned that you were able to completely change how your workers looked and just keep your models. So that's sort of the Holy Grail of object-oriented programming, that kind of object that's reusable and you don't have to throw out the code. Do you think there's a reason why, in particular, you were able to achieve that, because I think that's not-- that's not common necessarily in object-oriented programming?

NORMAN: Partially, a little bit of OCD-ness like very early on, very strictly saying we're going to write this object-oriented code, and we're not just going to hack things together. I think that helped a lot, because we actually spent the time in the very beginning to think about like which objects were responsible for what and what their purpose should be.

Yeah, basically, I think because we moved more slowly in the start and thought more carefully about how that code should be structured, we ended up with having an easier time later on.

MATT: There's also the fact that because we had learned these things from the prototype that we are putting into this game, that also meant that the objects that we created because we wanted similar functionality to things that we had already seen and we knew worked, it meant that we were comfortable pulling out the functionality into that.

I don't want to say it was designed to fit. But there is the fact that we moved it on purpose, really.

AUDIENCE: I would like to say something on it. So we had a very good MVC model. So models were at and has a tree-like structure, I think it was very easy to change the model somewhere else [? and knew it ?] involved-- sorry, used our new evolved models once [? models and no idea ?] of what happens. So basically, it was [INAUDIBLE] change.

AUDIENCE: Thank you. All right, thank you.

MIRIAM: Hello, my name is Miriam. And today, I'm going to be presenting for Team Heat Wave. And we made a game called Heat Wave. So the goal of Heat Wave was and is to educate Red Cross workers about how to prepare for and handle heat waves.

And if you've never been through a heat wave, it's just defined as elevated temperatures for an extended period of time. And the way you prepare for that is you set up umbrellas for shade. You get water coolers. And during the actual event, you try to go inside and drink an excess amount of water.

So while we had that game goal, we also had design goals of usability, playability, and education-- usability because if the game doesn't open, it doesn't turn on, that's a problem, it doesn't work, playability because we wanted people to be able to play through the whole game, it's just very fundamental, and education because this game is meant to educate Red Cross workers about how to deal with heat waves. So we really wanted that to be one of our primary objectives for the game.

So to meet these goals, we had our design processes. And I'll talk a little bit about each of these in detail in a minute. But we started off just as the other teams did with brainstorming. Then we formed a team based off of our ideas.

And then we broke down responsibility. So one person was in charge of one aspect of the game. Another was in charge of like the graphics, all separate tasks.

And then we continuously updated. And what we used for that was Trello, primarily. And I'll talk more about that in a minute.

So brainstorming, we were actually right there on the board drawing things for a while. And we had two major ideas going as a group of people just considering this topic. The two ideas we had were the game we actually came up with, where you play as a Red Cross worker trying to help people. And then our second game was playing as a heat wave, trying to make people faint.

And while that actually sounds like a lot of fun, we stuck with the first idea. And the reason we did that is we thought we could get more education into the game. Because education was such a primary focus for us, we really wanted it to be the core basis of the game. So we went with the game that would directly correlate to what these Red Cross workers would be doing out in the streets before and during a heat wave.

And based off of that idea, we formed a team. We actually had a pretty large team. This is eight out of nine of our people. Joe wasn't in this photo, because he wasn't there that day.

But we had a really large team. So we had to be really focused as to like who was doing what and what was getting done when. Because when you have such a large team, things can slip through the cracks.

So we used Scrum. And as you can see up there, it says so many emails, because there were so many emails. But the way we dealt with that based off of previous projects was to say, well, we're going to have a lot of emails. There's nothing we can do about that. But we can make the emails relevant, so we can break them into different threads.

So the people who were handling the character objects, they're just going to have their own thread. And maybe like one person who's communicating between teams will also be on that thread. But it's really their thread. So we had a lot of emails. But they were divided up as to who got to see them and who it affected.

And the other thing we did is we had our Trello. And we constantly updated that. And we kept track of what was being done in this sprint and previous sprints. And it was really easy to see what was taking longer than we expected and what was done, what was done but could use improvements. Like you could make a note. We had like a not-done-yet section. So we really managed to stay organized that way.

And the other thing we did to make sure things got done was group meetings. And these were quintessential for our groups. We had a bunch of like three-hour long meetings. And we would get task after task done, bug after bug fixed, and really just worked through for hours on end.

So once we had this game and we were all working on it, we had four focus tests that we ran. And they all had a theme. So our first focus test was about the concept, can we educate people in the basic mechanic of that we think we're going to use. And I'll talk about that in a minute.

The second one was overarching issues. So I said our three design goals were usability, playability, and education. So that was really our second focus assessed.

The third focus test was visuals. Are we connecting with the user? Are these the visuals we want to have?

And then for the fourth one was game balancing. Does this game feel fun to play? Is it working out?

So the first focus test, we focused on the general mechanics. We had a low fidelity prototype, which is actually a Python-based game. And there was a list of people. And you could say, I want to talk to this person based on some attributes and offer them water, tell them to go inside.

And each turn, you could either continue talking to them, say forget it, you're being annoying, or oh, you accepted water, I'm going to move on to the next person. Or you could do nothing. And what we learned very quickly was that it was working.

People were choosing to try and help people based on their characteristics and based on oh, well, this person fainted really quickly, and they were homeless, so I think homeless people might faint faster. Though actually, I don't think homeless people were in this game.

And we also experimented with different types of dialogues. So we experimented with having like very factual dialogue, drinking water is really important, even if you're not too thirsty versus something like, hide your wife, hide your kids heat wave.

So once we had that general concept in place, we built a basic unit game. And we wanted to see overarching issues. So we had these four-- well five, but one person has already fainted in this picture-- five different characters with different attributes. And you could choose to talk to them.

It was the same exact concept we had in the Python text-based game. This time, it was a little more visual. There were people and there was a dialogue that would show up. But it wasn't fully there yet.

And what we saw was the usability and the playability were definitely having issues here. You can see that. But the education was definitely coming through it. In fact, people wanted it to be more visual.

And we saw that, and we said, well, we have to test more visuals. So you can see, this was the version we tested later. And we said, how is this working, who are you choosing to click on? And people said, well, first of all, it's confusing.

All these people look the same. I can kind of tell who's a woman and who might be a man, but that's about it. The labels aren't moving with the people. Even if they were moving with the people, they're really too small. We can't tell who's who.

And we said, well, we have this art that we think we're going to redo all the art in the style of. We're thinking about getting rid of the labels. Do you think that's a good idea? And they said, yes, get rid of the labels. They're too small anyway.

And so we showed them this caricature of one of the types of the characters, which is a homeless person. They're a very vulnerable group to heat waves. We said, this is kind of the art style we were looking at. We think it displays more information. Do you think that's good?

And we got enormously positive feedback on that. They say, definitely, I would click on this guy, because he looks like he needs help. And you'll see that later.

Something else we were having an issue with visually was that the way people would go inside is they would just kind of wander out. But the way they fainted, they would actually just disappear, proof. So people didn't notice it actually. And then they'd suddenly be like, well, there was 10 people, and now there's five people, and what happened?

So we said, OK, we know this is an issue. What do you think would be the best way to visually show that people are fainting and that would emotionally resonate with you? And they said, well, we want them to fall over.

And maybe it'd be nice if there were some other feedback, like sound or something. And we said, OK, we'll take that a step farther. And we did. And we'll talk about that later.

And the third thing that we really got back from this visual feedback focus test was that there was no indication when people were getting sick. So in the real world, if you're getting sick, you might like turned red, get really sweaty. If you're about to faint, it'll be very obvious is the point.

And there was no indication here. So we said, well, we're going to do something about it. We're going to put that on the back burner, keep thinking about it. And we are going to fix that somehow. And so we put that all into practice.

And you'll see the screens in a bit. But our final focus test, we focused on game balancing. Is this game balanced? Are people fainting at a reasonable rate? The problem was that we would have like six people all fainting at the same time.

They said no, they have to faint at different increments. And also on top of that, we had an issue where the temperature was somewhat random, going up and down. And people were not adjusting to that.

One day it was 110. The next day was 80. And that's in Fahrenheit, because I assume most of you use Fahrenheit typically. But our game is actually in Celsius now.

But the idea was that people were not adjusting to this change. And it wasn't realistic. So what we do now is we actually ramp up the temperature, and so that the first day, very few if any people faint.

And then the next day, by the end of day, people start fainting, because it's getting hot. And then the third day, they're fainting faster. And you'll see that in the playthrough after this.

So during this whole process, we made some good and bad choices. And I'd like to talk about bad choices first. So we made two major-- these were the two, I think, biggest bad choices we made. They're not completely horrible or anything.

The first was that we depended on external code. And the second is we focused on education, not fun. So when I mentioned the external code, one of our teammates had a dialogue system for unity, which is really cool, it looked really nice, had lot of features. And we said, let's go for it. We can use this as a foundation to build a really complex game.

And something we really didn't stop to think about was how much work is it going to be to develop our game around this system? How much work is it going to be to change the system to fit our game? And also are we going to have time to do all of that and also focus on making the game complete as a whole, instead of just kind of showcasing this one aspect.

And it turns out it was a bit of a pitfall for us, because we didn't expect it to take as much time as it did. And if we were to go back, the teams kind of said, well, maybe we still do this and we just deal with the issues early on. But also, maybe we should have just designed a simpler game and not use this external code.

Another bad choice we made was we really did focus on education, which was good, because our game does teach people. But it is an educational game in the sense that it's not the most fun in the world. And if we were to redo this, we probably should have focused on fun earlier.

We played with having funny dialogue and making more emotionally resonating effects. But at the end of the day, it's an educational game. And it's really not that exciting to play. So that's something.

But in the process of doing that, we made some good choices too. And one of those good choices we made was group meetings. You get so much done when you sit down with like most of your team for three hours and you just hammer through. And we did that multiple times. And it really worked out for us.

Something else we did well was prioritize. Because we had a team of nine people, we really had-- availability was kind of all over the place. And even when we had group meetings, you could only really expect like six people to show up. You were guaranteed that at least three people weren't going to be there. Even if you did a doodle, which we did.

So what we prioritized was based on group-- we had groups of people with different responsibilities. But if there was a bug, we said, OK, who is available right now? What are you're working on? Is this more of a priority? Can you do this now?

And that process worked for us. We got bug after bug fixed that way when we weren't in a group meeting. And when we got to the group meeting, people generally had a sense of what was going on, because we were doing this process of they kind of had maybe worked on something for a little bit based on it being a priority.

So now, let's get to the actual game. So the game has a start screen within an instruction screen, which is kind of the sublayer. The main game, which has the day scene and then a newspaper scene at the night, and I'll show you all these. And then the end screen.

So originally, this was what our start screen looked at that we play tested. And it was beautiful, as you can see up there. No need for changes, right?

So we actually did change it. And so now, it's the same background as a game for Cohesion. You have your play, but you can also use the instructions, which are pretty useful if you've never played before.

And then that takes you to our main game. Our main game originally, you saw that on the first focus test. I think this is pretty similar to our second focus test.

You see we had a progression with the main game. It took a lot of iteration. And something originally we didn't have, I said, was there was no indication of when somebody was getting sick or their characteristics. It was a lot of issues.

So we made some progress. We added the indicator that say, I'm about to faint. You should probably try to help me now, which is that little explanation part on part of their head.

And then finally, we redid pretty much all of the graphics. And that took a while. So we were in the process of redoing them at this point. And now, the game looks like this.

So it's much more cohesive. All the art fits together. The people are really visually caricatures of the different types of people you need to help.

Elderly people, homeless people, drunk people are all really vulnerable to heat waves. And then there's some characters that actually aren't on this screen right here but that aren't as vulnerable, like normal, like adults aren't as vulnerable. And athletes aren't as vulnerable.

So at the end of each day, when you play this through, and you've helped your people, and you've given them water or set up coolers or whatever you wanted to do for the day, you get to a newspaper scene. And the original newspaper scene looked like this, a lot of text. It doesn't really help you with much.

No one really cared much about it in the first iterations of the game, because the long-term objects hadn't been adding yet. So it's just the umbrellas and the water coolers. And so we changed it to look like this.

It's the same information, just a little better organized. And the other thing that we added in the main game, we added those buttons that says, you can set up a water cooler or an umbrella. And that takes your time up.

So if it's cool outside, maybe you do that. But if it's like 110 degrees in Fahrenheit, then maybe you should focus on helping people not faint. So we had that.

And then say you finish, 20 people faint or whatever-- I think it's 20 people faint-- and you get to the end screen. And our original game, we had no end screen. And the reason for that was, I told you we really focused on education not fun. And we just didn't think, part of the fun of a game is seeing how long you survive. But we just weren't thinking about that.

So we really reevaluated that. And we said, OK, we definitely need an end screen. And we have it looking like this. So it tells you how long you lasted.

And then you can see the credits for what was involved in the game. And you can play it again. So there's more feedback for the user of how they did.

And if we were going to do this project again, there's two things I think we'd do majorly differently. And the first is talking about heat waves. Our group thought heat waves were going to be really cool. We were like, oh, people are fainting everywhere, and it's getting hot, and we have to do something.

And then you start reading about heat waves. And basically, it gets hot. You tell people to go inside or drink water. And that's about it. That's all a heat wave is.

And so what we'd do differently is really the passion aspect. If we're going to do a game about heat waves, we depended kind of on our passion coming from the thinking heat waves were cool. I think we should have focused more on having passion for the game and then incorporating the-- well, also having the game build around heat waves but really having a more exciting game that we could somehow also get that educational aspect in.

What wed also do differently is accountability. I said we had nine people. Sometimes, people disappear when you have that many people. And keeping dibs on everything, especially when you have separate email threads, can be a little confusing. So maybe look into some of the tools that the other teams mentioned, where you have multiple group chats and you can see them all. That looks really interesting.

Future features, more long-term options. I think that's one of the things in our game that really helps with the planning aspect is OK, do I want to be doing this, like helping somebody now? Or do I wanting to be installing an object now?

And really, our game kind of depends on that balance of choosing who to help and then also what to do. Am I helping or not? So more long term options.

And then something we originally conceived was to have multiple environments. And we didn't have time to implement this. But in different environments, you do slightly different things. Like if you're in an office, you might want to install an AC unit, which is different than what you'd do outside.

So really look into multiple environments. Different countries have different environments, might have slightly different strategies for what to do. And we really would like to look into that.

So before we play the game, do you guys have any questions? In that case, I'd like a user tester.

AUDIENCE: So someone who hasn't played the game before, again one of our guests. Alex?

AUDIENCE: Sure.

AUDIENCE: Thank you.

MIRIAM: It's not showing up there. Give me a second. Display. You're going to have to give me a minute. I didn't realize it wouldn't show up.

AUDIENCE: Make sure that's not plugged in.

MIRIAM: Yes. I [INAUDIBLE] have it plugged in. How do I mirror the screens? Sorry, it just-- otherwise, he's going to have to stare up there. Oh, thank you. Don't look at my emails. There's so many of them. OK, yeah.

AUDIENCE: Are we good?

MIRIAM: Yeah, go for it. My sound is on silent. There.

AUDIENCE: All right? Let's see, solo, go [? to tech ?] the instructions so thanks for [INAUDIBLE]. All right.

Let me read through the instructions. It's going to offer homeless people water, tell old people to go inside, install umbrellas, or many other options. OK, so pause, click on Pause button. OK. [INAUDIBLE] whoop.

MIRIAM: Sorry, what just happened?

AUDIENCE: I may have clicked that actually.

MIRIAM: Oh, did you start the game? Here, we'll just quit. No worries. Great.

AUDIENCE: OK, thanks. OK, I think we're ready now. Let's play. I'm going for the umbrellas. OK. Yeah. All right.

Wow, that's nice. Does it get darker as it goes through? Cool. Whoop, uh-oh. Wake up. Hey, OK. Should I do it around here?

MIRIAM: Yeah, sorry. Go through again. Try talking to someone.

AUDIENCE: All right. Is it--

MIRIAM: No, it's something long.

AUDIENCE: Oh, OK. No worries.

MIRIAM: All right, that's good. Thank you.

AUDIENCE: Maybe, just start the game over.

MIRIAM: Yeah, should I just-- yeah. It was working. OK, let me refresh the page. There.

AUDIENCE: Oh, there you go.

MIRIAM: I don't know what happened. Sorry about that.

AUDIENCE: No worries. Oh, I see, you can give them options to do. Oh, OK, that changes it just a little, yeah.

MIRIAM: Kind of important, just a little.

AUDIENCE: All right. Oh, OK. Let's see, I'll talk to her. Uh-oh. Oh no.

AUDIENCE: I actually caught the rest of the game.

AUDIENCE: Thank you. Any last questions for the group?

AUDIENCE: I liked the bird sounds and also the fire sounds. Are there other sound effects?

MIRIAM: So we had music. But it was really hard to find good music for a heat wave, because you think it sounds hot and you don't really think of anything. So we had this very eerie music, which didn't really fit either. So we went for the minimalistic bird sounds, because we thought it was the only thing that kind of fit.

Is there any other sounds? No. Yeah, we had other sounds. Just they sounded wrong.

We had fire sounds, like in the background and that made the whole thing sound really dangerous and terrifying, which is not what we want to portray. We want to portray that you can do something and prevent anything bad from happening. And any other questions? Yes.

AUDIENCE: So a lot of things have changed in your game since Monday. A lot has changed since Monday. How did you manage the process?

MIRIAM: So we actually, we were going to have a meeting before Monday. But really, our schedules didn't work out. So we actually had, I told you, group meetings. That's where we got everything done.

We had like a three, four-hour group meeting on Monday night, which we were planning to have. And while there was like a couple core things that we wanted to fix, just like small like bugs that we were working on, and also while some people were doing that, we're just like, well, we have other people who aren't doing anything and can't really help with what's the major thing, so why don't we just like add other features, like it getting light and dark.

Because that's something we really had considered and we hadn't had time for. But in that group meeting, where somebody had time, we were able to add that. And it looks good.

AUDIENCE: How did you test it? Like, did you--

MIRIAM: Oh, so we've been running it like nonstop all of yesterday and today. But then it broke.

AUDIENCE: Yep, definitely, it happens.

MIRIAM: Yeah.

AUDIENCE: You also went from a screen that had pretty small characters on it to a screen where the characters were about 3/4 the size of the screen. How did that decision come about?

MIRIAM: So we had our drawings. And when I told you we focused tested, then we had like a big picture of them on the screen. People loved it. But when we actually put them onto the old screen, they were really small and you couldn't see their characteristics.

And we said it's better to have people overlapping more often but actually being able to see their characteristics. Because the caricatures are really where the learning comes in. Like, if you didn't notice, the people who fainted were, I think, the drunk people and an old person.

So you start to notice as you play the game, OK, homeless people faint really fast if you don't give them water. And that's just like a fact. People who are homeless typically don't have enough fluids in them. And they're also outside a lot. So it's really hot.

So that's relearning comes in. So we wanted to make those bigger. And to make them bigger, we thought, OK, we'll just put in like a simpler one-lane background. So that's where that came from.

We were planning on doing that before yesterday, I mean before Monday. But we just didn't have the assets in yet. So like a lot of things changed that were already in the works since you last saw it. Cool. Any other questions? Well, thank you so much.

LAUREN: All right, so we're Cholera Control. And we're going to talk a little bit about our game and the making of it. So firstly, Cholera Control is a game we made for the Red Cross. Our client was Pablo Sanchez, as a few others have mentioned.

And the point that we wanted to get across with our cholera game is that it is an easily preventable disease, if you just like wash your hands. It's really not that hard. But people just don't seem to do it, because there's a lot of factors going on in their life and they sort of just forget. But it's really easy to do, if you just wash your hands.

So we want to just do a quick demo of the game. Where is-- OK. So if someone would like to come down and play our game.

AUDIENCE: OK.

LAUREN: Cool.

AUDIENCE: Cholera is fun.

AUDIENCE: Not supposed to show up on our home video, so that's OK.

AUDIENCE: Are you hot?

AUDIENCE: No, I'm just kidding. I don't know.

AUDIENCE: We'll find out. Don't have any policy for that.

AUDIENCE: OK. Play a game.

LAUREN: Can you guys read that?

AUDIENCE: Yep.

LAUREN: Can anyone in the back not read it? Because, it--

STUDENT: It says cholera is spreading. You got to control it and watch out for outbreaks.

AUDIENCE: OK, I'll just-- Oh, OK. I have $1,400?

LAUREN: So as you can see, the game is kind of a strategy game. Right now, there's only one locality to deal with. We sort of didn't want to throw too much at the player at the very beginning.

So you can kind of-- also, the game is paused, so it's going to open in that corner there. And so you can have time to sort of just read, make sure you know what's going on, what all those different things do. Then you go back to the map. And time keeps elapsing.

And so over time, more localities appear, up to four. So right now, you just get the second one. They are on different branches of the river. So they're not going to really hurt each other right now, still relatively easy.

STUDENT: We go cheap.

LAUREN: Hopefully. I don't want to offend anyone, if they're like, this is really hard.

AUDIENCE: So the average [INAUDIBLE] that the infection is still growing, more so.

LAUREN: So one of the things you could see, if he goes back to the map, is all the bars above the villages, green is the healthy and red is infected. And there's an arrow, which I think is a-- you can see it pretty well on there-- the arrow, if it's pointing that way, that means that the amount of green is growing. So there's more people getting healed.

If it's pointing the other way, then more people are getting infected, which is bad. So if you see your arrow switch directions, you usually want to get on that really quickly and make sure that nobody dies-- well, no, nobody gets infected. Nobody dies in this game. We didn't want to be too harsh.

AUDIENCE: Are the products accumulated? So my like--

STUDENT: Yes, yeah, so if you buy more than one, they work together.

AUDIENCE: OK. Ew, boiling water.

STUDENT: So boiling water is special, because it helps downstream villages.

AUDIENCE: I clicked that.

STUDENT: That doesn't help.

AUDIENCE: I know. Is my budget growing?

STUDENT: Yes.

AUDIENCE: OK, oh great. Oh, crap, I didn't mean to do that.

STUDENT: You can undo.

AUDIENCE: Oh, I can?

STUDENT: Yeah, well, now you can't.

AUDIENCE: Now, I can't.

STUDENT: That one's going to-- you're [INAUDIBLE].

AUDIENCE: OK, I need to buy them boiling water, and that's it.

STUDENT: You're done.

AUDIENCE: OK.

LAUREN: Well, thank you.

STUDENT: Yep, thanks. Yeah, so if you manage to survive longer-- no offense-- you get to-- up to four villages pop up, or four localities pops up. And then it gets really hard. Cool.

Cool, so first, we're going to talk about what went right, both from the creation of the game and working as a team sort of perspective.

LAUREN: So firstly, I'll go over the iteration was a lot better on this project. In this class, we had a total of four projects. The first three were each over-- like, the first one was two weeks. Second one was two weeks. Third one was two weeks. And then this one was eight weeks.

So this time, we had a lot more time to sort of decide what we wanted to do, what we should try out, and get to sort of test each and every single one of the ideas that we had, rather than just focusing on one idea of having to do it, because you only had two weeks. The other thing is that after three projects, we finally figured out how to do design meetings really well.

We got them down to that they were only like a half hour each. And when people showed up, they were really productive. And so everyone figured out what they wanted to do. They talked about the game. It got done, and people got out of there. It was very nice.

Another thing we did right was simplifying. It was really hard to adjust scope. It was easier in the other games, because you realize you only have two weeks.

When you have eight weeks, you think you can do a lot, and you really can't. You think you have a lot of time, but classes and applying to jobs, and everything takes all of your time. And so you have to really learn to, OK, like, I only have so much time for this class. I can only do so much on this game, so I'm going to adjust the scope.

And it was really hard even when the client, when Pablo told us, you should change what you're doing, we didn't want to. We thought, no, this is a great idea. This is how it should work. But then when the client tells you do it and all your play testers say your idea is bad, you need to just give in and change.

And we ended up having really great results. With the simpler gameplay, it's a lot more fun. And the options, there are less options, but they're much more meaningful. As you could see, the player was sort of reading through each and every option. And it's because they each do something different.

Before, we had a lot more options. But they were all sort of the same. You just kind of click them, and they do something. But they're all just about the same effect.

With this, they all have different effects. So you sort of have to strategize. Do I want to spend more money for this effect? Or can I just use this cheaper effect over and over again for the same result?

STUDENT: So I'm going to talk a little bit about what changed from beginning to end. So the UI in the beginning looks much uglier. I mean, that just came with sort of refining that. I want to talk a lot about sort of the design changes that really changed.

So in our first prototype of the game, you sort of click these buttons here on the right. And that would give you the actions. Whereas, in the final version of the game, you click on the villages, and that gives you the actions.

And this came from something that Pablo told us early on and really made a big difference, which is like people that are used to playing video games get this concept of click action, apply to object. But we realized, both through play testing and again Pablo telling us, that when you don't have that sort of experience, working in a lot of videogames and just having that context in your head, that doesn't really make sense.

It makes much more sense to the people that we're aiming this game for to click on the object and then choose an action. So like that inverting of the order of things actually makes a big difference in helping to understand the game and just making the whole thing smoother.

On top of that, we sort of like really refined the information that we're showing when you look at the map. So right now, like in the original version, you look at the map and you sort of don't see straight away everything you need to see.

You need to go to each of the villages individually to know what's going on. You sort of can only see where each village is, or where each locality is and how much health it has.

Whereas in the final version, we sort of give you every you need to see. And it took a long time to figure out how we wanted to do this UI. Like, how do we show what prevention measures are in place?

How do we show whether the infection is growing or decreasing? And how do we show which way the river is flowing? All of these questions were really important and really led into the final design.

Secondly, about like options, at first we had lots of options, too many. People did not even want to figure out what each of them did. It was too much information thrown at once.

And although we thought that having lots of options would lead to meaningful-- like, oh, well, you can make these advanced strategies. It really didn't, because people didn't even want to bother learning all that.

Whereas, in the final version, having fewer options made it much easier or like much less scary when you opened up the list of options, the actions that you have available to you as a player. And it was much more accessible, while still making the strategies diverse.

So now, we're going to talk a little bit about what went wrong in the process of making the game. So working together is really hard, because people are stepping over their toes. Oh, what do I do now. Oh, I can't touch that, because you're touching that. Like, all these sort of problem arise.

And so at first, we really tried to avoid that. But then we realized working apart is even harder than that. Initially, you think, well, if we're each working on really sort of independent parts and we bring it all together in the end, that'll be happy.

Everyone will be happy. We're not stepping on our toes. We can each work on our own time and that sort of thing.

But that turns out not to work well, because people do things differently. People follow-- like, even simple things, like coding style and how you name your variables and all that sort of stuff makes a difference.

And if you're not working together closely, and if you sort of working apart, bringing that together was a huge hassle at the end. Like we spent a lot of time just making sure everything, all the components that we had made as individuals worked together, just to get the game running.

LAUREN: So another thing that went wrong was the motivation for this project. At the very beginning, the team wasn't very passionate about the project to begin with, which is really hard. It's really hard to work on something that you don't really love and want to do.

And I thought, you know, maybe this will just get better. People will start to have ideas. They'll feel ownership of the project. And then they'll be more motivated to work on it. But that's not true.

People, if they start off in a bad place, they're not going to get any better. You really have to focus on somehow helping people to either learn to love the project or learn to just be able to work on it. And this can be done through different ways.

The easiest way is just to get people to realize like we have to do this, so you have to work on it. And I found it as-- towards the end of the semester, it took me to figure this one out. But if you give people vague instructions, they will wait until the very last second. But if you make it crystal clear, exactly what you want them to do and give them is as detailed instructions you can, it's much more likely that it'll get done in a timely manner.

And also, we felt really restricted by the topic and the requirements, which was another just problem in motivation. And so crunch is something I was sort of alluding to, is that when you have the instructions and you don't want to do something, you will put it off. I do it.

I am sure everyone else does it that I don't want to do this. I don't understand what they want me to do, so I'm just going to wait until the last possible second when I have to do it or I'm going to fail. And that's when it gets done, which is what I think was a leading thing to our crunch. And so we had constant crunching. Every time we knew we had to play test, the night before, everyone was up working.

And there was a huge crunch after Thanksgiving. We took until Thanksgiving, and then everyone realized we don't have that much for longer in this semester. We only have like a week and three days before this final presentation. So there was a lot of crunch there.

And the work was low priority because of other classes, which is a really unique problem to doing a school project, as opposed to doing a project in the real world, where people still might have other things to do, but this is their job. Whereas, when this is a class, you can't really fire someone from your class.

Let's see, you want to talk about what we learned?

STUDENT: Yeah. So what we learned in terms of game design, at least for me and probably for everyone on the team, what was most surprising is that giving more choices and making a game more complicated does not make it more fun. Initially I thought, more choices means more strategic diversity or whatever, and that'll make everything more exciting. And every time you play the game, you can try something different.

But that's not really true. Having less choices can be even more fun than having more choices, because then you don't have-- like when the player doesn't have to think about as much at once, they can really go deeper into what the current options are. So that was really surprising.

Also in terms of game design, requirements can be restrictive and often you can't do what you want to do. You as a designer can't do what you want to do, can't fulfill your own fantasy for what the game is opposed to look like, because of the requirements, because of what clients want, and because of what players want.

And you have to learn to sort of deal with that. The designer is not always right. Just because I have an idea for what the game is supposed to look like, if I test on 10 people and all 10 people say I don't like it, I'd prefer it to be this way, then I'm wrong. I have to change that. And that's something that's hard to deal with, but it's something you have to learn to do.

Yeah, we learned a lot about cholera. Basically, as we said in one of first slides, washing hands is overpowered in real life. If you just wash-- very simple things can prevent cholera. And that's something we wanted to get across in this game. In the game, washing hands is overpowered, just so that they get that idea across.

And about coding, there's a lot of simple things you can do to really polish up the game, like tweening, which is a animation API available, and Phaser that we used. But really any animation API that does like little things, like having the window pop up instead of just appear, having things go like "paching!" and move in and out, that makes a huge difference for very little effort. And it makes the game look much more polished.

In terms of future changes for the game itself, we initially planned to have seasons and lots of random events that would sort of make the game more exciting, especially near the end, once all four villages are up and you sort of get into this pattern. But we basically didn't have time to do that.

And then the second thing that at least I personally wanted to add to the game was more advanced infection models. It turns out that modeling infection is-- well, it's not surprising really. But modeling infection is really hard.

Balancing your model of infection is really, really hard. And it's sort of almost impossible to make it have this sort of smooth curve, where it starts out easy and then gets sort of hard at the end but not too hard. Infection is exponential in nature. And that's really hard to deal with.

If I had more time to work on it, I'd probably spend a lot more time thinking about different models to use for infection and make it easier to balance. Like right now, you change like one little number by hardly anything, and the game goes from really, really easy to completely impossible, just because of the nature of infection.

LAUREN: And lastly, future changes for the class. One of things that we all felt would be really useful is if the professors had enforced the sprint task list, because you could submit your sprint task list at the beginning of your week. But you never had to tell them if you actually did everything.

You just had another sprint task list, which maybe if that it was looked at carefully, there might be the exact same things two weeks in a row. But a lot of times, you never heard anything about your progress. You just kind of had your progress.

And it wasn't until the end that we really realized like, oh, we're kind of far behind. We need to fix that. So it would have been nice earlier in the project to have that sort of feedback, like, hey, you should be-- are these things done? You should be doing more.

And more freedom in choosing the topic, like we mentioned before, we felt really restricted. There were things we wanted to do that we couldn't, because of the confines of this project. And so a little more freedom would've been nice. But you know, it's a class. So finally, does anyone have any questions or comments, feedback?

AUDIENCE: OK. What would you do if-- what would your team have done if they were able to choose a topic or have a little bit more freedom? Was there anything in particular you talked about as a team? Or when you're talking about things you wanted to do but the client said no.

AUDIENCE: Humor.

STUDENT: Yeah, in terms of like if we were doing about cholera, things we wanted to do about cholera but we couldn't, like death is not in the game. We can't make it like overly morbid or anything, not that we-- But there are certain things, like we wanted to have more options.

But since the game is sort of oriented towards-- or rather, the options have to be oriented towards what an individual can do. So the game is supposed to teach kid to young adult as an individual how can I prevent cholera, which is like you wash your hands. You boil your water, that sort of thing.

But things like put basically bathrooms, the sorts of things that a government or the group of people as a whole could do, but an individual can't really do, were options that we wanted in the game, and could have sort of interesting mechanical effects within the game, we couldn't do, because it doesn't make sense. I can't teach you to make bathrooms. You can't, not really, as an individual.

LAUREN: Yeah, and sort of as Jen shouted out, tongue-in-cheek humor. There was a lot of time during the game where we're like, oh, we should have this happen, but it was offensive. It was funny.

It would be funny to an American audience. But because it was for an audience in Ghana, we changed the-- we didn't know whether to use village or town or city. And so we asked Pablo. And he said use the word locality, which to everyone playing it, play testers, we're like this is a really weird word. Why does it say locality?

And even we forget to use the word locality. And we call it a village accidentally. And so we'd want a little bit more freedom there and sort of make it maybe a more humorous game.

But we didn't really-- we were really afraid of being offensive. That was like one of the first things we talked about when we started making the game is how do we make sure we don't offend anybody accidentally.

AUDIENCE: Any other questions? We're done? All right.

LAUREN: Thank you.

AUDIENCE: Thank you.

AUDIENCE: Thanks.

LIZ RITA: We're the Saving Gora Gora team. I'm Liz, Rachel, Kevin, Justin. There are others in the audience. Go to the beginning. Yeah.

So to start us off, I'm going to talk about, let's see, the goals that we had from the beginning. Our product is about cholera and cholera prevention. And our audience was Ghanaian children. So we had to find a way to connect Ghanaian children to this information about cholera prevention, positive behaviors, proactive things they can do in the community, while also having a fun game that they can relate to.

What this ultimately meant is that we had to do a lot of research, because we didn't have a direct connection with our audience. And we couldn't directly play test with children from Ghana, ages 8 to 13. We had to make a lot of assumptions, which ended up being wrong after we talked to Pablo, specifically about them.

So we did some more research. We looked at Ghana, cartoons targeted towards children in Ghana. And from those cartoons, we looked at the color palettes, some behaviors within the cartoon specifically, and names and sort of character designs from the cartoons.

And we got Ghana research from documentaries and stuff, also informed decisions that we used to change minigames, which we'll talk about later in the presentation.

A quick overview of the narrative-- you start the game. There is this monster hiding in a bush. You go to check him out. It turns out that he's being persecuted, because everybody in Gora Gora is sick. And they think he's the cause.

And Sal is actually a cool guy. You're a bunny, and your name is Kojo, and you're a cool guy, too. So you're asked to prove that he's innocent. And you take that up, because you're an awesome person.

The gameplay ends up being that you explore the town, looking for ways to prove that Sal is innocent. And you do that by unlocking these minigames and getting clues from the minigames after you defeat the minigames.

And after each minigame, you can go talk to the mayor, or you have the choice to, because he has an office. And when you have all the clues, you finally convince the mayor that Sal is harmless, which is great.

KEVIN WANG: So our first minigame dealt with water filtration. And the concept behind it is that friends and neighbors are bringing containers of water to Kojo's mom. And they want to see whether the water is safe to drink, or whether they have to purify it beforehand by boiling.

So that, and when we initially designed our game, it turned out to be water filtration kind of factoring, in which bottles of water were going down a conveyor belt. And you were asked to remove the bottles that were unpurified and that needed to be cleaned.

So as you see on the left, that was our very first iteration. And I guess the issue with that, as Pablo brought up to us, was that it wasn't relatable to the kids that we were trying to target, because these kids likely won't ever see a facility that has these conveyor belts, that does this kind of purification.

So we had to go through several iterations to figure out a way to make the game a lot more relatable. And our final product is on the left-- or on the right, sorry. And as you can see, it's outside one of the homes in the village.

And your mom is just standing behind a pot of boiling water. And now, you just have plain containers, bowls, buckets, tanks. And your goal is to kind of see where the water is coming from, how warm it is, and try to figure out whether you want to boil it or not.

So some challenges we faced were, in our first iteration, it was more of a real time game play. You were kind of rushing against time to pull off all the unfiltered water, as all the bottles continued to scroll to the right, regardless of how fast you were going.

But then we realized that took away kind of from the educational aspect, because it forced the player to just kind of hurriedly just pull everything that they can. So instead, we changed it to a styled gameplay that was kind of at the player's pace. They can do everything as fast or as slow as they want. And that, I think, gives the player a better chance to kind of learn everything there is to learn from the minigame.

RACHEL WANG: Cool, so the second minigame is a water collection game, where you're asked to help your friend [? Korku ?] find where to collect water from. And so with this development process, it was kind of similar to what Kevin was saying about making it, like have as high of a learning value as possible.

And then another aspect of this game was making it fail-safe. So obviously, we thought there was one right answer that the player should take away from it. But we didn't want them to fail and then not win the game at the end, if they were to not choose the right location.

So one way we dealt with that was, every time the player chose a wrong location, there'd be immediate feedback, saying, oh, this isn't such a good place to collect water from because. And so as you can see, this example is, if you were to collect water from the river, you don't know if there's excreta from upstream or if someone's peeing in the river right now. So then it'll ask you to try another place.

We also did a feature cut pretty early on, which was also finding someone to dispose of your excreta. And so we focused on the water, which would hopefully focus the player's attention in figuring out where to place water and really think about the water aspect and not so much as another aspect of the game.

So the other challenge was, as Liz and Kevin already pointed out, was there's a huge cultural difference. So again, I have like a before and after shot of what our landscape looked like. And so originally, there was snow-capped mountains, a lot of grass. But from our research, we saw that this didn't really look like Ghana landscape.

We had a water treatment facility, which originally was the correct place to collect water from. But we eventually changed that to be a well. And so that's more realistic in terms of where people collect water in Ghana. Additionally, at the end there is a task bar, so it provides you more feedback. If you clicked on any of the buildings it'll provide you feedback about what that place is, and whether or not you should or shouldn't be placing water there.

JUSTIN MARTINEZ: Our final minigame is focused around teaching the symptoms of cholera and the importance of early prevention and recognizing the early signs of cholera to prevent the disease from spreading. So the premise of this game is that the doctor in the town is very busy. He can't go out into the town to actually check on patients to see if they're seeing any of the early signs of cholera. So he asks you to help him by going out and talking to some of your friends in town, and then asking them if they're having any of the symptoms, and then ask them to come in to the doctor.

We initially started off by having this game be a game where you help the doctor in the doctor's office. And he's diagnosing patients, and you're sort of diagnosing the patients with him. And we realized that this would quickly turn into sort of a quiz-type of game, and it would really detract from the learning aspect. It would essentially the same as just reading the systems out of a pamphlet. So we decided that by adding more interactivity by forcing the player to go out into the village and actually find people and talk to them and then ask them to come to the clinic would be a lot more engaging, while still maintaining the same educational aspect about trying to search for the right symptoms.

Additionally, we made a change where we had the player go talk to some of the villagers that were adults. And then we realized that-- after speaking with Pablo, that the social hierarchy in Ghana is not necessarily that of the United States. And this sort of interaction, where a child asks something or sort of demands something of an adult, isn't really something that would happen, just because of the stricter social hierarchy. So we decided that it'd be more appropriate if we had the child go talk to some of his friends that were of the same age. And then tell them, since they're on the same sort of level, to go to the doctor's office, rather than talking to elders.

Some of the challenges that we saw were that this game is heavily dialogue-based. It's almost entirely interacting through our dialogue UI. And so we needed to do a lot of iteration on that in order to make sure that it was clear who was speaking and give the appropriate choices so that the player can make meaningful decisions while having his interactions with the villagers.

And finally, since it is so dialogue-heavy, there's a problem that comes when making a game for children when you have a lot of text, because they might not be the strongest reader. So we focused w lot on making sure that the vocabulary was simple, and we tried to keep the sentence structure as simple as possible, and straightforward, to get the message across to children.

So some of the overall challenges that we faced while doing the game development was mastering the states with Phaser. This is sort of an intricacy of the Phaser engine itself, where when you spawn off the different stages of the map, making sure that we can maintain the data across all these different states, so that there can be a sort of progress through the game. And finally, we want to make sure that the game wasn't too difficult. For example, with the facility game at the beginning when we had the very fast-paced clicking, and then you would fail almost all the time. We wanted to make sure that it wasn't too difficult, and that it was accessible.

The cultural disconnect we touched a bit on in some of our previous games, making sure that the target audience will be able to play this game and relate to it in order to pull the message from it, and making the play meaningful. We wanted to make sure that the game play was still getting the message across, and finding a good balance between education and play.

RACHEL WANG: So now I'll talk about how our teamwork worked out, and what our process like as a team. So we used four main tools. The first one being Trello, to keep track of our tasks and progresses. So, we'd put all our sprint task lists, our product backlog, on to the Trello. People would claim the different tasks, and then be able to say if they were doing them, if they were done, or if they haven't started. And then that means we could track how people's progress was.

The second one was weekly meetings. So, every week we had a meeting to either do some research about Ghana, talk about how we could improve the game play and make it more meaningful, if we should cut some features, and whatnot. So, these meetings were really great for quick and efficient decisions, and also really important decisions.

Our third tool was Slack, which some other teams talked about. But it was really great because, first, they had Google Drive integration, so you could see when people were pushing code if you should be pulling code. And then, in addition, we could have different channels. So we had a separate coding channel, where all the coders could talk to each other, and that might not be relevant to other people. And then having a whole team channel was also efficient, because it would be faster response than email.

And then our final one was Google Drive, which is where we have all our assets, had all our dialogues, our characters. And this worked out to be a really great tool for collaborative storage.

Some downfalls of this was-- I'll talk about the second part, was basically with all these tools you need to make sure that everyone's actually using the tools. It's not actually effective to be using Trello if not everyone's using Trello. And we found this to be the case, not everyone would be updating their progress on Trello, or not everyone would be on Slack . But some mitigations we had to that is, in like Slack, you can mention people's names, and then it'll send them an email if they're not actually on Slack at that time. We did have to remind people to be updating the Trello board or updating their progress in Slack, or just ping people individually in email. But I think we worked it out.

Something we could have improved on was enforcing deadlines, and having deadlines. As Kevin will talk about, we had different roles between coding and art designing. So, obviously the art assets had to be done before you could really code things and put it into the game. So in that aspect, we should have probably had clearer deadlines so that we could stick to a stricter schedule. And then, in addition, we should have probably had a bit more frequent communication with the entire team. So we did have a lot of communication, but sometimes not all the team members were present, and we should have probably improved a bit about sending out meeting notes and catching up people who weren't at the meetings when we made certain decisions. And to that regard, something that we could just do for next time is, send out meeting notes, and keep everyone up to date, and possibly even have smaller meetings where not everyone is present. So I guess in terms of what went right, Kevin will talk about that.

KEVIN WANG: So, as Rachel was saying, we separated a lot of the tasks of the project between the team members. And since we had seven people, we designated four to coding, two to design and art, and then a few others to the other aspects such as narrative, project management, and sound. So, that actually helped us a lot, in that having only four coders rather than seven really cut down on the number of merge conflicts and issues that we had in previous projects. Because, obviously, the fewer number of people working on each file, the less likely it's all going to break when people merge their stuff together in GitHub.

And with the art designers, it actually helped to have just two. Because, although they had to do more work, it was easier for them to collaborate and make sure that all of their art followed the same theme, rather than coming from three or four different sources that look slightly different. Eduardo and Liz were very capable in making sure that all the art had the same kind of color palate, and the same kind of cultural theme to it, which helped, I think, unify our game in the end.

And, as Rachel also said, we had semi-frequent meetings, mostly at the end of the weeks, just to catch up and see how everybody was doing on their parts, and what we were planning on doing for the next week. And it also served as a good time for us to really sit down and get some work done, whether it's drawing some new assets, coding a new minigame. And having most of the people there together at the same time allowed us to really bounce ideas off each other when we were implementing this, which made things a lot more efficient.

And lastly, we realize that at the beginning, we had probably more than we could take on over this eight-week period. So we did a good job of cutting features early. And the main one we did was cutting the fourth minigame out of our game entirely, so that we could really focus on making the three minigames that we have currently really robust and really relevant to the ideas we were trying to convey.

RACHEL WANG: So moving forward from this where hopefully we would be able to find more of our target audience, our focus tests helped a lot whether it was speaking to Pablo, other MIT students, people in the class. They gave us a lot of good feedback about the game. But obviously we didn't get a chance to speak with Ghanaian kids, which is our target audience. And that could definitely help if we had a longer period and were able to find even kids ages 8 to 13.

In terms of iteration, I think we could still focus a bit more on balancing the difficulty. And then we mitigated that by doing things like what Justin said about changing the text dialogue, and also providing a lot of help tutorials or instructions throughout the game. But that's something we could always think about, so that even kids younger than our target audience could access the game. And then, obviously, just making sure the game is culturally relevant, thinking about word choices, thinking about assets, something we could always improve on.

And then, finally, to actually keep moving forward we could implement another minigame, find out other things about cholera we really want to get across, and add other adventures to the game. But the game right now is pretty contained, and gives, we think, three valuable lessons about cholera, and three very concrete preventative actions that you can take, and bring back to your village and your family. So I guess that's what we would think about if we were going to go for it.

And now, we'll move into our demo. So, I guess, if there's any questions first we can take those, or else we'll be looking for a demo-er.

AUDIENCE: I have a question regarding how you used like the structure of like having the many minigames inside of a big game. I wonder like does that help splitting the tasks up among different members in the team and make the process better? Or did that add more difficulty to finish all the contents and correctly tie them together?

RACHEL WANG: Yes, really, I think the modularity really helps, so the three of us took the lead on one minigame each. But then obviously there were components that cross all the different minigames. So, for example, our other coder worked a lot on the conversation and dialogue UI that shows up in all the minigames. And additionally, at the beginning we did run into an issue where we thought, oh, really the game is just three minigames. So we worked to come up with an idea to tie everything together. And that ended up being an inventory clue kind of thing. So you could go around town looking for clues that you needed to unlock the minigames. So, for example, to play the water collection game you need a bowl to collect the water. So you would go around town and find someone-- maybe someone was like wearing a bucket on their head. And you'd be able to collect that bucket from them and then play the game. So, in that sense, we were able to come up with this idea that could tie together all the different minigames. Does that answer your question?

AUDIENCE: Is its mother a cat?

LIZ RITA: Yes, [? Bunnykins' ?] mother is a cat.

AUDIENCE: All right. [INAUDIBLE]

[LAUGHTER]

AUDIENCE: So, you cut the minigame number four?

JUSTIN MARTINEZ: Yes.

AUDIENCE: About when in the project did you do that? And about how much work had you actually put in to that minigame before you decided not to complete it?

JUSTIN MARTINEZ: That game did not make it past the paper prototype. After we did the paper prototype, we realized that, that game and the symptoms game were actually very similar. And so we [? introduced ?] some or the storytelling aspects into the doctor minigame that we pulled from the fourth minigame.

PROFESSOR 1: Thank you.

[APPLAUSE]

[INAUDIBLE] will volunteer. Thank you.

 

[LAUGHTER]

AUDIENCE: I sure helped!

[LAUGHTER]

 

From our previous discussion, I wonder if I can take his bucket.

LIZ RITA: [INAUDIBLE] like, go closer.

AUDIENCE: Oh, gosh.

I don't know if [? Korku's ?] is going to get that bucket. Maybe I'll keep it. Wow, I already have two quests.

[LAUGHTER]

 

[LAUGHTER]

 

Never play with fire by yourself.

[LAUGHTER]

 

Whoa, look it's turned into a cat.

[LAUGHTER]

 

Ah, cool. I mean, if I say no, I should come back later, don't I?

[LAUGHTER]

Thank the bowl, and click me when you're done. All right. Well, I know where to go, but we'll do this anyway. There's no water there!

I guess that makes sense. If there was water in the house, I wouldn't need the bucket. I do all the wrong things first. It looks like there are a lot of bacteria in the lake. I have really good eyes.

[LAUGHTER]

 

You-- I don't want rusty water. Oh, the bathroom, that's a great place to get water. I won't go there. Yay! I have water. Can I go swimming?

Yes, yes, I can. I forget what you wanted. What did you want again? Paper. I know-- no, I don't actually. Oh, I guess I do know something. Ah ha!

[LAUGHTER]

 

I guess I need to go in the houses now. That's my guess. Oh, cool. You-- I better boil that.

RACHEL WANG: You might want to start the game first.

AUDIENCE: Oh, start the game. I'll do that first. I like this water. This is great. I just know that the well is good, because I was just there. Pump and clear, well, rust was the problem before, so where am I getting this hot water from the pump? Discolored. Discolored. Well, I am going to be safe, because I don't have to gather firewood.

 

I'm running out of firewood. Now I'm going to be in trouble here. We'll go for it. It's from the pump, how bad could it be?

[LAUGHTER]

AUDIENCE: Is this the rusty pump?

[LAUGHTER]

AUDIENCE: Oh, right. That's the bad stuff. The well's the good stuff. Oh, that's [INAUDIBLE] pump. Ah, whatever.

AUDIENCE: It is the cholera that you've got to test in this game, right?

AUDIENCE: Hm, I only have three firewood. Let's just do this. One of the next one will be clear, I'm sure. Well and clear. There we go. We'll boil the rest to be safe. All right. Throwing up and have diarrhea and very thirsty. Oh. So in other words, you've seen the monster. You should go see the doctor, because you have all those symptoms. All right. Where are my check marks? Oh, look I got three clues. Is that good enough? Let's go out to mayor. I don't have any more spaces for clues, it must be good enough. Nope.

 

LIZ RITA: [INAUDIBLE]

[LAUGHTER]

 

AUDIENCE: Yay!

LIZ RITA: I just jumped over that office.

AUDIENCE: I guess the repetition's not a bad thing, is it, for your demographic? That's good.

[LAUGHTER]

PROFESSOR 1: That's it. Thank you.

RACHEL WANG: I think that's it, that's all we have. Are there any last questions?

PROFESSOR 2: I actually do have one question about the music. Because you have it on the credits. Is this like a piece that the person wrote for you? Or is this something that you downloaded from the website?

RACHEL WANG: We downloaded it.

PROFESSOR 2: You might just want to check their website to see exactly how they want to be credited. [INAUDIBLE] title of the song they want used, or something like that. But if you've already done that, that's good.

PROFESSOR 1: Great. Thank you.

RACHEL WANG: Thank you.

[APPLAUSE]

PROFESSOR 1: All right. We're done! Thank you so much.

[APPLAUSE]

We really enjoy teaching this class every year. We really hope you got a good experience for it. I liked seeing a lot of the presentations, and I liked the changes that we saw from rehearsals to today. So there was a lot of really good information in there, both in the games and in the presentations. Again, if you have any questions about future classes-- we don't actually offer a game design degree at MIT, but we do have a concentration of comparative media studies. If you take any four CMS classes, you get a concentration. It can be from this list here. There's information on your desks about other things you can do with games at MIT. Course six students, if you're interested in doing UAPs, if you haven't thought about that, start thinking about that now. We could help with mentoring and advising on UAP projects and other kinds of research. And I'd like to give a thanks to the instructors, Phillip, Sara, Andrew, for all your help with running the class this year. So, thanks again.

AUDIENCE: Thanks, Rick.

[APPLAUSE]