Description: In this lecture, the professors introduce Project 2 of the class and discuss digital prototyping.
Instructors: Philip Tan and Richard Eberhardt
The following content is provided under a Creative Commons license. Your support will help MIT OpenCourseWare continue to offer high quality educational resources for free. To make a donation or view additional materials from hundreds of MIT courses, visit MIT OpenCourseWare at ocw.mit.edu.
PROFESSOR 1: So today is all about you. We are introducing Project Two. We are starting off with the Project One pitch presentations, then we're going to have prototype demonstrations. The idea is that everyone in class should have heard about all the games that were made and should have at least seen all the games be played. it's going to be kind of difficult, but we're going to try to do that.
After that, we're going to form teams. So we're going to choose a few of these games and form teams around them. And then after that, assuming we have time left, we're going to work in our new teams. You're going to rewrite that Project One vision statement and you're going to modify the paper prototype on volume here has a group just to kind of see what the mechanics were and what you're going to have to do for Project Two.
So starting off, Project Two-- it's another low fidelity prototyping, but this is more digital. So you're going to actually make a digital game. We're asking to create this digital prototype in a short time frame. You had about a week to do Project One. You're going to have about two weeks to do Project Two.
There will be some of the work done in class. Unfortunately, it's not going to be the programming. That's going to happen outside of class. In class, we're doing a lot of the meetings and a lot of the project management stuff in class. And we'll be walking through a lot of that.
You're going to be basing that game off of a Project One game. And then yeah, we're going to integrate project management concepts into your process, and we'll be talking about some of that stuff starting Wednesday.
Extra goals-- you're going to be working as a team for the first time using a common game engine. So hopefully some of the lessons from that game engine tutorial we did last week work out-- I think that was last week, yeah-- work out for you.
You're going to be doing version control, so it looked like we had everybody able to use some kind of version control with all those engines. That's a good sign.
And then you're also going to be managing your time commitments. This is the first time you're going to have six people on one project for this class, and then you're going to continue like that for the rest of the semester.
So coming up with strategies on how to work with each other, how to maximize the work you do in person, and what you can do when you're not next to each other, when you're working from your dorm room, from a study area, things like that.
So the deliverables for this one-- today, we are going to do this workshop, this team information workshop. On Wednesday, we're going to be work shopping the product backlog, and you're going to be turning in to Stellar-- actually, I meant the vision statement. But on Wednesday, by the end of class, we'd like you turn in the Stellar an updated vision statement.
So take the statement you were working on for Project One, modify it based on the new team you have. You'll do a little bit of that today in class, and then you'll turn it in by the end of class on Wednesday to Stellar.
The following week, you're going to turn in to Stellar before class starts a product backlog based on the workshop you did the week prior. And in class, we're going to talk about sprint back task lists.
So you don't know what a sprint task list is right now. You don't know what estimates are right now. You'll be working on that on Monday, and then each team will give a short presentation to us about the work that you did.
On Wednesday you'll turn in that task list you created. And in class on Wednesday, we'll be playing all the digital games. So you have to have something running by Wednesday at 1:00 PM. It could be running and broken. You might not get much good feedback out of it, but it must be running by Wednesday at 1:00 PM.
And then the following Monday, the project is due. Yeah, really, really short. On Stellar you're going to turn a whole bunch of stuff. All of your games should compile out to HTML, either be playable on a website or use a website plug-in like Unity or Flash or whatnot.
So there is more details in the handout in Stellar. I updated that this morning, so please take a look at that once your teams are formed. So it's probably one of the first things you should do is take a look at those requirements. Again, you'll need a written a written postmortem from each of you.
We'll ask for a design change log, which your first entry will be today. You'll need an updated vision statement if anything changed from the one you turned in on whatever I said it was, Wednesday. If anything's changed, you'll turn it in again. And you'll be doing focus test reports. So we're doing some focus testing, some testing in the next week. And then, you'll also do a postmortem presentation.
And so, this presentation will actually be five minutes per team. The requirements are on the handout, and we'll talk about it a little more later in the next week or so. But basically, it's tell us what went right, tell us what went wrong, tell us what you learned. We don't necessarily want to see the game being played. We want to see what you've learned from the game, so highlight that with screenshots, with video, stuff like that.
All right, so this is what we're doing for the next-- we've got 15 slots-- so for the next 15 or so minutes-- elevator pitches. Why are we asking you to do an elevator pitch? If you can succinctly describe your game in one minute, it's probably pretty well scoped for Project Two.
Also, you probably have a handle on what you're actually making. You know what the game's about. You can describe the game to another person. To us that means, great, that project is probably going to be a Project Two project. If you have a little bit of difficulty describing it, if you go a little bit over time, we're going to allow you to go over time, but don't. Why do I even tell you that? I just messed everything up, didn't I?
But if there's some issues going on with that, that'll let us know a little bit about the scope of the project. Don't show us the game, don't use visuals, don't use laptops. You're in an elevator with an executive. They said, fine, you got a minute of my time. Tell me what you're trying to do. Bam, convince them that your game is cool, depends on what your game does.
In this particular case, we want to know why it's about planning for randomness. Remember, that's our design constraint for the Project One and Project Two. What about your game is planning for randomness? What is the core piece of game play in it. Remember in your vision statement, in one of the versions, we asked you for 20 or 30 seconds of game play. That's a great thing to put in a pitch.
So you've got all the material, just take your minute, go. Afterwards, we're going to do demonstrations, and I'll bring that slide up later. But basically we're not going to just rely on you talking about your game.
We're going to be able to see all the games being played. And we're going to, again, try to get everybody able to see all the games being played if they haven't been played already. And after that, we're going to try to form teams, which is really hard. So that comes later.
All right, any questions before we move on? Any additional comments from y'all? Oh yeah, remember to check handout 2 on Stellar. So yes. by the end of class today.
All right, so first team is Lazy Beaver. Again, you only need one person from the team to come up if you don't all want to come up. Come up here, stand about right here, there's a microphone right here. It'll capture you-- talk. Lazy Beaver, come on down.
STUDENT 1: All right, hi everyone. Our name is called Lazy Beaver. Lazy Beaver is a survival game in which players must take on a chaotic world full of surprises. These surprises come in the form of random environmental events such as hurricanes, predators, and even Ebola.
The player takes one action every day which either replenishes or depletes their finite resources with the objective of surviving the elements in order to build a set number of dams. Since the environment is so unpredictable, the player must carefully plan their actions or risk losing by running out any of their resources. This lets the player either choose to be risky or play it safe.
The digital prototype will maintain the same core gameplay of choosing actions, reacting to the environment, and preparing for disasters. We will take the opportunity to carefully balance events and resources to tune the difficulty to appeal to all types of players.
Lazy Beaver should move on to Project Two because during testing players found our game both delightful and difficult. Also, the technical scope of the game is fitting for Project Two's timeline, and the mechanics of the game are well suited for the preparing for randomness theme.
PROFESSOR 1: Dragon's Lair. Come on down.
STUDENT 2: Hello, everybody. Our game is called Dragon's Lair. The game's point is you are an adventurer and you come into a dragon's lair. You have 20 actions you take, but after every time you take action, the dragon destroys one of them. The point is you want to try to collect as much gold as possible.
The game ends when all the parts are either discarded by you or destroyed by the dragon. And then you count up how much gold you got at the end. The game is lost, thought, if you run out the dragon's patience, because the dragon can only put up with you being in its lair for so long.
The game would be good for Project Two because it has a small scope. The only thing we want to do for the digital prototype is get some artwork in there, a little bit of ambient music, add a timer so that people aren't taking too long at each turn.
And add a high score table because the game has high replay ability value. So we want people to be able to see their achievements. People found it fun and it was difficult, and so yeah, we think it's a good game.
PROFESSOR 1: Great, thank you.
Fight or Flight, come on down.
STUDENT 3: Why is it that in every Indiana Jones movie ever there's a temple that gets destroyed. A temple gets destroyed because it turns out that running out of a temple is really, really fun.
Our game-- Fight or Flight-- forces the players to run from a randomly but not. Environment that gets randomly destroyed behind or in front of them and balance their actions between fighting their pursuers and just running as quickly as possible.
It works for Project Two because it's fun, dynamic, and actually pretty simple at its core. Thank you.
PROFESSOR 1: Plunder Winds.
STUDENT 4: Hi, everyone. Our game is Plunder Winds, a pirate themed treasure hunting game. Our game is based around three simple core mechanics that interact with each other. The first one is a random encounter mechanic, which controls the probability of finding treasure. And you can affect this as the game progresses.
An exploration mechanic, which tells you what the risk level of nearby encounters will be. And then wind mechanic, which limits your moving and forces the player to make strategic decisions about where they move.
Our game's digital prototype would have the same core mechanics as our paper prototype, but it would be faster and more graphics so it'd be easier for players to pick up. We could also add on unique encounters and abilities to improve replay ability.
So our project should on to Project Two since it's easy to implement. And also, throughout play testing, we found that players found it easy to pick up, but also found it hard to master. So you should come join our crew-- Plunder Winds.
PROFESSOR 1: Thank you.
PROFESSOR 1: Blind Aliens. WT.
STUDENT 5: It's a working title.
PROFESSOR 1: Uh-huh.
STUDENT 5: Hi, everyone. We're Blind Aliens. Our game is Blind Aliens. The premise of the game is aliens, blind aliens, have invaded the Earth and you are one of very few surviving humans. And the game is very simple, it's in a very small room. There's aliens that come in through random gates around the edges. And they randomly roam around searching for you, but they can't see you because they're blind.
So you have three options. You can sneak away very slowly. Or you can run very fast, which is loud. Or you have a gun, you can shoot at them, which is also very loud and you'll be risking getting discovered and eaten alive. So the game should move on to Project Two because it's very simple. During testing, we found that people found it very engaging in that it was not boring at all. So, yeah. Thanks.
PROFESSOR 1: Next up is Live On.
STUDENT 6: Hi, everyone. Live On is a survival themed game that takes place in a hexgrid based world. The player needs to stay alive and move from the start to the goal. There are four type possible terrain to raise-- river, mountain, plain, and forest-- each with simple costs and benefits.
The key mechanic for the game is that at every turn, the player needs to choose which tile to move on to next based on what information he has available. So the player only has limited vision on one hand is important to choose grids that will lead to a good location for the next move. On the other hand, the player need to plan for the [INAUDIBLE] tiles that he can't see at the moment.
The game will be a good project for Projust Two because, in my opinion, not only does making plans based on incomplete information and random events lies at the heart of the games mechanic, we implement a good set of tradeoffs and balances between the different terrains that serve to offer the player meaningful, consequential choices of which path to go. In the digital version, in addition to the core game play, we seek to add randomized map generation and multiple characters with different abilities to further enhance the gameplay. We'll stay with a 2D game, the grid representation of the world, and turn based actions, as opposed to continuous work over the time game plan. Thank you.
PROFESSOR 1: Beaver Evolutions.
STUDENT 7: All right, so Beaver Evolution is exactly what it sounds like. You have a colony of beavers, and you have to fight against nature and evolve your beavers over generations to survive against the trials and tribulations that nature will throw at you.
The core mechanic of the game is based around making a choice between three different options for every generation. You can either build your exam, popular beavers, or choose an evolution traits help develop you colony to fight against the natural disasters that will try to hinder your progress.
Our game is going to be a great game for Project Two because we have a lot of ideas for implementing it in a real time world, currently as a turned based game were you make a choice and then you respond to a natural disaster.
We think that it'll be great to implement a real time game because you will be able to respond to natural disasters and allocate your beavers to either work on you dam or work on evolving. And you have to have quick reflexes in order to survive through the game and win the game. Thanks.
PROFESSOR 1: Comcastic.
STUDENT 8: Hello. Comcastic is a cable monopoly simulator where you are trying to place your oddly-shaped service centers into an existing city landscape. Your goal is to make as much money as possible while caring about your customers' satisfaction.
STUDENT 9: So in the digital prototype we're basically going to have a grid where all the homes and businesses are laid out, and the user will see the inconvenient-shaped pieces for your service centers. And then, when they select a center, they will see how many people it can serve and the price that it'll cost them each month. And then, they will need to place these on the board.
STUDENT 10: We think this is a good project for our Project Two because we've found that playing the game and creating the game is both very simple. And we found that it was really engaging. We had a few random testers kinda describe it as a strategic version of Tetris, basically.
PROFESSOR 1: Sparkly Redemption.
STUDENT 11: Boosh! You're a lady with only one arm, and your other arm is a gun that shoots things. You're a disgrace in your nation and your only chance at redemption is to get all of the sparklies.
However, the place where all the sparklies are are filled with monsters. And depending on which sparklies you pick up, sometimes you get better arm gun powers, but sometimes the monsters change their behavior and you have to adapt to that, or just be strategic about picking up your sparklies.
Our game is super cool because, even with our simple paper prototype version, people had a lot of fun with it. And the sort of game that's pretty easy to implement at a most basic, just fun to play stage. But then it's good to add stuff on top of it, like extra monster behaviors and super shooty arm powers. Plus you're a lady with one arm and a gun that shoots thing, which I think is cool.
PROFESSOR 1: Modgi Dice.
STUDENT 12: Hey, everyone. So Modgi Dice is a math puzzle game like Sudoku or 2048 where the user navigates a dice around a square grid, rolling the dice one side at a time, and adding that side of dice to the square.
The cool mechanic of this game is that each square is modular 7 and the goal of the game is to reset all of the squares to zero. This game will work well for Project Two because it is a fast paced mover game kind of like 2048. And you can move those around very quickly while also having to plan out your moves. Thank you.
PROFESSOR 1: City Evacuation.
STUDENT 13: In City Evacuation, your goal is to escape the city because there's an earthquake in your city. And you have to do that while saving three friends along the way. And what will happen during the game is you might get hit by an explosion, or abridgement fall down, or you might have some [INAUDIBLE].
STUDENT 14: As far as the digital scope, we're going build a 2D game that's dependant on your dice roll and will generate random disaster cards that will come up and the hardest part will be the graphics.
STUDENT 15: We think this is a good project for number two because there's a lot of randomness, but we also give the player tools to plan and strategize around that. Additionally, people thought it was really fun to play. And though it's sort of simple to implement at the beginning, we think there's amble challenge in the graphics, the sounds, and the animations that can be built on top of that framework.
PROFESSOR 1: Thank you.
STUDENT 16: All right, the next 12 hours, our game is called Shoutkey.com/doorway. Here's the idea-- you're playing World of Warcraft-- sorry, Warcraft 3-- and you see that guy with the second and a half ping, and you get really jealous. Man, I wish my ping were that high. So then you start encouraging your pet to chew on your ethernet cables, get those dropped packets. You really want that slow, unresponsive feel.
So we take that desire and mix it with a platformer to make a really frustrating game where as you play it, your controls become increasingly unresponsive. And I think it's hilarious and fun. Yeah, it's fun. Yeah. Shoutkey.com/doorway.
PROFESSOR 1: Thank you.
STUDENT 17: So, Lost Underground. You are a traveler and you fall down a hole, and you get lost in an underground mine. So the goal of the game is, equipped with some bombs-- infinite amount of bombs, because that's just how games work-- you're supposed to escape from the underground by planting bombs and trying to move through barriers that you can clear.
The randomness comes in with the addition of some of ghost bombs that will be floating around. And they will not chase you, but they would go through you and would explode at random moments.
So you have to plan around getting to the end of the level and also not dying before you get there, which is common in a game. This is a good project because it's simple and it's sort of reminicent of Bomberman, which is a great game. So, yeah.
PROFESSOR 1: Thank you. Dice Traders.
STUDENT 18: Dice Traders is a multiplayer card game where you play a card combo in order to score points. Importantly, you can trade your cards with other players in order to improve your combos. But if you do that, you might be giving your opponents what they need to win.
And so this introduces a lot of strategic considerations about things like what your opponents score is, how large there hand is, and so on and so force. And you have to keep all of that in mind when you're playing. And our playtesters really enjoyed the complex strategy that arose from these simple elements.
It would be good for Project Two because the mechanics are very simple, which would make the game easy to implement. However, it is designed as a multiplayer game, so it would require some sort of AI.
PROFESSOR 1: Thank you. And, last but not least, Gravity Shift. That is the last one, right? Nobody else? All right.
STUDENT 19: So our idea was for a puzzle platform with the following characteristics-- it's a basic platform, you have a guy on one side trying to get to the other with a bunch of platforms. Unfortunately for you, the platforms are all spaced so that it's completely impossible to reach them fortunately for you, you can place a number of blocks anywhere you want on the stage.
Unfortunately, again, they all cost points and you'll lose points if you place them. And every time you land on a space, it'll disappear. The twist is, once you get to the end of a stage, everything will rotate 90 degrees.
All your platforms will become walls and vice versa and you'll have to make it again. If you weren't ahead, then the second part of the stage will not possible, which is why it requires the actual thinking ahead to solve the challenges.
The reason that this would be a good idea for Project Two is because it's a pretty basic idea, but it's actually a deceptively difficult game, and it's really easy to make a stage that's really hard to solve.
PROFESSOR 1: OK, that was really good, you all kept to under a minute. Next up, we're going to take five minutes, set up your games, try to put a lot of space around where you're set up. I know it's going to be hard. But put enough space around where you're set up so people can watch what you're doing.
Take one of these Post-its and-- how the hell do these work? There we go. Oh, yeah. Take one of these Post-its, put your name on it wicked big, planted down on your table so we know what we're looking at. So set up your games, all the stuff that you might need is up here in these two boxes.
The goal is to make the [INAUDIBLE] geological center. So you roll the dice--
PROFESSOR 2: All right. It's about time, so thanks everyone. And first of all, all of you have playable prototypes. So for Project One go you. You were totally there. A couple of things that I wanted to say about all the projects-- actually we expected that a lot more projects were going to be vastly out of scope than we actually got.
A lot of stuff that we saw here could actually just be fine for Project Three. A lot of games that we saw here, once you're a little bit more comfortable with the technology and the build process-- and in some cases, it's going to be just the efficiencies of knowing the people on your team a little bit better-- you'll be able to execute any of these games for something like Project Three.
But we would like to actually guide this next step where we move from Project One to Project Two a bit of a better. So we are going to cut a couple of projects, just to make the team building process go a little bit faster. Otherwise, having to select which one of the 15 projects that we're going to carry on is just going to take way too long than we have class session.
But we didn't do it completely arbitrarily. We're going to talk about our concerns. If you're one of those games that we're going to cut, and you really, really want to do that for Project Three, I want you to use the time over Project Two to think over your design and see how you will address all of these concerns while you're working on somebody else's project too, because we saw a lot of really, really good stuff here today.
Let's see, so a couple of games that we're cutting. Gravity shift we are going to cut that because the randomness isn't really integrated into the design at this point in time. Again, think about it, figure out how you would do that for Project Three.
I actually had a concern about the UI of the game, because a lot of these games-- sure, some of you are working in Unity 3D-- that seems to be a game that UI wise seems to suggest that it should be a 3D game, because you need to know what the sides of the dice are before you roll things.
But how do you convey that to a player in a way that's not going to have them to deal with a camera? And you could also do it in 2D, but then how to convey that information to the player?
PROFESSOR 2: Yes.
PROFESSOR 2: Oh, sorry. That was the feedback I had for Modgi Dice. My mistake. Sorry, I did, in fact, get that mixed up. For Gravity Shift, the UI problem was how do you convey to your player which way things are going to shift next? Right?
Is it relative to the player, or the relative to the level? When the gravity shifts, are you rotating the entire level or are you rotating the players. Now the player's falling sideways on the screen. These are all like big UI challenges. Assignments we actually happens to be about UI, so that's a good time to be able to tackle that.
So think about that. Sorry-- sorry to Modgi Dice.
PROFESSOR 1: For project three, though, for that one, still bringing in the randomness and actually bringing in the design constraint for project three will be important for that one.
PROFESSOR 2: Yep. OK, then for Final Flight and Dice Traders, we have very similar feedback. Right now, your design is specifically-- the fun of your games are really in the multiplayer right now. That is absolutely fine.
In fact, they are really, really solid game designs. The problem is that project two is really short and AI is time-consuming. It's not necessarily hard. It's just going to take a lot of time to work on. So we're going to say let's not do that on project two. You might want to save that for our project three.
Finally, for two more games, for City Evacuation and Doorway, actually, technically, both games are feasible. I am actually fairly confident that the games that you showed today could be done in the time span of project two. However, I feel that a lot of the fun in those games comes in multiple levels-- being able to get different environments and different scenarios. And that's going to be very time-consuming, which you don't have time for in project two.
So it's an evaluation. It's kind of like the size of your level and all of your elements that you've got in it. It's just going to take a lot of man hours just to be able to generate one map, let alone multiple maps.
Doorway, it seems to me that playing through one round of the game on a computer can go through pretty quickly. Actually, where's Doorway? I like to make eye contact. Yeah, there. OK.
It seems to me like playing through a level, at least the first couple of levels, could go through pretty quickly, which is fine. Players like that, especially when they're wrapping up right at the beginning of the game. But that means you have to generate a lot of levels. And that's just a lot of time that you don't have.
So for the rest of the projects, we're going to put them up around. And we are going to ask you to put your names using the little Post-its to show which team you're signing on. But I still have more feedback, because the other games have challenges that you're going to have to overcome too.
Dragon's Lair, there, so much information, so much information for players to have to understand what's going on. How are you going to convey that over to a player? The good news, your information's relatively static. It's not like you have numbers changing in the middle.
[INAUDIBLE], you do have numbers changing in the middle of the game-- so many numbers, so many little variables and factors. So how are you going to convey all of that information to a player? So you have a UI challenge there.
Beaver Evolution. There's a-- Beaver Evolution? Beaver Evolution. You have a range of possible bad things that could happen to a player. How do you explain that to the player before it actually happens to them so that you can sort of like anticipate and plan, right?
You could say, oh, well. They'll play it through once, and then they'll die, and then they'll restart the game. That's not a great solution. Think about something better than that.
Comcastic-- Comcastic, very specifically is a UI problem, because how are you going to show the players what they're about to put down on the screen, and then show them the consequences of what they've just put down? Because your game is all about how do I rotate this thing and then figure out where it goes and what's going to be the outcome, your problem's mostly user input-- how to get user input in game.
And Modgi Dice, I already mentioned it. How do you do this in 2D? It's-- yep? Is that a hand? Oh, sorry. I thought you were putting up a hand.
How do you explain to the player if you rotate it, the dice, this way, this is a number that's going to be coming up, versus that way? If you're going to do it in 3D, fine. But 3D's at least twice as long in terms of development time. So you have to keep that in mind.
For Blind Aliens and Sparkly Redemption, you're going to need some art just to be able to convey to players what the heck is going on in your game. The good news is that as long as you have some art, I think you can make it work. But that's going to be your bottleneck. That's going to consume up all of your time.
Things that we feel that can probably work that we're fairly confident is within the scope of this project include Lazy Beaver, Live On. Lost Underground. Some of these games resemble other games that exist, so you already have kind of like a template to work on. For some of the games, the paper prototype really kind of already gives you a pretty good idea of how the computer game is going to work. So I'm not too worried about-- if your game just ran on text, it could still be comprehensible. So I'm not so worried about that.
But so these are the games that we have short-listed. Not all these games necessarily become project two games, because we've got-- one, two, three, four, five, six, seven, eight, nine, 10-- 10. And we're hoping for teams of six.
PROFESSOR 1: Teams of six.
PROFESSOR 2: We do not have 60 people in a classroom, OK? So--
PROFESSOR 1: We have about 47 last time I checked. So about seven teams?
PROFESSOR 2: About seven teams, so that means three of these projects will have to get cut. And we'll probably just cut them based on whether they have enough people on the team, which means then the people who have signed up on those teams will have to find some other team.
Now, that's going to be really obvious. Once you have your Post-its up there, you're going to see how many people have signed onto each team. And we want you to try to get to a team of at least five. Six is good, OK?
PROFESSOR 1: So team formation. Come on down. Put your name on a Post-it. You do not need to choose the game you were on previously.
Once you've put your Post-it down, sit back down. Sit down. Come on back. Come on back. We'll read off the names and we'll see how this is going. Come on back. Come on back. Come on back.
Did you put your name down?
AUDIENCE: What's up?
PROFESSOR 1: Did put your name down?
AUDIENCE: I did, yeah.
PROFESSOR 1: Then sit back down. Sit back down. Sit back down, back down.
AUDIENCE: Can I add my name if there's already six on something?
PROFESSOR 1: Yes, you can. It just means you're going to get moved or somebody's going to get moved.
OK. If you're not decided, you can sit down with your name, too. All right. Everybody's down? All right. Lazy Beaver, sorry to say. Maybe we'll see you in project three.
We've got three, three, three-- no, wait. That's more than three. Three, three, three and two. And we've got one, two, three, four five; one, two, three, four, five six, seven. The Future-- maybe you're moving. One, two, three, four, five, six, seven, eight, nine-- oh, my god-- ten. We're cutting that with two. One, two, three, four, five, six.
You're OK. One, two, three, four, five. All right. So Blind Aliens is set with Roy, [? Mikael, ?] Miriam, [? Shalam, ?] [INAUDIBLE], and [INAUDIBLE]. Apologies if butchered the name. Blind Aliens, you're done.
Where there any other sixes that I'm missing? No. OK, so the big ones, Comcastic-- one, two, three, four, five, six, seven. We need at least one to leave. Is that you, Sam? Maybe it's Matt. Julia? Sabrina? Anderson, Sean, or [? Tage? ?]
Modgi Dice-- one, two, three, four, five, six, seven, eight, nine ten. Devon, Peter, Caleb, Megan, Jordan, Kevin, Jeremy, Bennett, Derek, Harry. Derek, I said big letters.
You're lucky I'm wearing these. Anybody I just named, come on down. Move. You have a couple minutes to discuss down here. So Modgi Dice, come over here. OK, great, Comcastic, taken care of.
AUDIENCE: [INAUDIBLE] has a problem that it's just so cool.
PROFESSOR 1: You'll get to play it.
AUDIENCE: [INAUDIBLE] us. Look.
AUDIENCE: [INAUDIBLE] on the ground.
PROFESSOR 1: If anybody on these other teams are like, woo, come over to our side.
PROFESSOR 1: Why? Why do you want people?
AUDIENCE: We're all very nice people.
PROFESSOR 1: All right. One, two, three, four, five, six, seven, eight-- I need two more people to leave. Get out.
AUDIENCE: We love you.
PROFESSOR 1: We need some chants. Come on. All right. Modgi Dice, you are now one, two, three, four, five, six. You're golden.
Sparkly Redemption, you've got five. We're going to let you stand for awhile. Lost Underground, you've got four. Beaver Revolution, you've got one, two, three, four, five-- ooh, you've got six. Yay. Making my life easy.
Plunder Winds, one, two, three, four, five. You're cool for now. Dragon's Lair, you've got three. [SIGH] Live On, you've got three. Lost Underground, you've got four. We need one of you to self-destruct. Come on down if you want to self-destruct, or I'll blow it up for you.
AUDIENCE: Roll a die? Roll a die?
PROFESSOR 1: You want me to roll a die?
PROFESSOR 1: Oh my god, I love this. This is the best ever. Ooh. We've got one, two, three that we're rolling. We've got a 6-sided die. How should I do it? One, two, three, four, five, six.
AUDIENCE: But Lost Underground has four people.
PROFESSOR 1: What's up? Oh, you're right. One, two, three, four, five, six. Four. One, two, three, four, five, six-- Dragon's Lair. Sorry.
AUDIENCE: It's chill.
PROFESSOR 1: It's cool. You could do it for project two. Come on down. Move yourself.
AUDIENCE: Were you moving [INAUDIBLE]?
PROFESSOR 1: What's up? Aha. All right, that's six. It's done. Sparkly Redemption, you've been redeemed. One, two, three, four, five. One, two, three, four, five, six. Plunder Winds, you are all set to go, to sail away. How many more of these do I have in me?
We do have uneven numbers. Life is unfair. Randomness, people, randomness. One, two, three, four, five. One, two three. Choose another team, any team, please. Live On, choose another team, any team please.
That's up to them to decide. But they can do it if they want. I don't recommend it, by the way. But you can choose any one of these that's on the board, too.
AUDIENCE: Wait, anything on the board?
PROFESSOR 1: You can choose anything on the board.
AUDIENCE: Wait, not [INAUDIBLE].
PROFESSOR 1: One, two, three, four, five, six, seven-- you've got seven choices, so many. No, too many, too many. No.
AUDIENCE: I got there first.
PROFESSOR 1: He got there first.
AUDIENCE: I want to join this one.
PROFESSOR 1: Were you this one?
PROFESSOR 1: Sorry. You were second. You were so close. So don't choose this one. And don't choose this one. One, two three, four, five, six, seven. You've got Sparkly Redemption. You've got Blind Aliens, Beaver Evolution, Plunder Winds, or Lost Underground. All right. We are done.
What are we doing the rest of the day?
AUDIENCE: We're doing--
PROFESSOR 1: You had two for project one. You've got five for project two I think you're cheating somehow, myself. Yes?
PROFESSOR 3: I would encourage, actually, we ask people to move around because [INAUDIBLE], and we just give people spots to regroup in [INAUDIBLE].
PROFESSOR 1: We meet as teams?
PROFESSOR 3: Meet at their team tags. And then find a place in the room to sit down, re-discuss vision statements, and start planning out [INAUDIBLE].
PROFESSOR 1: So no. Huh, you're right. I don't have a slide for this. All right, so we're going to do exactly as Sara said, which you did not hear but I did because I was listening. Sparkly Redemption, hang out over here.
Actually, before you move, what we're going to do, come down here. Meet each other. Shake some hands. Get to know each other. Sit back down. You've got one hour left today. Talk about your schedule. Talk about your vision statement. Look at your prototype. Work on your prototype some more. Re-write your vision statement, and talk about what it actually means to make a digital version of this game.
So Sparkly Redemption.
PROFESSOR 3: And whatever you do, do not forget to exchange contact information.
PROFESSOR 1: Oh, my lord.
PROFESSOR 3: Email--
PROFESSOR 1: Were you not going to give each other your email addresses?
PROFESSOR 3: Phone numbers, whatever.
PROFESSOR 1: Modgi Dice. Blind Aliens. Beaver Evolution. Plunder Winds. And Comcastic. This is the safe, right?
PROFESSOR 2: That was fast.
PROFESSOR 1: Yeah. No, it's one of the things where you might not be happy, but it gets done.
PROFESSOR 3: Hey, I think you ran that really well, by the way.
PROFESSOR 1: Thank you.
PROFESSOR 3: That was a hard team formation, especially when people had to jump ship.
PROFESSOR 1: I wanted to just put one of them on that one, but I didn't want to be the one placing people in teams.
PROFESSOR 3: Yeah, and I think that's the right way to do it.
PROFESSOR 1: Yeah. What's up?
AUDIENCE: What should we do with the stuff--?
PROFESSOR 1: Oh yes, someone just asked. What do you do with the old prototype that didn't get chosen? Take pictures of it first. Set it aside. Maybe put it in an envelope. And then maybe it might come back for project three, so don't forget about it.