Flash and JavaScript are required for this feature.
Download the video from iTunes U or the Internet Archive.
Student Interview: Lauren M...
LAUREN MERRIMAN: So my name's Lauren Merriman. I'm a senior right now. I'm actually graduating in February. I took this class because I decided I really want to make video games, and this is a good class to take. My team is seven people, and we are mostly seniors.
We made a game about [? cholera. ?] The other team focused on the younger 8 to 13. And we focused on a little bit older-- about 13 and above-- so we could have a little bit more complicated mechanics and text where we needed it. So we didn't really have to rely on figuring out how to make everything really easy to read. So it uses English that assumes someone who speaks English could read and understand very easily.
And our game is a strategy game. It's real time, where the days are-- you have to survive a year and the days are automatic. So you have you go and take care of four different localities, and give them either soap or water containers or electrolytes to help heal them. And later on you get boiling water. And you just have to take care of these four localities for a year.
So we learned early on, the class, you start by your first project is just paper prototype. And then after, you have to make digital prototypes, but they usually expect you to have a paper prototype. And for this one, they expected you to do it however you wanted to. And so we started off with a paper prototype, and we sort of then quickly implemented it digitally. Because there were certain things that doing it with paper would take a long time to make a calculation.
But we originally had part of it was you could see on the screen what the localities, where they were. And then you would try to implement things. But we didn't have a screen to help you select that. And so you'd tell us what you pick, and then we quickly put it in the game and reset it. So that's what we originally did, and it was really hard to do it that way because people going from the screen to a paper prototype, they were confused. And they didn't really see how things interacted.
So then our next big thing was make it all digital. And in the presentation that you saw, we had that original shot of what the game looked like when we had it all digital. And it was just a really poorly designed GUI. And it was hard to read and hard to understand and people were really struggling with it. So I actually was the one who redesigned the GUI, and then it went through a couple of iterations with the new GUI.
So we decided how to make it the most clear, and I sat down and I looked at other strategy games, mostly Civilization. I'm actually not a big strategy game player, so I actually had to go look around and see what other places do. And I stole a little bit from Civilization, and a few other games that just had good elements of design that looked clear and understandable-- even to someone who's never touched the game before. And so that's what I wanted in our game. So that's why we implemented it the way we did. And then the game kind of turned into the way it is now.
So one of the biggest things is I'm not a programmer. So I was doing either design or product management or the scrum master-- is what they call it, which is someone who has to take care of the team and make everything fit together. Whether it's including art and music and coding-- making sure all those elements fit together into one cohesive whole. And so that's sort of the role that I started to do and then really liked doing. At first I thought, on some of these projects, I should take on a coding role to try to force myself to learn.
But I realized I didn't really want to. I really liked doing this role instead. But you learn it's really hard. Especially in a class setting where people aren't really tied monetarily to this class. You can't lose your job if you don't do your job. You can do poorly in the class, but because it's a group thing, you might not do that poorly because the group presented like, this is our game.
And so unless you specifically call out that person, they're still going to get credit for it. And so it was really difficult as the product manager to get people to do what they said they were going to do in a timely manner, and get people to respond to my emails. And so it was really something that you have to get people to understand-- especially towards the end where we didn't have a lot done, and we needed to change a lot-- that there's not a lot of time, and there's still a lot to do. And then when I finally got everyone in a meeting and they all sat down, we talked about this, like, everyone, you just heard it-- oh, that's when that's due?
So I finally got people in gear, and so I wish I could have done this earlier in the semester. It was just this project. With the other projects, people didn't usually fall into that trap as much because it was only two weeks. So two weeks doesn't give you a lot of time to fail. You've got to do it quickly. And but when it was eight weeks, it was a lot of time and so people are like oh we can push this off a little further.
It was really hard. I actually ended up having-- I talked to the professors to try to figure out a way to get my team to listen to me. And it was still really hard, but once you finally get everyone together and really lay it out very clearly, like the clarity is what I was missing. I thought I was being very clear, and this is how things would do. And even with the way I was assigning tasks, I thought I was being very clear and I wasn't. I was really missing concrete details.
I said, guys, implement this idea-- implement that you can take the actions. But I didn't tell them this is how it should look. This is how it should feel. And so when it got implemented, it wasn't what I thought it was. And I was like, this is really disappointing. This is really ugly.
So when I sat down and redid it and then told them exactly what I expected, things got done faster. Because, like we said in our presentation, people weren't really motivated for this game. And so having the motivation and really vague instructions made it that people wouldn't do it until-- you put that off. That's a really hard task. I need to figure out what she expects, and then I need to do it, and I don't really want to. So that's something you put off to the end.
And so when you give people clear instructions, it makes it easier just to do it. Because they're like, oh, that's simple. I can do that really quickly. And so I think that was the easiest way is when you really set clear instructions, clear deadlines, and you can't really punish people. There's no way of slapping them on the wrist when they don't do it. You can just not assign them work. And you move it to somebody else.
And eventually people realize that they weren't getting assigned any work. And they realized just, hey, I'm not actually doing anything for this. Can I have work? And I said, you have to do it by this time, and if you don't, then we're pretty screwed. So really doing that, really making sure you have clear deadlines and shifting the work around so that people who will do the work and can do the work and have the time to do work are getting the work.
And the people who either just are doing the work or maybe don't have the time that week because that also happens, where one week will be really tough. So you shift the work away from them. So you have to be better about-- I think if I had started being better about how I gave assigned work rather than just evenly dividing it, that really would help with the project.
So working with a client was hard because he was unavailable a lot. And the times he did come to class he said, if you have to email me a question, it better be really clear and concise, or we're not going to answer it. And so luckily, in the beginning, we kind of knew what we wanted to do with our game. And so we just went in that direction.
And then whenever Pablo came into class-- Pablo was our main client. We also had Ellie, but she was only in class a couple times, and so we don't get as much feedback from her. So whenever Pablo came into class, he told us what we needed to fix, and that was the biggest interaction with him that we had. At first, we didn't really know who to design it for because they said, we need two cholera games for everybody. And so we were really unsure and so finally, three or four weeks into the project, we talked to the other cholera team and said, what are you doing? Because we're going to do the opposite.
Because they wanted two games that would be for different groups, and so then we did that. We talked to Pablo the next time he came in, and he said, yes, this is what I want. So luckily we managed to guess what he wanted. It could have gone worse if we did something that he didn't want. So if that had happened, and he said, you guys are really going in the wrong direction, I think we would have made sure to email him more. But most of the time, he's like, I like the direction you're going. You just need to fix these sorts of things, so that's what we did.