UAT: How long were you in the industry?

Lynn Understiller:
I began building games in 1979, but did not officially join the games industry until 1995 when I joined Sony. I have worked at Sony Computer Entertainment and THQ/Rainbow Studios in a variety of roles including Character Lead, Cut Scene/Tools Senior Artists/Animator and others. I have worked on over 15 published game titles in my time in the industry.

UAT: Where did you work?

Lynn Understiller:
Sony Computer Entertainment, THQ/Rainbow Studios

UAT: What roles did you fill?

Lynn Understiller:
Character Lead, Cut Scene/Tools Senior Artists/Animator, others

UAT: Game listing (what titles did they work on?)

Lynn Understiller:
Over 15 titles including MX vs ATV (4 revs), Smackdown vs Raw, UFC, Some of the top franchise titles for football, basketball, baseball, and more.

UAT: Game listing (what titles did they work on?)

Lynn Understiller:
Over 15 titles including MX vs ATV (4 revs), Smackdown vs Raw, UFC, Some of the top franchise titles for football, basketball, baseball, and more.

Derric Clark likes to run his classes like a publisher. The experience gathered by the students enables them to learn how to manage and work together in game groups. The skills also transfer to the various aspects of game design, something Derric knows a thing or two about.

Derric has tackled various tasks including computer modeling, programming, animation, artwork and even virtual reality. We spoke with Derric about topics including working with mods versus Torque, the independent game development scene and why unfinished games are not failures.

UAT: What projects are you working on with students in your classes?

Derric Clark: This term I've got two running. The first one is a Neverwinter Nights group who are building a RPG using Neverwinter Nights as their engine, called Fateless. It's a humorous look at not only the role-playing genre, but also the type of people who play role-playing games. It bleeds into the storyline, so you have different play styles that show up. It's a one-term thing; it just started up this term.

The second one [Xenocide] is a RTS group who is currently using the Torque game engine with the 3D add-on. They're doing a spaceship RTS game, so there's no actual terrain. It's all done in space with planets and spaceships, and two races fighting against each other.

UAT: How many students are in each group? How many groups are there in your class?

DC: The Neverwinter one [Fateless] … has six to eight [students]. The Torque one [Xenocide] I believe is about the same, about eight to ten.

UAT: How do the Neverwinter Nights and Torque editors compare to the UT 2004 editor?

DC: Neverwinter uses a toolset called the Aurora toolset. It's been around for quite awhile. Bioware, the company that built it, is really proud of it. It has a full level editor, script editor, dialogue editor and it ships right along with the game-just like Unreal. It's a tool given to the community by the developers, so anybody can make a mod-you just have to buy the game.

Torque is more of a semi-commercial game engine. It's put out by a company called GarageGames. They're really trying to push forward the independent game development scene, so they have this engine which is more of a traditional "buy the engine and build your game" as opposed to modify another game. Then they have these add-on packs, like the RTS add-on packs and things like that. The lead guy in that group [Xenocide] actually bought Torque, which cost $100, and the add-on is $50.

The lead of that has $150 into his engine, but along with that comes full publishing rights. So if you build something, you can actually publish it, as opposed to the mods where you're using Neverwinter or Unreal. Those don't give you publishing rights; you just put them on the Internet and people play to have fun with it. If you actually wanted to publish it as a stand-alone game, you have to go buy the full-engine games and those are hundreds of thousands of dollars. GarageGames is a special little thing there. They're similar to Unreal, but Torque is more stand-alone. It's not an existing thing, and you have to build all of that yourself.

UAT: Speaking of that effort to go back to indie development, what do you think about that movement?

DC: I think it's good. Gaming is big business now, and there's a lot of money wrapped up into it. And that can stifle creativity and innovation a little bit because companies aren't willing to take a risk on this bizarre, out-there game. They don't know if it's going to be commercially successful. So the indie-development scene has a lot more room there. A group can get together and spend $150 and build something that's wacky and off-the-wall, and then it takes off-or maybe it doesn't. But they don't have millions of dollars behind it when it fails and kills a company.

I look at the indie development scene as a good way to get experience, but also push new things into the industry the big developers might not try just because their hands are tied because of the development contracts. It excites me. I love the indie scene; I think there's a lot of room for great innovation.

There're a lot of students now that want to enter the IGF [Independent Games Festival]. It's about time; we've gone too long and not entered. A lot of these guys are starting to look at that as a way to get seen and get known. There's a local company, Flashbank Studios, which does casual games. They won an award through the IGF and they're really involved with the IGDA. It's a really good channel for indie-developers.

UAT: Are there going to be any classes set aside for students wanting to enter contests like IGF?

DC: None of the classes are built specifically to go after the IGF. In the past, classes have set themselves up for particular reasons. We've had classes put together to enter the Unreal contest. I know that a lot of the groups now get together and consider that as part of [submission]. As a requirement of the class we never put it on [the curriculum], but it's something that's on the back of all the students' minds. They're starting to understand exposure, networking and that getting their name out there is very important. It's a great way to do that, so you're going to see that a lot more.

UAT: What kind of instruction are you giving for the projects-more hands-on, or lecture-based?

DC: I try to run mine like a real studio would run. We try to have one class a week where it becomes more of a progress report/brainstorming type of class. It's not me getting up and telling them a whole bunch of stuff to do; it's everybody trying to figure out a challenge, trying to fix this and trying to do that. It feels like a production meeting. The students themselves will also schedule their sub-meetings-like if the art guys or programming guys want to get together. Different classes might have an official meeting time once a week, but they have three to four other sub-meetings.

When I run my project classes like this, I don't run them like a classroom experience. I run them more like a project-production experience. So I give them guidelines and milestones and then I let them figure out [things like], "Okay, here's our task list." Every one of my projects will have a leading person. They'll have an art lead, art director and programming lead, and they actually do a lot of the [list making] and hand that stuff out. It gives the upper-term students in those roles the experience of managing the project, and the lower-term students [experience] in some of the more production-oriented roles. It doesn't run like a traditional class.

I almost try to take a very hands-off approach. I get involved in resources and setting that stuff up. I try to not impose the way I would like to build the game on them. It's their project so I kind of take a standoffish approach to trying to influence the design. If I see them doing something that's going to get them into trouble, I try to guide them and get that stuff set up. Ultimately it's their project, so I let them do what they want to do as long as it's within good production standards, and I just help guide them rather than teach them.

UAT: Michael Eilers has mentioned wanting to bring together the different classes to work on games together (one class doing models, one class do levels, etc.). What do you think of that?

DC: I think it would be great. The problem you run into is communication and the infrastructure to make all that work really well. I've done stuff in the past where I've had a project class running, and I'm also teaching GAM101 (Introduction to Gaming Design) class, and I've had GAM101 students do testing for the MOD class and just make it part of the curriculum. It's good experience for them and it's good feedback. I know we've talked in the past about an instructor here that needs to have people say, "Write a story," or do models. Why not make them so they communicate a lot more? It's an idea that's hard to get because you have to make sure the classes are running. I would like to see more collaboration between the classes.

For the individual students, I think it's good that we link the classes up so that one class goes into another class and there's this flow individually. And also, if you add collaborative classes, it would be really cool. It's just that it's hard to do. That's why I don't like the fact these projects get set up this way. I think the concern Mike has is that if you get too many of these projects running, you're spreading your resources so thin. If I've got modelers here, and modelers and animators for each of these groups, and I've had students that [have said], "I'd like to do this," they have to choose. If you do it more the other way, you use an animation class and they have multiple projects. Linking them together would be cool, but they're hard to set up.  A lot of times, they put in a ton of time and the scary part is the project class has an assignment that is not ready when they need it. Or the students in the other class decide it's not what they want; you're putting in jeopardy the project class because another class didn't mesh together right.

It's a little scary. You don't want a project to fail because the models aren't working. If there's [a problem] in the [normal game classes] like there tends to be now, they just grind it out. They'll put in a ton of hours, but they'll get it to work. [There's] some issues to work out, but I think it can be used well. I think it'd be good for testing and those other smaller tasks.  

UAT: Switching gears, what did you think about the COR project and what they accomplished with their team and amount of time.

DC: They did some really good stuff. They had a tight team. They also had some content experts. The lead programmer used the full-on Unreal engine before-not just the mod version. He knew what it could do. A lot of those members had been on other projects that didn't do so well. And they learned a lot of lessons and fixed a lot of [problems] and were very successful. The team-building and stuff they did online-they had the discussion board on the forum, and every week the team would do something outside of the production-really brought them together. From the production side of the process, they did a lot of things really well, and they had a lot of really passionate people in that group that really wanted to see it do well.

So the combination of all that stuff really made it where a lot of those guys are now starting to get hired and move on. I don't know if any of these projects are going to capture that. My goal is to get people that have never been in a project before coming in earlier, and the upper-term students running the projects that have seen what to do and what not to do. You just keep building upon it, and the ones that become more and more successful learn from each other's mistakes. We've been doing long enough where I think that's starting to happen.

UAT: What about the complaints about projects not getting done on time or at all?

DC: There are two ways to look at it. There's a push for completed work. Completed work is a very good thing and it will look good on your demo reel. I see it as two-sided; there's educational value in a project whether it completes or not. You could make the argument that a project that just explodes, fails and goes down in a miserable wreck. Now that you've been through that, you can say, "Okay, here's a problem. If we fix it, that won't happen again." On the flip side of that also is that on the portfolio side, someone on the forums locally was talking about how their project failed and they have nothing to show for my portfolio now. And another student replied back, "If the project failed and you have nothing to show for your portfolio, you're the reason that it failed." Even with the most busted project, you should still have your work that you did for it. If you did quality work-whether it finished or not-you should still have good work that you can show (models, code, etc.).

The idea here is to find the balance that not only gives them the completed work to show in their portfolio, but also shows the right way to do a project. You're still learning from your mistakes. But in the game industry, everybody's going to be involved in the failed project. Projects fail all the time, and there's a lot of money on the line for those projects and people get fired. I'd rather see a student go through that in the educational experience as opposed to losing their job because of it. Ideally, if we can get it so that projects succeed and complete and also show the pitfalls of development-like, you should avoid this and do that-that's the best of both worlds, and that's what we're trying to shoot for. Not every project's going to make it. Things happen, but were trying to complete more-that's the big focus right now.

I have mixed feelings about it. I'd never want to build a project where the purpose is for the project to fail. That is not the point, but when someone says a project failed, I don't think that's necessarily a fair thing. I think you could say a project didn't go the completed piece, but the experience itself wasn't a failure. There's a lot of good stuff that comes out of it.

UAT: To prevent failures from happening, is there anything you're doing to guide them?

DC: What I'm trying to do is rewrite my own personal requirements for me to get involved with the student projects. I'm actually setting up some prerequisites that the leader has to have [previous experience]-and that can include preproduction work, but also certain classes. We had a class called game production documentation, and we had a class called student production that talks about how to run a project. We have all these classes set up to give you the skills that you would need to get in those positions.

And I personally haven't been really diligent about checking those. I've been more going off of my gut-feeling … and sometimes that can be off. So for me, I'm going to make it so if you want to run a project, here are the classes that you had to have taken. And if everyone in the class has had those, you're going to have an animator who has animation skills and has a management side. That way, I know coming in that if you've been through these classes, you understand how to work this, how to do those production schedule and how to get all these pieces that are going to be needed to make this successful. I think that's going to happen a lot.

I almost see myself as a publisher: [for example], at this date I need to have a playable level; at this date, I need to have preproduction done; I need to have a working model; I need to see the gameplay here; I need an alpha here; presentation material and website material. Then we have goals to shoot for that's going to drive them in the right direction. This is giving them the broad scope of, "Here's what we have to get done," and letting them fill in the gaps of how to get there.

UAT: What skills will the students need for successful completion of the projects?

DC: It depends on the different aspects. I think you have to have the people who can actually accomplish the tasks that need to be done. The skills are going to come from their disciplines that they're signed up for. We have an array of classes here set up to let you hone those skills. If you're an animator, you go through the animation stuff. Also, you're going to need people who can do go from a design standpoint. So that's where all the game classes come in. If I'm going to put somebody in a position in a MOD class or a project class, and their job is level design, they better have that level design class. If there's someone write the production documentation, they should take the game documentation class.

They can easily get the skills through the classes that we have here. My people that are running the group better understand all the sub-jobs. They need to know what animators do and what texture artists do. If I'm going to bring somebody in whose sole purpose is to animate, and that's all they want to do, I'm not going to require them necessarily to have C++ programming skills. It has to be in focus in what they're task is going to be. If we can match those tasks up with the right people, that's going to make everything better.

UAT: When are the due dates for the projects?

DC: I tend to run things on a term-to-term basis. Fateless is definitely going to end this term. I'm not sure about the future of Xenocide. There's more work to be done on that one, I think, and it could become a bigger thing. I haven't talked to them [the students] about where we're going to go with that, and I don't have that information. Fateless is just going to be one-term build; Xenocide could go longer, but they're going to have playable stuff up by the end of the term and an alpha build in a couple of weeks.

There's nothing that says that a program can't run multiple terms. I personally tend to not commit more than one term at a time. It's really hard for me to sit here now and say, "Sure, we'll do that in the spring." I have to make sure that everything's going well. And then the other flip side of that, I almost want the sense of urgency sometimes. I don't want students to come in and say, "Well, we have three terms to work on this. So this term if we don't quite get this done, it goes to the end," because that just keeps pushing stuff off and off and off.

I would rather [have it so] if at the end of the term, if things are going great and you've made great strides … I have no problem going another term if it warrants it. Committing a deal at the beginning is like, "Sure, I'll let you go three terms." It can be a dangerous thing for all of us involved. I tend to take it on a term-by-term basis. At the end of the term, let's evaluate what you did well, what went wrong, if you're where you said you would be, if you're beyond that, if you're not quite there and how that would actually make another term viable. [That] is the way I go.

UAT: Looking forward to the fall, any new projects you're introducing in your classes?

DC: One new project I've been talking to a group on in my game production documentation class-one of my prerequisites that I'm talking about-is a Dungeon Siege 2 mod (which they're doing all of the design work), which they've got beta copies of now. In designing the game in my GAM430 class (and this is why these other classes are important), through the design process they've come to the conclusion that Dungeon Siege is the way they wanted to go.

Ken Adams is a man who preaches the basics. With past experience at Target Games and Hobbies, he learned the essentials creating role-playing games on paper from scratch. Now as a teacher, Ken drills the fundamentals onto his students.

We talked with Ken about his present projects, the necessary skills to be successful and a few examples of apathy in the game development program.

UAT: What projects are you working on with students in your classes?

Ken Adams: In my GAM220 classes, we have four to five projects going spread out between the two classes. They have a choice of editors to use [Far Cry, Unreal Tournament 2004, Neverwinter Nights and Warcraft III]. In the level design class, we're focusing on drawing one level on pencil and paper, and designing four to five electronic levels.

Some people are taking both GAM230 and GAM220 at the same time. I had a couple of [students] go, "Well if I use this level in the GAM220 class, can I use it [in GAM230]?" I'm looking for more of a complete project-I'm not looking at just one level. There's one guy that's going to do that for this next level that's coming due. I think he's going to do that.

We're also going back to Branching Fate by Steve Merka, a mod of Unreal Tournament 2004. It is a multi-player mod that plays like a single-player game. It has 10 linked, multiplayer maps. The level progression changes based on which side wins-just like the tides of war would affect a real campaign.

UAT: For the level design classes, what goes into the sketching of a level (pencil and paper)? What about making an electronic level?

KA: The mapping of the level is done so you can have a blueprint to create your level from. Also, I make the students do a write-up of the level so that they have a good idea of what the level will be like.

UAT: What kind of instruction are you giving for the projects-more hands-on, or lecture-based?

KA: I do a lot of lecture on the theory, which drives some of [the students] crazy. When Michael [Eilers] and I and Derric [Clark] started this program, we had a big talk with the deans, and we decided that the students were going to have to learn the editor themselves. The reason for that is when you go to a company, they'll say, "Here's the editor, here's your toolset and I need this done in a week and a half. I'll see ya," and that happens a lot. You have to teach yourself, and a lot of students were like, "I hate that," and I told them, "Yeah, I know, but you're going to have to do that."

I used to work for Target Games and Hobbies-which is a pen and paper company-and we did a little bit of work for an electronic game. I did a little bit of level work, and the other gentleman, Josh Gauthier, worked with me and we had to teach ourselves the editor. That's a pretty common thing. If you can figure out how to teach yourself the editor, once you pick it up, the rest get easier and easier.

It's not because I'm trying to be heartless. It's an incredibly hard field to get into. There are a million people thinking, "Oh, I can do this for a living." Okay, go do it-try to go get in the industry. [And they say], "Oh, it's too tough. I'd rather stay at home and play my game." [And I'd reply], "Yeah, I bet you would." Hell, I would like to.

UAT: Do you see that [attitude] as a common trend here?

KA: A lot of people come here, and it seems that they think they're going to play games for a living. You'll do that maybe as a tester, but if you think somebody's going to pay you a lot of money to get to level 60 of World of Warcraft, it's not going to happen. I wish it did; I'd be at home all day drinking beer and playing World of Warcraft. (I'm sure I'd look like Ken the Hutt inside of a month or two). "You're going to give me $60,000 a year to do this? That's great." I've never seen one [person get that]. I've had a student in my GAM101 class get all mad at me and say, "I have to drop your class." And I asked, "Why?" He said, "We're not playing any games." I told him, "No you're not, and you're going to be working a lot." It's a busy industry. It's a fun industry to be in, but you're going to work a lot.

UAT: What skills will the students need for successful completion of the projects?

KA: MAX and maybe Maya. Most games use MAX because there's a ton of plug-ins for MAX for games. Photoshop and Illustrator might not be bad. Being able to texture is important. Being able to unwrap a model for texturing a lot of people don't want to do that. People complain, "Well that's hard. That's boring." Yes it is, but to be able to do that is a big thing.

Being able to write well and being able to communicate well… that's for programmers, artists, level designers and managers. You need to be able to have good written communications skills. So when they tell you, "I'm an artist. I don't need to learn how to write or spell," that's bullshit. The biggest complaint we have from people in the industry is that no one knows how to write or communicate well. I've become a little bit more intense on that. I'm used to reading a lot of technical papers (I have an engineering background). Michael has a master's [degree] in English literature, so he's really intense on that stuff.

UAT: What problems have you encountered with the projects?

KA: Students either not doing the work or they overreach what they can do.  Some get scared and just stop showing up. 

UAT: When are the due dates for the projects?

KA: For Branching Fate, they want to have it done and present it by the next Tech Forum, or have a good presentation-like 99 percent polished. The last week of the semester is when all the GAM220 projects are due.

UAT: Michael Eilers mentioned getting more students and instructors (via their classes) involved in jointly making games. What do you think of this?

KA: I think that's a good idea. I'm not sure how that'll be facilitated. I guess there are some models that I'll need to be made for MOD 1, and I talked to Mike Erwin and those guys, and I guess I could say, "Here, I need this model," and they could find a student to do it for them. He would just assign it as a project or assignment.

I'm going to try it this semester and see how it works. Ask me halfway though next semester and I can let you know.

• Rainbow Studios/THQ Phoenix
• Raven Software
• Insomniac Games
• Midway Home Entertainment (unofficially, but better known as Midway San Diego)
• Interplay Productions