Michael Eilers is one of the game instructors here at UAT. As a former gaming journalist and game industry consultant, Michael has a perspective of the industry that few see. That knowledge, coupled with his programming experience, led him to UAT.

He is currently overseeing several student projects, including Subterfuge, a first-person shooter that is influenced by Spy vs. Spy. We talked with Michael about those projects, his future ideas for the game development program and why humor is an inspiration in games.

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

Michael Eilers: Currently we’re working on a Half-Life 2 mod, which is in its second semester, called Subterfuge. I knew right away that I wanted to do something radically different from typical Half-Life gameplay. Everyone that was going to do a Half-Life 2 mod was going to essentially make a Counter-Strike clone or just screw around with new skins, weapons. It’s a total conversion mod; there will be nothing even resembling Half-Life 2 in the game when we’re done.

I was thinking to myself, “What do I want to do with this game to make it different and bring a little bit of ‘old-school’ to it?” One of my very favorite games for a long time was a game called Spy vs. Spy. The essence of that game was that you’re spies and you can’t attack the other person directly. You attack them indirectly by placing these traps. I like that idea of gameplay because it makes the gameplay much more tactical. It also makes the game based on careful observation to memorization. They’re some types of gameplay that you don’t typically find in a first-person shooter.

The second thing about that game, which is important, is that you can always see the other person [in split-screen]. So you had to watch, look and see where they planted that bomb … to diffuse that bomb and not get blown up. Each room is almost identical to the one next to it.

There’s also a huge comedy value to the game. For instance, when you were blown up, it was funny. You never felt frustrated. In most games when you get killed, you’re angry and upset about it. When getting killed is funny, it tremendously relieves that burden of frustration. So we’ve tried from the very beginning to make things really funny.

I want to try to get it released on the Cuban Pete’s machines downstairs by the last two weeks of the semester. I want to have a build on there so we can get student feedback on it. And then we can put it on game workstations, put it on the game cart and release it internally—do some beta testing in the school before we release it online.

We’ve got two other projects which are interesting. The first one is called Wizard Kings, a Warcraft III mod. The basis of the mod is an attempt to totally change the gameplay of Warcraft III completely. Warcraft III is typically a run-of-the-mill, real-time strategy game in a pseudo-strategy setting. What we decided to do is turn it into a tactical card-based game where you cast cards to summon creatures. On top of that, it’s an artificial life simulator, so the creatures that you cast each have their own life cycle and exist in certain environments.

The [other] thing we’re doing, which is also in the five-week online program, is an Unreal Tournament 2004 mod. We haven’t started it yet, but our concept is a snow map which you have snowmobiles and a snowball cannon. I’m calling it Snow Crash, which is a Neal Stephenson joke. Nobody’s going to get the joke though because nobody’s read the book unfortunately.

UAT: What was the inspiration behind Subterfuge?

ME: The game is based on Spy vs. Spy. You run around and you plant traps inside containers. Inside these containers are four pieces of equipment you have to get, including plans, decoder ring and binoculars. Once you get the plans, you make a bolt for the exit and get out.

We tried to make it really funny—very Warner Bros., very influenced by “Road Runner,” “Tom and Jerry” and all those sorts of things. Everything is based around the physics engine, so if I plant a bomb in a safe, you don’t just blow up—you blow up through the wall and out the window, spinning in rag-doll fashion and [going] “splat” on the ground. For instance, one of the traps puts a slick patch down on the ground so your character will slide … and then at the end of the hallway, you put a flaming barrel trap which launches these flaming barrels towards you in the air. So you run down the hallway and slide, hit the flaming barrel trap and get blown up, and watch your corpse go sliding back down the hallway.

Humor is one of the things that I think is desperately lacking in games. And oftentimes, the humor that comes from games is unintentional. There are a lot of moments in Doom 3 which I thought were funny—which I’m sure the developers did not intend to be funny. I wanted to try to exploit humor and make humor an asset of the gameplay rather than make it an unintentional side effect.

One of my inspirations for this project was Burnout 3. Burnout 3 is a very different game than what we’re trying to achieve, but at the same time it has a tremendous emotional value to it. I find the game to be insanely frustrating and incredibly hilarious. In other words, it provokes a strong emotional response, and it’s through the physics, through the color, through the action [and] through the simulation of impact with other cars. There’s a lot of content that is not just graphics on the screen; there’s a lot of thought going into the game design.

There’s a lot of creative freedom with how you play the game and with the particular style of play. You can play it like an ambush game where you wait for the other person and ambush them, you can play it very aggressive, or you could play it in a non-violent fashion—get the traps, get the briefcase and get out.

UAT: Any outside interest in Subterfuge?

ME: We had a huge push to get the game playable by Tech Forum. We demonstrated the game at Tech Forum to Ed Fries, Steve Reid, the guys from Flashbank Studios, the guys from Torque and the guys from GarageGames. All of them were really thrilled by it. They thought it was a lot of fun, they thought the concept was good and that the gameplay was good. They thought it was different enough from the original game that it was worth playing.

UAT: Any problems with the development of the games?

ME: The Half-Life 2 SDK (software development kit) for developing Half-Life 2 is actually really difficult to use—it’s much more so than the engines for Doom 3 or Far Cry. Valve really broke their promise essentially in making Half-Life 2 a modable game.

[In Subterfuge] to get [the split-screen camera] working took four weeks. It was very intense work by at least three people on the team—if not more—sitting down and going through forum after forum, trying something and having it break. The solution we came up with to making the two cameras work was embarrassingly stupid. We ended up taking the camera and stapling it to the character. It’s actually inside their torso, and the tip of the virtual lens is poking a little bit out of their chest. It’s totally a “MacGyver,” duct-tape solution, and I hate those kinds of solutions. I want to have elegant code that’s impressive, and this to me feels like it was thrown together at the last second. It functions just fine, but the steps we took to get to that solution were just ridiculous.

[Regarding Wizard Kings’ artificial life simulator], it’s been incredibly difficult to program this because the scripted language program to Warcraft III is very powerful but also very limited. Typically, those two things come together: very powerful that can make changes in the gameplay, to very limited in that those changes can only be within what Blizzard designed. You write your code and you think it works great, and then you actually play the game and nothing happens. There’s not much that you do about it because you’re dealing with someone else’s engine, and it’s got its own quirks to it.

UAT: What will some of the effects be of Subterfuge’s development?

ME: We’re doing an experiment with this mod, which is the model for some future projects here at the school. We’re actually outsourcing some of the modeling and texturing to the other classes here at school. For instance, we’ll give the MAX and Maya classes a list of stuff we need modeled for the game. Students are going to model those things as part of those classes, and we’re going to recycle it in our mod.

We need to really change the way portfolio material is generated in this school if we want students to have a nice, well-developed and broad portfolio at the end of four years. In an ideal world, every time a student models something, it gets used in a student project here at school or in a showcase for that student. It doesn’t go into a drawer and get forgotten—it becomes an active, living part of the school’s overall product. So we have some stuff that we’re going to do with very large-scale projects—maybe MMO’s or some things of that nature—where we can have not just one to five students, but the entire student body generating and contributing in some way.

We want to try to put some structures in place to make that happen. I’m trying to get a feel for how that’s going to work this semester and probably try something bigger along those lines in the fall. We’ll try to get students work re-purposed, essentially. If it gets turned in more than once, I don’t have a problem. Other instructors might, and I’m not going to step on any toes in situations like that. It’ll always have to be cleared with both instructors for this to happen.

We haven’t done enough yet—mostly myself, but also Derric [Clark], Ken [Adams] and Jon Harbour—to cross-pollinate between the game classes, the programming classes and the art classes. We need to do a lot more communication between those classes and try to align them towards a final product. It’s not going to be easy to do, but I think the students would benefit from it tremendously.

If a student models in MAX and the model they make ends up in the texturing class, the texturing class textures it and that [texture model] ends up in a UT 2004 mod. Then the student builds a level in a GAM230 [level design] class that ends up being the level the character runs around in, and the programming class writes some cool code for that. So we have a mod which is a collective example of student work, and the student gets the impression that everything they’re writing, creating and working on has a purpose. It’s a tremendous, positive achievement. I want to try to purpose a lot of student work that way so that everything leads towards a final product.

The other thing is that it gives students a stronger motivation to polish their stuff if it’s being seen by their peers. Peer review and peer pressure are really powerful teaching tools. If you tell somebody that their work is being seen by everybody, and not just by the instructor, it really pushes them towards their best work. Some of that peer pressure pushes people in an opposite direction and they do no work at all. Some people can’t deal with the pressure, but the truth is that you’re not going to succeed outside of the school if you can’t put up with that sort of challenge.

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

ME: The team itself for [Subterfuge] is very small. We only have four people working on the game—technically six. Four are our core programmers, we have one guy doing storylines and character development and we have one guy doing music and sound effects. It’s a small team of people—much, much smaller than anything else at the school. I don’t know any project working with six people trying to get it done within the time frame that we’re trying to get it done. It’s been tight, and it’s going to be interesting.

Wizard Kings and Snow Crash are both by the same group of students for MOD 1 and MOD 2, and that’s about 11 students total for each one of those.

UAT: What is the difference between doing projects in class and projects online?

ME: What’s unique about it is that we’re doing it for the five-week online class, so it’s an online-only mod. In other words, the students never meet each other—they only meet online. The second thing is that we’re doing it in five weeks versus 15, because the online classes are 15 weeks compressed in five weeks.

It’s been a very interesting experience. I’m not going to say it went smoothly—it actually was pretty rough. It’s really hard to communicate effectively online because everybody’s in a different time zone, everybody’s in a different place and almost all the students involved are non-traditional students. They are taking online classes because they actually have a life (40-hour per week jobs, marriages, families and children), and they’re trying to take these classes, so it’s very time-intensive. But it came together very well.

The students have to be very self-motivated. It’s impossible for me to literally lean over their shoulder, poke them and say, “What are you working on?” It requires a huge amount of direction and effort on the part of the instructor. I think the overall success rate is going to be better or at least the same as the normal classroom mods, because the students who participate in these tend to be highly motivated. The online classes tend to weed out the weak essentially in a very short order.

UAT: What about projects for the fall semester?

ME: I’ve got a Torque 2D game that I’ve designed known as Singularity. I’m trying to put a team together for that for the fall. It’s going to be a very small team: a couple of artists, a musician and a programmer. I’m going to see if I can get Jon Harbour to work on that with me. I’ve wanted to do a Torque 2D game for a long time. It’s a real-time action/puzzle game.

Then we’ve also got another Torque 3D project, which I’ve heard rumors about. Students are picking out classes for the fall right now, so they’re trying to decide whether they’re going to have time to work on projects for the fall. And then I want to have at least one more UT 2004 mod in production.

[Subterfuge] is supposed to end this semester because it’s [part of] MOD 1 and MOD 2. If I get enough student interest, we may continue working on it. One of the things I want to do is that when I teach level design class, I’m going to have students in that class build maps for that mod project [a map pack, for example]. In other words, try to give the student content being created in these classes a purpose. It doesn’t just go in the library burned on a CD. It will go out there on the Internet and be useful and purposeful.

UAT: Any future plans involving game development?

ME: Our major focus is moving away from mod development as much as possible and moving more towards original development from scratch. Jon Harbour and I feel very strongly that we need to move to mobile development, like cell phone games, Game Boy Advance games, Pocket PC games and web games. Those are areas that students are not generating content in. We have no student projects that are working for mobile devices. I think that’s a huge loss and a tremendous missed opportunity.

If we were to focus on anything here at school, I would say to put all resources into mobile game development. It is the absolute fastest-growing market, it’s the market that’s the easiest to gain entry into and you don’t have to make this incredible, complex and deep gameplay. For the mobile devices, the bar is set pretty low. Most of the games are Breakout clones or Snake clones. I think you could realistically make a game for mobile devices in three to four months and have it be as polished as a commercial release.

For instance, look at the COR project. It’s an amazing piece of work; it’s incredibly impressive. It took them essentially two and a half years of work, and those guys busted their butts and it was a huge team and they worked really hard. And they had to work outside of the classroom because they used up their classroom time (MOD 1, MOD 2, SPT) and they had to keep going after that. I still think that the COR project could not be boxed and sold as a commercial product. It’s a tremendous project and I have huge respect for it—they really accomplished a lot—but at the same time, even after all that work, I don’t think you could just turn around and package it and sell it without a lot more changes to the way the game is delivered and the way it’s played.

Conversely, I think you could make a Pocket PC game in six to eight weeks and have it be a saleable product. You’re dealing with writing 100k of code instead of 10,000k of code, and you’re also working with these very restricted environments which limit what you can do, and also limit the audience’s expectations of what you’re trying to do. They don’t expect Doom 3 on the palmtop.

A mod is probably not a good thing for a portfolio, because it requires the person reviewing your portfolio to actually have that game and have it installed. The odds are very small that the HR person at a company is going to have Half-Life 2 installed on his hard drive. But at the same time, you can take a movie of that or link to a website, and you can give people an example that your work is up and running and moving rather than a bunch of static screenshots.

We’re only slowly ramping up the actual facilities we have here at school. We still only have eight game-dev machines and a limited amount of seats for MAX, Maya, Gamebryo, Torque and things like that. I’m working very closely with Mark Hartlieb, Todd Blackwood and the game instructors to build up our game development facilities here at school. They and Dave Bolman are really onboard with ramping up the amount of equipment we have here at school for games. Also, the AV department is about to get a huge upgrade, and that’ll help us too, because you need trailers, content, good storytelling and good website design.

All that ramping up is going to help us, and it’s going to be a trickle-down effect. We have an incoming class of over 400 freshmen, and I’m not exaggerating when I say that 70 percent of those people are interested in games. So we’re going to have to build more stuff just to satisfy them.

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.

Jonathan is teaching a few classes this summer, including Game Programming in C++ (GAM327) as well as three special topics classes: Console Game Programming, Handheld Systems, and Game Engine Development. The classes are a boon for game programmers at UAT. The University is equally enthusiastic and has purchased new hardware for the classes, including development kits and handheld systems.

Jonathan's education is in computers, but he learned first-hand that technology is always changing.

“I have a B.S. in CIS [Computer Information Systems]. This program is a good choice because it's so well-rounded,” Jonathan said. “The education I received was a little out of date, so I had to pick up a lot of skills on the job.”

Some of those skills and experiences can be transferred to today's students. “The most important thing to know up front is absolutely everything you can possible learn about databases,” he said. “Get as much experience with SQL Server 2000 as you possibly can.”

Jonathan is not just a game instructor, but also a gamer at heart. He has been playing games longer than some of the UAT students have been alive, although he's the first to admit his reflexes aren't what they used to be. He only now plays pseudo-realistic games like World of Warcraft (WoW); Civilization III: Conquests; Need for Speed Underground; Fable; Star Wars: Knights of the Old Republic; Halo 2; and Counter-Strike. Jon prefers consoles over PCs; in fact, WoW is the first PC game he's bought in the last two years.

Jonathan also has a serious interest in cars—especially Fords. He has two 1968 Mustangs that he's restoring himself, including engine, brake and body work (check out the cars at http://www.jharbour.com/cars.aspx ).

Jonathan knows the plight of student game designers and programmers. “You are in an extraordinary challenging field of work,” he said. “You absolutely must take yourself and your studies seriously. There's a fine line between having fun learning and goofing off.”

His knowledge brings across guidance to those looking to getting into the industry.

“If you have a plan and know what you want to do, then you can get the job you want,” Jonathan said. “Focus in on something, find a niche that you will specialize in and master that subject. The whole PC arena is so huge.”

The expansive PC market offers the option to specialize in your skills. Jonathan brings forth a nugget of information for those looking to get hired.

“The important thing is to be well-rounded, but have a hot point that you excel at,” Jonathan said. “When your resume reaches a project lead, what will stand out and get you noticed? [Perhaps] you are not just a ‘game programmer': perhaps you are a 2D engine programmer, and your forte is arcade and handheld ports.

“Food for thought: There are more 2D game projects in the works right now than 3D projects in the game industry, and there's more console projects than PC projects.”

For his future students, Jonathan has an important message he wants to convey: "You will never stop learning. What you will take away from the college experience, more than anything, is the ability to teach yourself everything you will need to know in the coming years,” he said. “Don't think of graduation as the end of all your hard work, because it's really just boot camp. By attending class after class, doing assignments and projects, and suffering deadlines, you will emerge strong, capable and confident in yourself. You won't just hope and dream; you will know and do.”