DigiPen instructors bring remarkable professional experiences to the classroom. In our Faculty XP series, we’ll zoom in on some of those fascinating career histories with focused Q&As.
Courtesy of his computer science students, DigiPen Game Development and Production Professor Douglas Schilling recently got a new addition to his desk — a miniature Douglas Schilling Funko Pop. It’s an appropriate gift for a man who, prior to DigiPen, spent 14 years developing pocket-sized fun himself on over 40 handheld titles at what would eventually become Kirkland’s Griptonite Games.
With a background in desktop publishing and avionics, Schilling decided to take his career into handheld gaming in 1994. He found himself developing fun-filled cartridges for massive entertainment franchises like The Sims, Lego, Spyro, The Lord of the Rings, Star Wars, The Simpsons, Iron Man, Harry Potter, Barbie, Digimon, and beyond. Schilling worked on every major handheld Nintendo console from the original Game Boy to the DS, with a few brief spins on other on-the-go platforms like the Sega Game Gear and the notorious Nokia N-Gage along the way (more on that later). Thanks to his programming prowess, Schilling eventually became Griptonite’s studio technical director in 2004, overseeing nine teams at a time working on separate projects. In between teaching DigiPen freshmen and sophomores the fundamentals of development, we sat down with Schilling to chat about his portable past.
How did you initially get into the game industry back in 1994?
Pretty much by chance! I saw a two-line ad in the paper about a game development job in Redmond and thought: What the heck — why not?
Was it a big jump going from avionics to developing Game Boy games?
Learning to develop handheld games, it wasn’t that hard because my background had prepared me to do embedded programming, which is a lot of what handheld game development was. Back then, we were using assembly language on the original Game Boy. My boss was asking me if I had much experience in assembly, and I said, “Not really! Well, actually.” And I started rattling off several different areas where I had worked in assembly during college and my early career. All of a sudden I was like, “Oh, I guess I have more experience than I thought.”
Assembly is a very low-level programming language, so we were working very close to the metal with the Game Boy. It took me about a month to be able to think in assembly language, the same way you learn to think in a foreign language instead of translating everything in your head.
The engine I started with for the Game Boy, we were writing pretty much everything by hand. As our engine developed, our code library started getting bigger and bigger with these helper functions we created to make programming simpler, so we could develop more complicated games as time went on. For example, there was probably three-to-four times more code in our later Game Boy Color games compared to our original Game Boy games.
You worked on titles from the original Game Boy on through to the Nintendo DS. What was it like working on Nintendo’s handhelds as they evolved generation to generation?
Development got both easier and more complex. Going from the Game Boy to the Game Boy Color, it was like, “Yoohoo! Now we have twice as much memory and CPU power!” Then from the Game Boy Color to the Game Boy Advance, it was a really big step up. You had a processor eight times faster, a lot more memory, and the ability to do much more complicated layouts.
The way Mike Dorgan, an adjunct at DigiPen who has worked with me since ’95, puts it: Our projects at the end of a platform’s lifecycle looked better than our projects at the beginning of the next one’s. In other words, we’d eked all the performance we could out of these platforms, but then we’d migrate to a new platform and hadn’t done that yet. So they would look roughly equivalent. From there we’d boost up and find more functionality.
If you look at videos of The Legend of Spyro: The Eternal Night, which came out in 2007 on the GBA near the end of that platform’s lifecycle, as well as on the DS, it looked pretty awesome for a GBA game. It had all these different things going on pushing the hardware to its limits in really interesting ways.
With the DS, we were one of maybe three or four third-party developers doing a launch title — The Urbz: Sims in the City. As a result, we had a lot of support from Nintendo. It was kind of fun figuring out how we could take our Game Boy Advance engine designed for one screen and make it work on a DS!
You worked on a number of handheld Sims games right when The Sims was first blowing up on PC. Was it tricky turning that PC experience into a portable one?
Yes! We were actually asked to port that first Sims game to the Game Boy Advance in 2000. It never happened though. The issue is, a PC and a Game Boy Advance are not at all the same. They wanted to make it so the entire Sims experience worked on the GBA, which was simply not possible. We tried to tell them that! They thought you could just download all the assets from the original game and put them on the GBA. They also wanted to make it so you could customize the houses just like you could on the PC version. On the handhelds, we only had four background layers, so all someone had to do was build a zig-zag wall and you’d get sorting issues that couldn’t possibly be resolved.
The first thing we did was make it so the avatar was steered by the player, not click-driven like the PC. They thought that ruined the experience. The other big change we made was if you went to upgrade your house, it would say: “Buy a Room.” You could change the flooring and walls, but you’d change it all in one pre-configured shot. You didn’t customize the layout like on PC. They said, “That’s not good enough,” and cancelled the project.
If I remember correctly, they went around and tried to farm it to other handheld studios over the next couple of years, and of course, they all said they couldn’t do it either. Eventually they came back and asked us to resurrect the old project! By that point, they gave us a lot more freedom. They let us have players steer their characters and upgrade their house using pre-configured add-ons. The other big change was instead of a car picking you up for work and you disappearing for the day, you actually went into your office and played a mini-game that determined how much money you made that day, completely breaking the main series model. It was 100% successful in my opinion!
One thing I’m proud of and felt vindicated by — I was playing The Sims 3 in 2009 and went to upgrade my house. What did I find? Pre-configured rooms! The method I came up with for handheld in 2000 was perfectly fine in the main game nine years later.
You have one Sims game credit on the notorious Nokia N-Gage! What was it like working on such a bizarre platform?
The side-talking taco you mean? We were being courted to do an N-Gage game. EA wanted to know if we’d port our The Sims: Bustin’ Out GBA game to the platform. We said, “No, thank you.” It wouldn’t have been hard to do, but honestly, none of us had any confidence the N-Gage would be successful. And you know what? We were right! In order to change the game, you had to remove the back cover, remove the battery, dig out the card, put in a new card, put the battery back in, close the cover again, and reboot your phone. It was like, “Uh, no.”
Later, I spent three days with one of the programmers from this English company that ended up taking the gig, running him through our codebase so he could figure out how to port it. That’s all I did, but I guess it got me an N-Gage credit!
We actually had the opportunity to work on the Virtual Boy as well way back when, and we passed on that too. Can you imagine working eight hours a day with your face in that thing? I remember there were actually some initial concerns about the design of the DS too, but instinctually, I knew in my heart that platform would be very successful — which it turns out it very much was.
Do you have a favorite handheld game you worked on?
I have a few experiences that I like for different reasons that I actually use as examples in my class.
One of them was working on Barbie: Ocean Discovery in assembly language. I was working on a puzzle mini-game, but we didn’t have code that would let you move a piece from one arbitrary place to another. My boss said, “There’s already a piece of code that lets you do that for a three-by-three box. Just copy and paste that!” But I refused. Instead, I wrote a new function where you could take any arbitrarily sized image and move it from any location to any other. My boss wasn’t happy with me, but that piece of code ended up going into every single project after that! That function was one of the first that got ported over from our Game Boy Color engine to the Game Boy Advance.
The game I was really proud of, though, was Heroes of Might and Magic. Mike Dorgan and I worked on it together. We would have so much fun planning out how things would work ahead of time. I was working on the heroes and he was working on the town code. We’d figure out, “What do each of our interfaces look like? How does the hero code interface with the town code, and vice versa?” When we’d come back from programming and integrate all our code together, it would just magically work, because we already made sure it would! As a result, it was very pleasant to work on — a lot of really good experiences. Planning is important!
How did you end up at DigiPen?
I decided to leave game dev for a while, and I realized right away that it’s very difficult to go from a highly collaborative industry to one that isn’t. I was looking back at game dev and was actually told about a teacher role opening at DigiPen from the former scoutmaster of my son’s troop, who was an art instructor for DigiPen. Even though I’d known about DigiPen for years and years and hired multiple people from DigiPen, I had never considered teaching there. I was hired in August of 2009 and teaching GAM 100 within the first few weeks!
How does your industry experience shape the way you teach?
My goal with teaching is to keep students from becoming professionals with bad habits. I remember working with someone who would just copy and paste everything like my boss had told me to do on Barbie. When I was technical director, I was called in to help with their code that had a major bug they weren’t able to track down. Dozens of hours had gone into trying to solve this. I came in and sat down, and it was something like a 3000-line file. It was like, “Well, first off, why is this file so big?” I never did find the bug, but I solved it anyway by resetting pointers every time memory was freed! It was just sloppy programming.
My goal in CS 230 is to teach students fundamentals of development that hopefully steer them away from bad practices like that. And I’m not just talking about game development! Game development is actually what I call a superset of programming, not a subset. It’s not, “You’re a game programmer, so you just program games.” It’s more like, “You’re a game programmer, therefore you’re familiar with a lot of different programming.” There’s almost nothing programmers do that is not in one way or another also used in the game industry.