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.