Session 8: Project 2 Presentations; Project 3; Digital Prototype with User Interference

• Download this transcript - PDF (English - US)

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: All right, so it looks like we've got everybody here. It's about 1:11. Today in class, we are going to end our project twos. Yay. We feeling good about this? Kinda? I'm feeling good about this. And we're going to start project three.

So we're going to start off with our project two presentations. Again, we're going to go through here. Each team has five minutes to give their presentation. Slides. You can set up your slides up here. We've carved out enough time for today to be able to swap out between computers and for us to ask a couple of questions after each presentation.

After all the presentations are done, we're going to take a break. Instructors will kind of talk to each other about what we saw in the presentations, and we'll address some of the feedback that we heard, some of the things that we saw in the presentations. As a reminder, presentations, we want to hear about what went right, what went wrong, and also what would you do differently?

Then we're going to start project three. And we're going to do brainstorming in class. Basically, the first week of class we're going to compress into about 30 minutes of this class. We're going to brainstorm, we're going to do our elevator pitches, and then we're going to form teams. So we're going to do that really, really quick. And it might require rolling the die again. It might require moving you from project to project. And that's going to be OK. We'll talk about why we're doing that when we go.

So I think that's everything from me. Any questions? And if not, Sparkly Redemption, come on down.

PRESENTER 1: So what went right? The game got made. It isn't broken or sad or dead. Even though we had to cut some things, I feel like the general idea of you are a player and you pick up sparklies and your sparklies change monster behavior slash your power-up slash whatever got implemented pretty well in a way that carried across our original idea.

What went wrong? I guess we had to drop some things. We had a person on our team not get hit by a bus, but they did basically not have as much time to work on the project as much as we thought. So we had to adapt to that. On the other hand, I feel like we adapted to that pretty well. So not good, but still good, I think, personally.

We were told to test early and test often, which I think we actually kind of did-- maybe not as early or as often as we could have. But we still tested even when we had something that we felt wasn't really testable but was still touchable. And I feel like that was kind of interesting to do because people kept telling us, you should totally be able to die. And we were like, yes, we do think you should be able to die, but we haven't implemented that. And so on and so forth.

But on the other hand, that meant we still got lots and lots of good feedback and things to think about, like stuff that we probably wouldn't have thought to have implemented but still implemented because we caught that early on. So yes, test early and test often, even if it's annoying, is what I learned, and I feel we all learned. And that might be all I can think of.

PROFESSOR: What would you do differently next time?

PRESENTER 1: What would I do differently next time? Meet up with people. Well, not necessarily physically, because we scheduled meetings but then we decided maybe we don't need to physically meet up because it's a pain getting people onto campus if they don't live on campus, which would have been fine. But then there were still times we were like, well, we meant to meet up but then we got iffy about scheduling a time, and everyone got confused.

And I feel like we managed to work our way through it. But it was still more of a hassle than it probably needed to be if we just sat down and scheduled out a chunk of time and listed things that we were going to get done. So differently would be better about meeting with each other, either physically or through the interwebs.

PROFESSOR: Any questions from anybody? OK. Which game engine was that again?

PRESENTER 1: Sparkly Redemption. It's the one-armed lady.

PROFESSOR: What game engine did you use?

PRESENTER 1: Oh. Phaser.

AUDIENCE: Anything to say about the experience of working with Phaser?

PRESENTER 1: So you do the thing where you have a bug and you think it's Phaser related, so you Google vague terms. And I've worked with Flixel and Unity, so I know personally I'm used to having long form posts pop up that you then dig through. But I feel like with Phaser it was a bit of a mixed bag. And sometimes you got relevant posts. Or sometimes you just went to the Phaser examples and kept digging through it until you found something vaguely relevant. So it wasn't terrible, but it was still not quite what I was used to in terms of figuring things out.

PRESENTER 2: So we're Lost Underground. One of the biggest things I felt our team had a problem with was communication. Because at the very beginning, we were really good. We all got really pumped for this project, and we got together. We had the paper prototype. We edited it a bunch. We quickly got that over to a digital prototype.

And then it kind of stagnated. We had the play testing, and we learned a lot from that. One of the most interesting things is we added the darkness mechanic, where you can only see a certain zone around you. And some people felt like you shouldn't be able to see as much. People felt you should be able to see more or less. Everyone had different opinions.

But we liked the way it worked. But it didn't work the way we wanted it to. People weren't concerned about walking around at all. The whole point of the dark is to be afraid of it, like oh, is there a monster over there, but there could be something to collect, and people weren't feeling that.

And so we found out from the play testing we needed to change it. And the best way to do this was to shrink it so you could see even less, to zoom out the camera so you feel really claustrophobic and far away from everything. And I think that really helped us.

We also learned-- what was really funny is we had just a placeholder, a little coffee cup, instead of a coin, which is what we originally went for. But every play tester was like, oh, coffee. That's the coolest thing. I love the idea of collecting coffee.

And so one of the cool things about play testing is if you don't say anything, they will give you really useful information, even though that's not what you intended at all, which was really cool to experience firsthand. And so we decided to stick with the coffee mechanic, and it ended up being a little more silly than what we originally planned for.

But like I said, communication was really hard. Planning out who was going to do what with a digital prototype was much more difficult than with a paper prototype, I personally feel. Because code intermingles in a way that paper doesn't. And so it becomes really difficult when people are pushing things and pulling things and then things break.

And so that was really hard. A way to change this, I feel like, would be to just make sure everyone replies to their emails, and make sure people are talking and everyone knows what's going on. And I don't know the best way to do this. Maybe an IRC chat, where they constantly have that chat channel there and people can look at it when they want to. Because emails kind of get lost. And text messages people forget to reply to. So something like that, where it's constantly there and you can go look at it and hopefully reply to it in a timely manner.

Or maybe just have-- one of the things I did in my other classes is the very beginning, everyone had to write up a contract of when you'd be working on things, when you reply to things. And so we had to sign and say, I will reply to any emails about this at 9:00 PM every day. And so you can expect a reply by my by 10:00 PM.

And so because we had this contract, we knew-- if I send an email to this person before 9:00 PM, I will get a reply an hour later, which was really useful when people were a little hectic and they had other things to do. At least I knew I would get that email back. So any questions?

PROFESSOR: So same question as before. What game engine did you use?

PRESENTER 2: So we used Phaser. And any coding questions, I'm going to direct to another team member who was more heavily invested in it than I was.

PROFESSOR: Anybody want to speak up about coding?

AUDIENCE: [INAUDIBLE] curious about Phaser.

PRESENTER 3: I thought Phaser was an interesting engine to use. I think in terms of the organization of the code, you have to do a lot of thinking beforehand if you want to make it work well. I guess it could be a little finicky when you just start building, because we thought, OK, well, we'll add code, and then we'll sort of architect it based on what we see happening. But then we came to realize that our code wasn't going to be as separable as we thought it might be.

I also ran into a couple of bugs that were in Phaser itself that I had to sort of dance around. So I would say watch out for the fact that there are still some bugs in it.

PRESENTER 4: Yeah, just callback nastiness and having to think about something will happen now-ish. Time isn't really now-now. It's like, now kind of now, then kind of then, floating point numbers that are somehow always floats and nothing is ever actually equal to anything else.

PROFESSOR: Is any of that documented?

PRESENTER 4: This is just found out. That's JavaScript. But I thought we could get away from JavaScript by wrapping that all in an engine, but no.

PROFESSOR: Thank you.

PRESENTER 5: Hello. We were Plunder Winds. So starting off with the good. I think our team was actually pretty well organized, and our roles were well-defined. So from the very beginning, we set up task lists and lines of communication. We set up a mailing list and then assigned everybody specific roles.

And then from that, we were able to-- none of us duplicated work. And we set up a good architecture early on. And so we used Phaser. And unfortunately, there's this one part of Phaser that's not really well documented in any of the examples and tutorials which is the state machine that Phaser has. Surprise, there's a state machine in Phaser.

And then once we discovered that-- we discovered that early on and used it. And so that allowed us to really architect our code well and separate out modules. And we also used a JavaScript module thing, which basically made it so that all of our coding efforts were really-- were really efficient, I think.

And as for the bad, five out of six, or basically our entire team, came down with the flu the first week, or over the first weekend. And that really impacted our schedule. So originally we had wanted to get a playable prototype by the first weekend so we could get people touching it and start getting feedback. But the plans best laid, it doesn't help if everyone gets sick.

So we had a large schedule impact. And the way we had to deal with that was, like, there's one guy who was able to code throughout the entire first week. And then the rest of us were playing catch up. And so we didn't get anything playable until the in-class workshop on Wednesday. And I think that really hurt us because we weren't able to get a lot of important feedback until very late in the process.

And so there were some features that we kind of added. And we were like, this may address player concerns. But we just didn't get enough feedback or data to figure out whether or not those concerns were actually really addressed.

PROFESSOR: And anything you'd do differently?

PRESENTER 5: I think we would not get sick. But also, we set up Asana and everything on Monday. But then we learned, like, oh, we have to do a sprint task list and a product backlog on Wednesday. So I think there was a bit of a weird issue there, where we already had one task management system, and then we introduced another one. And then we introduced scrum boards and we were like, well, which one do we use? And then we just didn't end up using any of them.

PROFESSOR: Any questions? So my question, I think, is you had the flu. A bunch of people were out. You didn't cut features. You tried to just catch up. Did you think about cutting features? Do you feel like you ended up cutting anything at all?

PRESENTER 5: So I think our core game was actually, like-- it was pretty simple to implement. And I just want to give a shout-out to our team. You guys pulled off an awesome job and implemented everything by Wednesday. And so we did actually manage to get a feature complete game by Wednesday. And then we started adding tweaks, like interface tweaks and maybe a visual cue here and there throughout the rest of the week. But in terms of cutting features, we didn't really have any complex time-intensive features that we would have benefited from cutting, I don't think.

PROFESSOR: Thank you.

PRESENTER 6: So our project was Beaver Evolution. And so I guess I'll first go through three of the bigger design challenges we came up with or that we encountered during these two weeks. And our [? system ?] was working with Phaser, which is kind of design, kind of the project challenge.

And so one thing we ran into is we didn't realize there was this thing called stages, and I think you guys just mentioned that. But since everything is turn-based, and in each turn you can make a choice between building, populating, and evolving, and then disaster might strike. So there was different things that happen. So we thought it could be very modular and we could use stages.

But then we learned that stages really start and stop every time you switch stages. So it doesn't take the info about what happened in a previous stage, which was really important to our game.

So then we ended up having to switch everything over to Phaser groups, so we could hide groups and show groups. So that was one of our first challenges, just kind of figuring out how Phaser worked and what would be best for our code.

It turned out our code was very modular because there were so many different elements to each turn. So it was very easy to split up the work. And that was helpful. Overall, we really liked Phaser.

Our second challenge is balancing the game, so making it not too easy to win and not too hard to win. And we kind of changed that by changing some of the winning conditions and then also adding a few mechanics here and there to make the game harder. Because often it was just too easy.

So for example, you could just keep evolving. Or you could keep populating your beavers. And then once you reached the number of beavers you needed, you'd win. But we kind of changed that by implementing a rule where you can't populate every turn because you have to [INAUDIBLE]. So I guess the slide is not really working.

PRESENTER 7: Yeah. So I'm not sure why the screen won't show our slides, but we can keep talking about the game. So Rachel talked a lot about the design challenges we ran into for the game. And so I'll talk about some of the project challenges that we ran into.

I was assigned the role of the product manager. So you remember the product manager in the scrum roles is the person who's supposed to sort of lead where the game is going and make sure that all the design implementations are the way that they're supposed to be and handle any changes that we need to make to the code.

So unfortunately, we didn't explicitly assign a scrum master. So by taking on the role of being the product manager, I also assumed some of the roles of the scrum master. And I know that this was stated to us in the lecture about scrum, how we should definitely not do that. And we now see why.

I unfortunately had to run some of the meeting-- I unfortunately had to focus on running the meeting as well as on making sure that the design was going in the direction it was supposed to go. So I definitely lost some efficiency there. And we started off very efficient. We were able to assign tasks, and our product backlog, our sprint task lists, were all very laid out. We had an early meeting to make sure that everything was going well.

But then by the end, I just sort of started running out of time. We were unable to schedule a meeting after the play testing session due to everybody's schedules being very tight. And so some of the changes that we wanted to implement after the feedback from the testing session we were unable to implement. But we were still able to get a good game together. Our organization just sort of fell apart towards the end.

So those were probably some of the biggest design problems we ran into. I would definitely next time, for our next project, make sure that there's a clear product manager and a clear scrum master so that those two roles can be done very efficiently and not overlap.

PRESENTER 6: Yeah. And I'll just add on, so our testing we really realized that user experience could be improved between having all the players know all the game mechanics and rules coming into the game. So yeah, in addition to not being able to meet up, not being able to play all the features, we really just focused on improving game experience by adding audio and by adding smaller things. But I think earlier in the game, we should have thought more about user experience and making sure that was a good flow.

PROFESSOR: Are there any questions? I think you covered everything. Thank you.

PRESENTER 8: All right. We're Comcastic. So as you'll recall, our game involves placing service centers on a map and trying to cover all of the houses. So what went wrong-- setting up Phaser took a long time. It was really hard for us to actually start writing code. We were using TypeScript, which was important, I think, for us, especially as a documentation. But it took some time to get a good set-up where you had a posted Phaser where everybody could develop and you had TypeScript integrated. And it would be nice if-- future projects, I think, will be set up for that. But for the first project, that was hard.

Meetings-- it was really hard to schedule meetings. We had seven people when we started, and we went down to six. And even at six, it was still hard to schedule meetings, mostly because of PSETs. I had one PSET, but everybody else had a lot of PSETs, and it was a lot of conflicting times.

What went right-- so Phaser itself, I think, really helped us develop fast. Once we got the hang of Phaser, it was a lot easier to develop. It was pretty consistent. The code is pretty good. It was not hard to debug by just looking at Phaser code for us.

Also, I think we got the synchronous communication down, because we really didn't meet that often, especially as a whole group. So we were using Trello, and it was really nice to just sort of bounce an idea off Trello, just put in [INAUDIBLE] feature, and then we would sort of discuss it via Trello. I think that that's something that we want to keep doing.

Also balance-- I think our balance is actually pretty good. It was sort of a coincidence that our pieces-- so the components of our balance are basically how the map looks, where the houses are, and then also the service centers you can place are. And you can imagine it'd be kind of difficult to make these two match up, but I think our first random attempts ended up working pretty well.

What we would do differently-- we would definitely stick to one communication tool and stick to something simple. I think Trello was fine, [? but even ?] GitHub issues would be good, and they would integrate with the code. Definitely we want to keep scheduling partial meetings with some of the group, just the programmers, just a handful of people, whoever can make it to one meeting. I think with students that ends up being the best thing to do.

And getting a [INAUDIBLE] viable product out early on-- I think we underestimated how important that was, even just getting a Phaser set up where you have an empty game running quickly. Even that, if you get that done in two hours versus two days, it makes a huge difference.

PROFESSOR: Any questions from anybody?

AUDIENCE: [INAUDIBLE].

PRESENTER 8: Yes, face-to-face meetings. Even Google Hangouts actually weren't easy to get everybody at one time.

PROFESSOR: All right, thank you.

PRESENTER 9: Hi. We're Modudice. That is our game. For those of you that played it, it's sort of like a number-puzzle type game. You move around a dice. You add numbers, a module of seven. And you want to make as many sevens on the board as you can, and you get points. And so what went well for us is our design meetings went quite well. We had two or three of these that were basically dedicated to figuring out, how do we do this better? And how do we answer some of the questions that came up during testing?

And I feel like those went really well. We were able to get good discussion. We actually came up with, like, solid answers. And we were convinced, like, OK. This may not be the best way to go, but it's definitely comparably good to anything else. So we're going to just stick with this.

And we were able to make task lists as a result of that. So we decide on something and then say, OK, what do we need to do to actually do this? And I think that went across fairly well.

And we did a lot of good testing, especially the testing we did in class. And on top of that, like, all of us just tested the game with our friends, since it's, like, fairly easy to play and sort of fun. So yeah, the testing was really useful. And we actually did change a lot as a cause of it.

PRESENTER 10: I'd like to add to the task list that I think we also did a very good job in terms of prioritizing what tasks were important. I'd like to say that we cut two features-- the dice rolling animation and sound. And I think those were really good feature cuts because they weren't central to our game-play as a very fast-paced browser game. And cutting them actually saved us a lot of work and let us have the time to spend on other features and stuff.

PRESENTER 9: And Phaser was good in the sense that it was something that went well, because it was easy to start with and it was fairly easy to use. Like, once you knew what you needed to do with Phaser, it was pretty simple to get it going.

But it was also a bad thing because it's Java. At least we did it in JavaScript. So JavaScript is hard to work with, hard to fix bugs and stuff. And I could see-- like, Phaser was fine because it was a fairly small project. I could see Phaser being absolutely horrible for large projects. Like, I would never want to use it ever.

PRESENTER 11: I actually thought that it actually did not have a lot of good documentation when we were trying things. I thought the community was not the best for Phaser.

PRESENTER 9: And so Git, I think, is awesome. But a lot of people weren't familiar with Git. And so the branching was confusing. And that became an issue. So if you're going to use a [? version control ?] like Git, make sure everyone understands it. That's something we learned.

And getting tasks done separately-- we thought that would be most efficient, since we're everywhere across campus, it's hard to meet up and stuff. But I think it's actually better to just at least start working together. When you have a set of tasks, begin the work together, do as much as you can, and make sure everyone's clear on how to do what they need to do and what exactly they need to do so that everyone feels like they are actually contributing and working together on this.

PRESENTER 12: I want to add one more point on Phaser, in the sense that-- I feel like Phaser-- we're trash-talking it right now, but I think Phaser is good for a one-person project because it's very easy to manage the stuff on your own. But with larger groups, I just don't like reading through JavaScript spaghetti code. So maybe we needed to find a better way to organize our code with more people. But I just didn't like-- like, I edited a piece of code, someone else edited it, and I was like, wow, it's totally different from what I expected it to be.

PRESENTER 9: And so yeah, next time it would definitely help to have scrum meeting and work physically together, so basically just spend more time together as opposed to messaging on email and stuff. Make sure everyone understands the source control and the engine. And like, have more people really think about-- like, have everyone on the team really think about design decisions. And then communicate, communicate. More communication definitely would hurt.

PRESENTER 10: I would like to add to that in terms of the communication. Because as a new member of a team who joined the Modudice, not the original Modudice team, we didn't actually host an information session about what were the critical things about the game, that we made it the way we made it. So the new members, such as me, had difficulty to put in variable input, at least for the starting duration of the project, and then we picked up later on. But if we had an information session, something like that, it would be very helpful.

PROFESSOR: Any questions from anybody?

AUDIENCE: Well, [INAUDIBLE]. When you said that your design meetings-- this was all the way on your first slide, were those online? Or were those in person?

PRESENTER 9: It was in person. But those were mostly focused, like-- so we had a lot of questions of how to represent the dice in 2D and stuff like that. So the design meetings were mostly focused on big questions like that.

PRESENTER 11: In addition, I think we had [INAUDIBLE] meetings. And I thought that we should just have multiple smaller ones, [INAUDIBLE].

PRESENTER 9: It ended up going, like, two hours.

PROFESSOR: Thank you.

PRESENTER 13: So what was bad? We're going to start with the bad things. The first decision we made as a team was using Unity 2D, because that was just the majority vote. Most people had worked with Unity for the project before. But it ended up having too many complications.

And it was actually a good thing that we switched to Phaser very early on. Like, two days into the project we switched to Phaser. So Unity [INAUDIBLE].

Second thing, we weren't paying too much attention to the assignments. Everyone was focusing on the game development and making the game look good. And we weren't updating the product backlog, and a change log [INAUDIBLE]. So we had to go back and remember what we worked on in the past week. And it was very asynchronized with that.

Another thing is we put off a lot of the work until the day before they were due. Like, the last project we had a lot of things that could have been done during the week, but the night before, we always have hundreds of emails to sending the emails around, trying to get everything to actually work. And that was a thing that cut off on our productivity.

Another thing is that we didn't really have a lot of meetings. We only had two meetings throughout the entire project, which had a downside that we weren't very synchronized. Even in some of those meetings, some of us couldn't make it. So we had to update whoever wasn't there with what happened in the meetings and things like that. And we definitely could have used more meetings to keep our work synchronized.

The last part is CoffeeScript. CoffeeScript was a good and a bad thing. I think it was a good decision overall, but it definitely had bad parts to it, which is that we had to sort of-- there's a hack-ish with Phaser that had to compile CoffeeScript to JavaScript, which caused some problems with the [? gulping, ?] where it would sometimes not work. And we had to run it twice. It generated JS files which we had to not commit into the source control because they were changed when the CoffeeScript files would change. And so there was some problems with it.

But once we had it up and running, it was so easy to write code and just iterate on the code. It was also easy to read other people's code, because it simplified 100 lines of JavaScript into two lines of CoffeeScript. I'm exaggerating. And then finally, also, it optimized the JS when compiled, so it would run faster.

PRESENTER 14: So talking about now some things that went well in addition to finding CoffeeScript, we had really great group direction from the get-go. Even though we didn't have a lot of meetings, I think one way we still managed to make that work was we divided bigger tasks into the sub-categories really quickly. And we also set up a Google folder in which we kept everything.

We didn't end up using Trello or anything like that because we really found that a Google folder with everything in it was the simplest for us-- that along with just one chain email where we sent everything really kept everything focused and everybody in communication, in the loop, as best as possible.

So source control, we used Git and GitHub. And we actually had a great experience with that. I'm sorry some people didn't. Nothing ever broke, and we barely had to merge because I don't think we did very much branching, which is the way I think we avoided any problems there.

So iteration-- we iterated our game a lot. We changed a lot of things, because we'd play it and be like, well, people keep dying, so how can we make that better? Another example is with our sprites, as you can see up there-- so the initial designs and then what we changed them to. We actually had a problem where somebody looked at our first alien design and said, that looks like a piece of the female anatomy. That is distracting. You need to change it. And we said, OK, you might have a valid point there. Even if we don't think so, maybe it does. Let's change it. So we iterated a lot.

And then focus testing-- we really actually implemented-- talking about iteration, in our focus testing, the two things we found were that new players were dying really fast. It took them, like, five times before they realized how to play the game. And then, in addition to that, after five minutes, they were getting bored.

So we actually took that to heart, and we changed one of the main premises of our game, which was this reloading thing, that it would take a couple of seconds before you could shoot again. And instead, we added a short term goal of actually picking up ammo. So you can see-- it's kind of hard to see. But the ammo-- the big thing is just the animation. But if you can see on the screen, there's a player, there's the ammo, and there's a bug.

And basically we changed that whole way the player actually shot to make the game a little more difficult over time but also starting easier, by having everybody smaller and then the bugs get bigger. So a lot of changes and iteration even based on our focus testing.

What we would change-- we'd start earlier. I know we talked about a lot of changes we made were the night before things were due. Pretty much all of our documents changed the night before they were due. And it's kind of frustrating, you know, having to stay up really late the night before it's due when you've had the whole week to do it. So just start earlier. I mean, we started pretty early, but finish earlier, definitely. Hands off for the last 12 hours, kind of thing.

And then we also talked about this-- being focused on what's actually due. So one thing that was good about having a lot of focus on our game was that we had a viable product really early. But a lot of our other documents kind of fell by the wayside, and they kind of came up to one or two people to just fix them all the night before they were due. So definitely focus on those things and more accountability with that.

And in conclusion, even though we had some frustrations, it went pretty well. Our game ended up pretty clean and creep and fun. So we really like it. Thanks, guys.

[APPLAUSE]

 

PROFESSOR: Questions?

AUDIENCE: How did you stumble upon CoffeeScript? What was the decision when you were trying to [INAUDIBLE]?

PRESENTER 13: Jen, you want to take this one?

AUDIENCE: If you could come down [INAUDIBLE].

PRESENTER 15: I used CoffeeScript a lot before I was really familiar with the build systems and stuff. So I figured it'd be best to kind of set up a build pipeline that optimizes the [? alpha ?] JavaScript to make the game run faster because [INAUDIBLE].

PRESENTER 13: And CoffeeScript also has a lot of shortcuts. It's like Python. It's like using Python to write Java. It's so good. Like that.

PRESENTER 14: Any other questions?

PROFESSOR: Thanks. OK, feedback. And instructors, please feel free to jump in if I'm missing anything. Oh, and I forgot to copy all my notes. All right. So yeah, I was wrong. Ha, you caught me.

Slides were intended to be required for this project, but they were not. So you're not going to get penalized for that. The issue for that is slides and visuals are recommended to help your presentations stay on topic. Basically, you had some issues sometimes with keeping track of changes. We had some issues with keeping track of our changes to our documents. So QA is important in everything that we do in life.

But for project three, slides and visuals are recommended to help your presentations stay on topic. And what we saw presentation-wise, slide-wise, was perfect for these five minute presentations. Quick, dirty, gets the point across, gets the bullets across. Visuals, like images or something, if you need it. For project four, that's a 20-minute presentation. Visuals are more important there. And we'll talk about those presentation requirements later when we start project four.

So discussion on meetings, things you should do in project three-- address how you're going to meet in your initial design meeting. The most important thing you have, before you even start designing your game, is to talk about who can meet when, what is your schedule. You all have syllabuses from your other classes. When are your PSETs due, when are your recitations, all that stuff.

Put it in your high-level design document. It's actually one thing that we use often in that one section where we talk about team roles, is team meeting times. And I think I heard this team mention that, that you've used in previous classes. That's a very good tip. Use that. If others can't make it to your meetings, is there a way you can take video? Is there a way you can archive what happened in the meeting for those people who couldn't come?

Here's something that I've seen some local companies do-- drop in IRC. Basically, even something as simple as keeping Skype open. Even better-- actually, my notes weren't put in there. Even better, an IRC solution that has some kind of archival process in, so all the previous chat can be saved. I know there are some solutions out there that actually hook this into your GitHub or Bitbucket or what you're using.

Those solutions are out there. Try one of them. But again, even something as simple as having Skype open and online, you can always tell if one of your team members is online. You can throw a text and say, hey, can I get your feedback on this? Can you take a look at this code? For your daily scrum, 15 minute Hangouts probably is-- all you need is 15 minutes for doing that kind of daily scrum meeting, so trying that out.

Problems we saw with backfilling your product management. Integrate your project management from the beginning. We know that this was a problem for this project because we introduced it to you midway through. That's OK. You actually did-- we mentioned this, you did some pretty good use of product management.

The goal for any project management tool that we're teaching in this class is that it should be helpful. It shouldn't be a hindrance. That said, we'd like you to get some practice with it first before you start throwing it out. So for project three, please use the project management tools that we described as we've described them to you. In particular, product backlogs, sprint task lists, and the design change log, and the vision statements, those high level design documents. Scrum boards, mostly optional, but we found them useful. They might not be useful for how your team is distributed. It's up to you to figure that out.

For project four, we'll give you the ability to create the system that works for your team, so long as you give us what information we're asking for. So you know you need this information. You know you need a way to manage your tasks. You know you need a way to manage your features and to prioritize your features to estimate. But how you actually do that and how you actually save it, that can be up to you for project four. We will want to see it actually cause some improvements. And if it doesn't cause improvements, let us know why and what kind of problems you found with that.

And again, the design change log. This is a design diary. It's even better. It's your meeting minutes. You should be able to fill it out in five minutes. Along with your task list and backlog, it kind of shows the history of the project. Take the time just to spend those five minutes at the end of each meeting to just throw something quick down so you know what has changed in the past.

Phillip, you want to chime in on this one? Modular code doesn't mean your tasks are actually separate.

PHILLIP: Yeah. This is just something that I got a sense of from watching everyone's presentations today. A lot of folks, even the folks who mentioned that the code was well separated and people could code independently, it doesn't mean that there are no benefits to actually still working side by side, even if you're working on different parts of the code. And some teams mentioned that.

So actually, again, being on Google Hangout or Skype or IRC or whatever, if you're working in your own rooms, or even better, a lot of people mentioned scheduling those face-to-face meetings-- it's OK for you to have a face-to-face meeting, even if you're not planning on working on the same batch of code. And you can actually still save a lot of communication time-- if nothing else, just to tell people what you're doing. So maybe it's not speeding you up, but it might speed everybody else up, and suddenly it helps the communication.

PROFESSOR: Form strike teams. You've got six people, maybe seven people, and eight people on project four. Not everyone needs to be touching code. There are other tasks that need to get done. You can form up into smaller teams. One team might just be working on some kind of-- again, if it's modular, it's going to have some dependencies. But if you can modularize it out, great.

But even better, especially with project four, when you have longer time, one team doing paper modification, doing UI elements, running focus tests, while another team is writing code. Think about how you can better utilize all the personal resources and all the man hours you have without requiring all these clashes with so many people touching the code. It's that too many cooks in the kitchen kind of thing-- not everybody needs to be doing that, need to be touching that.

Here's another thing we noticed. A lot of what you asked for was basically more time-- just various different ways of saying you wished you had more time, you wished you had started earlier, you wish you had iterated earlier, the flu hit. A lot of what you're describing there are things you're not going to have any control over ever. You never have control over that stuff.

What you need to do is focus on those things that you can control. So if you have illnesses, if you have major technical problems, the game is whatever you decide the game is. You've actually got some freedom in this class in that you've told us what the game is, and we're actually even telling you in the last week, again, tell us, what was this game actually supposed to be, so that when things change midway through the project, be flexible. Change what you're delivering to us.

Make it so that whatever you're delivering to us runs, works, is playable. This isn't a design class. We're trying to teach you some design skills. But it's not focused on design. So if the final game isn't fun, it's sad, but it's OK, so long as it runs, so long as it's playable, so long as it fits all the requirements that we're asking of you from the beginning. I know it's weird. This is the only class we do this in. Trust me.

All right. So that's it. Any other questions about project two? I think you all did really, really well. Really happy to see how the presentations went out. Yes?

AUDIENCE: Is there any way we can see what everyone did?

PROFESSOR: What's that?

AUDIENCE: Is there any way we can see what everyone did?

PROFESSOR: Oh, yeah. So one thing I highly suggest, somebody on your team email the video game mailing list. Video games, yeah. I did the plurals wrong. I never do that right with mailing lists. videogames@mit.edu-- email out a link to your game to your classmates if you want people to play it and give you feedback on it. At the end of every project do that.

Actually, use that mailing list as a resource for you to talk to each other across teams. Hey, here's our game. We need a little bit of feedback on this. My team is all sick. Can somebody please play this and tell me what's wrong? Can you play this on a different browser and tell me if it's broken? Take advantage of that mailing list. Any other questions? Yeah.

AUDIENCE: So [INAUDIBLE] postmortem, will we get more feedback on project one and project two, what the group grade was?

PROFESSOR: So there are no group grades. So what you're getting is-- your grades, if you look at the grading rubric, 20% of your grade is individual. The other 80% percent is your group. So the grade that you get is basically adjusted based on the quality of the write-up.

AUDIENCE: OK. And on project two, will we get more feedback on everything we've done, so we can better plan for project four?

PROFESSOR: Yeah. So for project two, you're going to get feedback on your design change log again. You're going to get feedback on your task list and product backlog. We just gave you feedback on the presentations and on those skills. You're going to do that again for project three. You get your feedback on the individual write-up.

Is there anything I'm missing there? And then game functionality-- we're going to give you more feedback on game functionality, because last time we did that in class. This time we're actually going to play your digitally released games. We'll give you some design feedback there for product three.

PHILLIP: Yeah. Because we could just show the actual numerical grading proclamations that we do, but that's meaningless without actually explaining what it is. So what we'll try to do is focus more on actual text feedback on what we thought were the strengths or the weaknesses of whatever you've given us.

PROFESSOR: That answer? Cool. Any other questions on grading? All right, give yourselves a round of applause for finalizing project two.

[APPLAUSE]

 

Let me double check to make sure I didn't miss a break. No, we just took a break. Ha, ha. All right.

So project three, you're going to practice project management, meaning you're going to use those tools that we talked to you about in the middle of project two from the get-go, with a slightly larger team. Some of your teams were five people this time, minimum is going to be six. We're going to make sure we leave class today with at least six people on each team.

And again, that's just to get used to it. Project eight, your minimum is going to be eight people. So with a larger team, you're going to focus on design iteration to maximize usability using user feedback through independent user testing. So the keywords there-- users, feedback, usability. Those are things we're going to be looking at when we're grading the functionality of your games.

So for project management, we mean create and use a product backlog and a sprint task list. There's few turn-ins for that. For design iteration, you're going to conduct focus testing and user testing on your own. And I'll touch on this again, but basically you're going to turn in two focus test reports, one of which can happen in class on a scheduled day. The other one must happen outside of class with a group of people who are not in class. So get people to test your game and report back to us on that.

And again, maximize usability. All the iteration that we see you do on your games, you should be iterating on that user interface or that user experience. So we are going to ask you to make a little bit more complex game than before. But really what we're trying to get you to do is make a complex game that has a possibly problematic user interface. Give us an interface that's good. Give us a user experience that matches the user experience that you want to strive for when you're designing the game.

PHILLIP: Just a quick thing. We do have a couple of lectures coming up on designing for that. But as Greg mentioned earlier, this is not actually the design class. There is actually a different design class that some of you have taken and are going to be distributed among the teams. Or you might have taken, say, Rob Miller's user interface class, which also has a lot of those same sort of concepts.

If you've taken any of those classes, you should be identifying yourself to your teams, because you probably have actually practiced designing for usability a lot more than a lot of the other people in your group. And that's what we're going to be looking for. But most importantly, the testing that we've been talking about, we are expecting you to be able to do that. And that anyone of you have already got the basic foundation of.

PROFESSOR: So our design constraint-- we're leveling up from planning for randomness. We want to see trade-offs in decision making. So every decision made by the player must have a positive and negative outcome in their play state. So first off, what does that mean to you? What do you think that means? Jenny?

AUDIENCE: Good things and bad things happen when you take steps. So you have to decide whether the good things outweigh the bad things at your current point in time?

PROFESSOR: Yep. Basically it-- opportunity costs. Risk management, future risks, unknown risks. There should be some unknowns and knowns there. So while the players should know that there's going to be some positive and some negative, they might not know the values of those positive and negative outcomes. So there's some kind of uncertainty going on in the game there.

And then some of the side effects-- sometimes when you make a decision, there's going to be an immediate change in player state. Sometimes it's going to be a long term. It's going to chain or combo up from previous decisions, causing problems in later things. So easy way to think about this, again, is of course strategy games. But you're also welcome to apply this to any genre that you might like to experiment with in this project.

So here's some suggested goals. Think of project-- yeah, go ahead.

AUDIENCE: Do we still have to use planning for randomness in this game?

PROFESSOR: Yeah. So there should be some amount of randomness in this game. So it's building onto it. So there should be some kind of uncertainty. It's not the focus of it anymore. So project two and project one were focusing on just that randomness. Project three should have some of the randomness in there. But really, what we want you to focus on is trade-offs.

So that's a tool in your toolbox. Try it out. If it doesn't work, if there's a reason it doesn't work, then don't use it. But there should be some uncertainty there. And again, all this is building up to project four.

So things you should try out in project three-- work with new people. The method we're going to have to put you in teams is going to try to do that. So you'll be working in different teams with different people. These are basically auditions for project four.

Use a new game engine. Did everybody use Phaser? Yeah. You're not using Phaser for project three. So we're going to basically want you to go back to that game engine tutorial, think about the other game engines you have available. We had one team to use Unity, and they had some issues why they wouldn't use Unity. And actually, those issues will probably apply for project three as well. Maybe you don't want to use Unity. Maybe it's too scary. Maybe it's a challenge. Figure it out.

And the last one-- I posted this to Stellar. It's a light read. Games For a New Climate is basically our handbook for project four. Our client presented us with this information. This is basically how games are used for game based learning, for climate change, for talking about planning for future risks, the complexity of future risks.

Take a flip through the book. Read it now. Start it now. Have it read by project four. Again, we don't have required reading here, but you'll have a better game, you'll have a better product if you take a look at this and maybe even do a little bit of research on your own, which is actually going to be part of project four. We'll talk about that later.

But if you want to make a game that does this, you can. If you want to make a game for project three that is a game to help a policymaker understand the need to spend money, time, or resources on disaster preparedness as a result of climate change, feel free. Part of that trade-off design challenge is actually inside of that statement. The uncertainty is inside of that statement. Project three actually would turn into a possible springboard and a way to recruit people for project four. But again, you're not necessarily going to have the same group. So it's up to you to figure out if that's going to be useful for you on this team or not.

All right. And then the hard requirements-- please read this handout on Stellar. I'll actually read the handout on Stellar too this time. Sorry about that.

Maximum play length, again, is five minutes. Again, single player game. User interface tested for legibility and usability. It must use and play audio for the player. And then, like previously, players can pick up and start playing the game with no external instructions. So if there are instructions, which there can be, it must be inside of the game or at least inside of the frame of the web page that you are using as a link for us to play within. And then, of course, must be delivered as a browser game, running on Chrome. And also, only in those engines that w e used in the tutorial.

Deliverables-- so actually, this is Monday the 29th. Wednesday is the 1st. On Wednesday the 1st, we have a guest lecture coming in. Swery65 is coming in to talk to us about his new game. His lecture is probably going to last about an hour. That means you're going to have two hours in class on Wednesday to work in teams and create a low fidelity prototype. It is not something you're required to turn in.

We are asking you to have a playable game on Monday, the 6th. Whether that's digital or paper is up to you, but we highly, highly, highly recommend making a quick, low fidelity prototype on Wednesday in the two hours you have, and then based on that prototype create the product backlog. It's the best way that I've found to make product backlogs. You might find a different way. That's OK, as long as you make one.

But on Monday, on the 6th, turn in the Stellar, your high level design doc, and what your product backlog is. So what are all the features that have been estimated, that have been put in priority order? In class, you're going to give a really quick--

AUDIENCE: Next slide.

PROFESSOR: What's up?

AUDIENCE: You're talking about stuff on the next one.

PROFESSOR: Oh, wow. I'm talking about stuff on the next one. Thank you. That's weird. In class, two minute presentations. Basically, just the core of your game design idea. Let us know what you're making. And then we'll be able to test your prototypes. I think-- let me look ahead. Yeah, so testing prototype is not required on the 6th. But if you do it, please we'll test them then.

We will also test on-- and this is where we actually do want you to have a playable, digital version. Basically, let us know that you have a playable game by October 8. And turn in via Stellar your sprint task list-- basically all the tasks with time estimates that are going to happen between Wednesday, October 8 and Monday, October 15. And the project due is the same kind of stuff that we did for this project-- your game prototype builds, your post mortems, your design change log, updated design document if you have an updated design document. And again, two focus test reports this time. One can be created in class on either the 6th or the 8th. The other one should be created outside of class with external testers.

AUDIENCE: Question.

PROFESSOR: Yes?

AUDIENCE: Is that Monday the 13th or Wednesday the 15th?

PROFESSOR: Oh, my lord. Did I really make that mistake? Can somebody check on Stellar for me? So it should be Monday the 13th, right?

AUDIENCE: No, we think it's Wednesday.

PROFESSOR: Wednesday the 15th is when we're having people turn stuff in?

AUDIENCE: Yep.

PROFESSOR: All right, holiday. Right? Is there a holiday that week?

AUDIENCE: Yeah.

PROFESSOR: OK. Stellar is the right place, and I will update these slides before I post them to Stellar.

AUDIENCE: Let me check on the big schedule. It's Columbus Day. So Monday, there is no class.

PROFESSOR: So Monday, no class. So Wednesday, the 15th. So you got a little bit of extra time. But it's a holiday, so maybe you don't have extra time.

PHILLIP: But if you get it done by Monday, then you can let your code soak a little bit [INAUDIBLE].

PROFESSOR: All right. So we are going to do brainstorming, and we're going to brainstorm in groups that you are not currently working with, so you can meet new people. You're going to get a card. It's going to have a number on it-- one, two, three, five, eight, or 13. I'll hand out the cards really quickly. Go to one of these stations, erase whatever's on the board if you need to erase on the board.

If you're in five, eight, or 13, you're going to have these easel pads. We are going to give you two timed quick brainstorming sessions. Five minutes, small break, another five minutes. When we break, change whoever's writing things down so everybody has a chance to speak. After this, each brainstorm group is going to be allowed to make two pitches to the larger class. What we're going to ask you to do is write a title for the game on a large Post-It, and we'll hand these out. One of these, yeah. We'll hand these out when we get there.

In your elevator pitch, make sure to address the core mechanic of the game and how it's applied to the design constraints. Games from project one that were not selected for project two can be pitched if your brainstorming group says that was actually a pretty cool idea. Let's pitch that too. But it must be altered for design constraints.

And I'll give you a break after that second brainstorming session to come up with these pitches-- about 10 minutes, I think. Any questions about this? Psyched? Pumped? All right, I'm going to hand these out.

[SIDE CONVERSATION]

 

PROFESSOR: Team one, pitch one, come on down. And just like before, you've got about a minute. Describe-- oops, wrong ones. Give us the name of the pitch, the core mechanic, and how this pitch approaches the design constraint. Pitch, go.

PRESENTER 16: So our first pitch is called Dragon's Lair. It bears no relation to the previous Dragon's Lair idea. The idea we came up with is that as a dragon, when you're acquiring gold, the more gold you have, the more heroes want to come in and mess you up to try and steal your stuff. So we thought that there's a fun trade-off there between acquiring more gold and becoming a more powerful dragon, but at the same time having more and more heroes wanting to come in and attack you.

We also thought that just in that, in itself, you don't quite get the idea of meaningful decisions, because everybody's just going to want to be a more powerful dragon and prove themselves as, oh, I can handle more and more knights. So we thought it'd be interesting to have this idea of not just being an enemy to everyone. You can actually ally with some of the villages in the game so you'll be making less money, but then you'd have more people on your side to help you defend. So the trade-off here is between being nice to people in order to get more defense or slaughtering them or just steal their money.

PROFESSOR: Nice pitch. Number two.

PRESENTER 17: All right, so our second game is called caffeine worker. And it's based on the idea that caffeine will pretty much simulate your [INAUDIBLE] where you can actually get more work done under less amount of sleep. But it also tends to have side effects.

So our game pretty much revolves around you are a worker, and you want to get these tasks done. And you want to get these done as efficiently as possible. So we're going to have something like a 24 hour clock. We're going to have night and day. We're going to have a lot of different sort of actions that you can sort of, like, decide on executing, such as you can figure out how many hours you want to sleep, how much caffeine you want to take, and also you can also figure out your eating schedule as well.

So we don't really have the nitty-gritty details, but we imagine that this game will involve a lot of scheduling, a lot of sort of-- I don't know, the trade-offs between sleeping and eating and drinking coffee. But in the end, I think what we want to do is that we want to make this game sort of like a platformer, where you are actual in control of the character and for [INAUDIBLE] your tasks, something you need to go from point A to point B.

But these different sort of attributes, how much caffeine you have over time, how much sleep you have, whether you're eating enough, whether you're happy or not-- those sort of effect your motor skills as well as some other implementations that we have yet to figure out.

PROFESSOR: All right. Thank you. Thank you group one. Group two. Pitch one, category A. Remember, it's one-minute pitches.

PRESENTER 18: All right, so here's the idea. You are an administrator at MIT. And your goal is the management of MIT and promote MIT's ideals and maximize their endowment and all that. And your goal is to carefully trade-off the short-term versus long-term policy. For example, you've got this plot of land. You could lease it to Pfizer for 60 years and get 2 billion straight to the endowment. But then you can't expand it till later.

And do you want to appease the students to get more in tuition? But maybe you need that money, so you raise tuition, but you also get rid of your unpopular flag policy at the same time. So you can play as many different administrators. You can play as, like, Dean Colombo. You can play as Kevin Kraft from the Office of Student Citizenship. You can play as the shady MIT corporation with this weird board of self-voting members that no one really understands. That's our pitch one.

[APPLAUSE]

 

PROFESSOR: What's the name of that one?

PRESENTER 18: MIT Simulator 2015.

PRESENTER 19: Our second idea is build a car. And we thought that you could start out with a limited amount of money, and we will send the car you build after a turn through a simulator. And so you don't exactly know which maze it's going to get. So depending on the result of that, you have trade-offs of how to spend your money, what parts to buy, and build a car.

PROFESSOR: Great. Group three.

PRESENTER 20: Hi, everyone. I'm going to tell you about Fight or Flight, which is from our first project. And if anyone played the paper prototype, it's going to be completely different.

So the idea is that you're playing this platformer, which is a map that has a bunch of separate little rooms. So any given little room might have four or five platforms. It's not really big. And so this whole big map has a bunch of these little rooms, all connected by different passageways. And you can get from different places to different places.

And all of these rooms are potentially exploding. So this is some sort of spaceship, and there's a meltdown. Or, I don't know, this is, like, the tavern. And near a volcano, things are filling with lava, or something. However you want to skin it.

So each of the rooms will give you some sort of warning about whether or not it's about to explode. And then some time after the warning starts, it explodes. And then if you're in there, you're in trouble.

So the trade-offs in this game are that-- so the overall goal is to get somewhere, is to get out, is to get from one side of the map to the other. And in between, there's a whole bunch of other people who want to fight you, just for the heck of it. So they want to fight you, you want to fight them. But the more you fight, the more tired you get. And the more tired you get, the slower you move. And the more slowly you move, the harder it is to escape a room once it starts exploding. So you can choose to fight, and you're probably going to kill them, you could kill the enemies because they're AI written by people in this class. Versus, like, the player who can actually just implement strategies and things.

But if you do go and have fun and try to kick everyone's ass and you succeed at that, well, then you're panting in the middle of a room that's about to explode. So fight or flight everyone.

PRESENTER 21: The second one is Jigsaw World, another platformer where you are inside a jigsaw puzzle, where every time you get to the end of a block section square thing-- they're oddly shaped because it's a jigsaw puzzle-- you get a choice of a new set of tiles to put on the end of the one you've already gotten. Sometimes you have to go back and pick one up off the beginning of your puzzle and put it at the end.

And various power-ups make certain ones incompatible, like being able to fly. That means you can't swim. Being able to swim means you can't jump-- all those kinds of things. You're kind of creating your own world that you then have to navigate differently. Oh, yeah. And deconstruct it. You never get to see the whole thing at once because it's falling apart as you're taking it and moving it somewhere.

PROFESSOR: Thank you. Group five.

PRESENTER 22: So our first idea is a game called The Gun Wars, in which you're managing a defense company. And you're trading off who you're going to sell your product to amidst a bunch of different clients. So you could have somebody go up to you, you get some information on who they are, say, hey, this is James, seems like an OK guy, and he wants to buy, like, 10,000 missiles, air-to-surface missiles or something.

You have to surmise him, figure out if that's somebody you want to sell to, figure out at what price you want to sell. And then there may be some consequences for that. Maybe you sell to Jimmy, and then he launches an attack on some country you like or don't like. But more importantly, maybe he does something your other clients like or don't like. And so you lose other business.

Or you get new business from people that are Jimmy's friends and realize they can buy weapons from you. So it's sort of a social responsibility game. You're a defense contractor. You're managing some pool of money, trying to make money off of contracts. And the trade-offs come with who you're deciding to buy and sell from.

PRESENTER 23: Our second idea for the game is Bullet Craft. Bullet Craft is a fast-paced, top-down shooter game that follows the simple formula, the classic formula, that the player controls the ship, moves around, [INAUDIBLE] that's coming at him, and shoots the enemies that spawns from the top of the screen.

Well, you might ask, where does trade-offs come into play for Bullet Craft? So there are actually various ways we can augment the game play so that we will incorporate trade-offs. For example, on the micro level, we can have ammo limits or overheating guns. And we can have a fuel limit which if the player moves, he consumes fuel which pollutes the environment, and the enemies become stronger because of that pollution.

At the macro level, we could also have the player choosing different types of weapons, spending their money on different types of ships and even a crew. What I like about Bullet Craft is it is very easy to implement, and it's guaranteed to be fun, so that if we make Bullet Craft, we are sure that we will be able to make a successful game.

PROFESSOR: Group eight.

PRESENTER 24: So the first idea we had is Daydream Inc. So in this game, you're like a regular office worker. And you have to try and not get fired. But the goal of the game is to succeed in your daydreams. So there's basically two mini-games within the game. There's surviving the office life, and then there's also your daydreams where you're fighting your boss or something.

And it's interesting because you use tools from the office to build weapons for your daydreams. So you might get a stapler and a rubber band and make a staple gun or something for your daydreams. So you have to spend both time and research from the office life in the daydreams without getting fired, so you can eventually win the game. Also, if you become CEO in the office life, so if you do really well there too, you lose.

PRESENTER 25: So our second idea was Score High. So basically, you're an MIT student. And you have a list of maybe three classes. And you have some stats-- like, your food, sleep, happiness, health. And the thing is, each of your classes has PSETs and tests. And you have to get to the tests on time, and you also have to turn in your PSETs on time.

And so how do you do that? So you run around the maze, and you have to get to the right building at the right time. But you also, when you're there, actually have to take the tests. And depending on-- you pick up different items. And say you drink 10 cups of coffee, you're really jittery.

Instead of seeing all of the options for the multiple choice question, suddenly you can't look at it, and you only see one question. And somehow you miss the back of the page. So you fail the test, right?

So the whole game is about choosing-- you know, when am I going to drink coffee? Or maybe I'll buy my friend coffee, and he'll give me the PSET answers so I don't have to spend five minutes doing the PSET. And managing those trade-offs while also running around this maze and getting everything done on time. And if you fail any of your classes, you lose.

PROFESSOR: Group 13, come on down.

PRESENTER 26: Our first idea is Ghost Face. The title's a working title. The idea is you're in a maze, actually a maze. And you have very limited visibility. You can only see a certain radius that is much smaller than the actual size of the maze. And there's ghosts coming at you.

And basically the idea is to get to the other side of the maze, solving the maze, but you only have limited disability. So you have to explore the maze and remember which path was a good decision and which path wasn't. So you have to trace back a lot.

You can also add in more things. Like, you may have a certain number of beacons, light beacons, that you can place in different areas, but a limited number of them. So you want to be-- you want to make a decision as to what would be a strategically good place to place a beacon and reveal an important and critical part of the maze so that you can see more of the maze. So that's our first idea.

PRESENTER 27: So our second idea revolves around DNA. We haven't found a good title for it. But the idea is, let's say there's an organism. And you have a certain set of diseases that you want to try to get rid of. And your goal is to somehow go around finding other organisms that have their set of traits. What's the diseases that you don't have, some other diseases that you have.

And play a game of chance-- so whether it's worth it to spend your time and energy eating or mating with the other organism and seeing if those genes come across to your [INAUDIBLE]. And the trade-off is-- the trade-off is, do you want to mate with this organism or not? We're still working on the details of this, but the idea is this gene competition [INAUDIBLE].

PRESENTER 28: And random mutation.

PRESENTER 27: Yeah, random mutations [INAUDIBLE]

PROFESSOR: OK. Thank you. All right. We're actually really good on time today, so you'll actually have some time to work in your teams after we get you all sorted out.

So we heard about Dragon's Lair, Caffeine Worker, MIT Simulator, Build a Car, Fight or Flight, Jigsaw World, The Gun Wars, Bullet Craft, Daydream Inc., Score High, Ghost Maze, and DNA.

12 ideas-- actually, a few of them could probably combine pretty well together. So we're not really throwing the ideas away. We're really just trying to get together into groups of six around a base idea we can start with. So if you've got a game that you're really, really excited about working on, come right down and put your name on it. And make sure your Post-It has your name and the game engine you used in the tutorial assignments.

Let's see what we got. All right, raise your hand if you still have your name tag, your Post-It. One, two, three, four. All right. We have Caffeine Worker only has one person on. [? Zigamantias ?], you have your name tag back. Nope, sit down. Just sit down.

Jigsaw World. Sorry, Kathleen. All right. We've got one, two, three, four, five, six. DNA is done. So DNA is Derek, Eduardo, Ava, Harry, Trisha, and Lauren.

One, two, three for Ghost Maze. Three for Score High. Two for Daydream. None for Gun Wars. Two for Bullet Craft. Three for Fight or Flight. One, two, three, four for Build a Car.

Two, three, four, five, six. Oh, cool. MIT Simulator. Don't get me in trouble. Norman, Jordan, James, Peter, [? Szeun, ?] and Sam.

Bullet Craft and Daydream-- first off, does anybody who has their name tag on them, are they all excited about either of these two games?

AUDIENCE: I am.

PROFESSOR: You are? Is your name-- do you have your name tag in your hand? OK, raise your hand if you have your name tag in your hand. All right, come down here and put your name on a game.

I'm going to get them all. I think we have enough to get every game to six. 10, nine, eight, seven, six-- hey, five. Cool. Thank you.

All right, Fight or Flight, Bullet Craft, Daydream I think are all either going to go away or combine somehow. Score High, one, two, three, four. One, two, three, four, five on Ghost Maze. Just needs one more person.

Five on Build a Car. Just needs one more person. Four on Dragon's Lair. One, two, three, four, five, six. OK. Daydream is gone, Bullet Craft is gone, Fight or Flight is gone. Move yourself to another team. All right, Ghost Maze has six and is done. Score High has five, six. Done.

AUDIENCE: Everything is full, isn't it?

PROFESSOR: Yes. So put yourself on one, two, three, four, five, six. Put yourself on any of them. Five, four, three, two-- thank you.

So here are our final teams. We're going to do one last shuffle. If anyone is like, I don't want to really be on that one, they can move to another. For Dragon's Lair, we have Roy, [? Mikael, ?] Liz, Zigamantis, Devon, Caleb, and Kathleen. You have a good mix of Unity and Flixel, so I imagine you might use Unity or Flixel.

Build a Car, we have Rodrigo, Anderson, Matt, [? Taj ?], Jeremy, and [INAUDIBLE]. We have Unity, Unity, Unity-- three Unity, three Phaser. I wonder what you're going to use.

Score High, six. Miriam, [? Sen ?], Megan, Kevin, Sabrina, and [? Zinue ?]. And we have Haxe, Haxe, Flixel. Oh, wow, lots of Flixel. And two Unity. So maybe one of those.

Ghost Maze, [? Jutoshka ?], [? Salaam ?], Daniel, Kevin, Justin, and Rachel. And Unity, Unity, HaxeFlixel. Ooh, it's going to be kind of tough. We've got three Phaser, two Unity, and one HaxeFlixel, so that's going to be a hard decision to make.

DNA, we've got seven-- Jenny, Lauren, Ava, Tricia, Harry, Eduardo, Derek. HaxeFlixel, HaxeFlixel, HaxeFlixel, Flixel, and one Unity. So probably one of the Flixels.

[GROANING]

 

You decide. MIT Simulator has Unity, Unity, Unity, Unity, Unity, Unity, Unity. Four Unitys and two Phasers, so probably Unity. And that is Norman, Jordan, James, Peter, Sam, and [? Szeun. ?] We have how many students are not in class today? Five or six students not in class today. They are going to have to-- what's up?

AUDIENCE: Make them a team.

AUDIENCE: Game to learn how not to be late.

PROFESSOR: That's a good question.

PHILLIP: [INAUDIBLE] simultaneously on Wednesday, that might be possible. But if a few of them don't come back on Wednesday, that may not work.

PROFESSOR: So teams will be finalized on Wednesday. These are the teams as they stand right now. You have 40 minutes to meet as a team to figure out if you all match schedules, to talk about the idea you just pitched, and make a really quick lo-fi prototype, or write down that page that you just said out loud on the spur of the moment.

Figure out what is that game that you're making. Work on that vision statement. And feel free to grab your things and put your names on it if you like.