SOME DEVELOPERS go from daydreaming about making games for a living, to getting their foot in the door straightaway. Others take a more scenic route. Adam Schmidt is one of the latter, and his journey one of the most fascinating.
Before joining Daybreak Games, he worked at Boeing as a software engineer, where he collaborated with a team to double- and triple-check software before it made its way far above the earth to the International Space Station.
I talked with Schmidt about his time at Boeing, how that job prepared him to handle the many glitches and foibles that occur in a real-time online game, and why aspiring developers may want to consider majoring in computer science rather than a program geared toward game design.
David Craddock: How did you become interested in EverQuest? Did you aspire to work on the game?
Adam Schmidt: My story goes back long before EverQuest came out. I loved games when I was a kid. I played tons of games during childhood, but pretty much everyone in the industry did. EverQuest was my first MMO. I played a bit of Asheron's Call at the time, but I just fell in love with EQ. I decided, "I want to see where my passion for gaming goes from here." Because of EverQuest, I took software engineering classes in college. I went to college because of this game. It was the tipping point: "Do I want to do this for the rest of my life?" The answer was yes.
I played a ton of EverQuest—probably too much—and went to a technical school during high school because they allowed me to do programming for half the day. We'd make little video games in class. It was a ton of fun. I played it more than I really want to admit. I think I had one year's worth of play time over the game's first four years. I played it a little too much.
Actually, no I didn't: It was all job research, right? For when I got a job here 15 years later.
Craddock: What was the game’s initial appeal for you? The hook that you weren’t able to shake off.
Schmidt: The community, for sure. I played on one of the roleplaying servers, and everyone was really into roleplaying aspects of their characters. That exists to varying levels today, but at the time, we had servers dedicated to roleplaying.
Craddock: In preparing for this interview, I noticed you worked at Boeing almost straight out of college. Since you had your sights set on making games, how’d you end up there?
Schmidt: My original goal was to switch [from computer science] to a gaming degree. They were still new. Only a few schools offered them, such as DigiPen and Full Sail. I was considering switching over, so I'd start at University of Missouri-Columbia, but I really fell in love with that campus, and didn't want to switch.
I enjoyed it and liked the engineering program there. I applied for internships before my final year at school. NASA Systems said, "We want to pay for your last year of college. We want you to work for us right out of school." I didn't have to apply anywhere else. It was great.
There are a lot of benefits to working in the space industry. I was there when space shuttles returned to flight, and being in the room with everyone who worked on those projects when that happened... People were in tears. Everyone's passionate about it, which means it's not so different from the games industry. Also, getting your last year of college paid for is nice. I came out with minimal student debt, which was great.
Craddock: What projects did you work on?
Schmidt: I worked with a group of people who were primarily responsible for being one line of defense for software that was going up to the International Space Station. Everything there was triple-checked, and more, because you could not make mistakes. You could not have bugs make it up there.
It was an interesting project to work on, but that level of... not stress. That's the wrong word. You just must be really careful of software that winds up going up to people in this little capsule, flying above the earth. There's no room for error; you have to be very careful all the time. You don't end up making a ton of software, but every bit that makes it up there is very impactful.
That's what I did: Making sure the software was correct. We had ways of simulating exactly what was going on up there; we had the exact same hardware down on the ground, so we could interface with them.
Craddock: Obviously, there’s more on the line ensuring that software works for people who aren’t even on Planet Earth. I did wonder, though, if you’ve ever drawn any similarities to working on real-time code for the ISS and maintaining a persistent online game.
Schmidt: Both are real-time systems, in a way. Not by every definition of the term, but both systems are running in live environments, and need support. We checked all code going into the game. No code went in without someone reviewing it, so that's a similarity.
I think every position you have [in your career] before the position you end up in next influences what you do. From that specific job, the thing that was most applicable on EverQuest was the amount of testing you have to do. How you test is very structured in that it doesn't really allow for error. Here, it might be looser if someone isn't paying attention.
Like, testing edge cases: If I do this thing, but slightly more, will the system go under? You get used to testing that.
Craddock: This may seem unrelated, but WWE employs an announcer, Michael Cole, who was a journalist stationed in war-torn countries before he transitioned to calling pro wrestling matches. He’s explained that after such a stressful job, he was looking for a different sort of challenge. Did that play a part in your renewed focus on game development? Not that it would be easy, but certainly less stressful than your work at Boeing.
Schmidt: I've done a couple of other things since Boeing as well. I'll be at Daybreak five years as of this summer. It's been a short five years. There are different challenges. They don't go away; they just become different. Boeing was never unenjoyable because of people's lives depending on it. There were so many lines of defense and so many ways to find issues before software went into orbit, and the people who made the software happen were really incredible. One coder's production output in NASA is going to be a lot less than here [at Daybreak], where one person will be writing thousands of times more code that winds up being in the game.
Craddock: Like you, many of your peers played EQ before they developed content for it. How did working on a game you’d played for so long change impressions you’d formed as a player?
Schmidt: You get to see behind the curtain, in a way. A lot of players have the classic, "That'll only take five minutes to fix" sort of mindset. I was never really afflicted by that because I'd done software for long enough to know that anything, if done right, looks simple. If it's not done right, it's very complex, because it has bugs and loads of other issues.
It's not overlooked, it's just hard to make changes. If you do everything right, the players notice nothing. Just learning more and more about that is a continuous process. We switched to a database, for example. From a player's perspective, how we store data shouldn't have an impact. But it does, and it's been interesting.
Craddock: What are some of the challenges of working with mature code?
Schmidt: One challenge is the code base has existed for over 22 years at this point. There were architectural decisions made back then that still impact us today. That is a challenge: You're continuously fighting against those to solve issues. Some of the advantages of having a mature product is, there's so much about new products that's in flux. We don't have a lot of huge, sweeping architectural changes to concern ourselves with because our architecture exists. It's more the challenge of tweaking that architecture to work with more modern things we're doing in the game.
We have a lot of systems that run synchronously: They wait for one thing to finish so they can do the next thing, then the next thing, and then the next thing. Everything has to be done in a specific order. That's not ideal. You want to be able to say, "Hey, system, go do this other thing and give me the result, and then I'll do something with it later." That's been the biggest challenge: Converting a system that was built to be synchronous, into a system that needs to be [more flexible].
Craddock: How does the fact that the game is constantly running—barring downtime like maintenance—affect your ability to roll out live content?
Schmidt: There are things we can't change because the game is live. The whole architecture is driven toward what exists, not what might exist. Most of those decisions were not made recently, so updating those systems might be impossible. You might not be able to change it to work in a way the designers want because it could impact three other things—and maybe it shouldn't, but it does, because of design decisions made over time. It's what we call tech debt. [Author’s note: Technical debt is defined as the cost of work that is added to one’s schedule due to choosing a faster solution rather than a better approach that would take longer to implement.]
Craddock: I understand that EQ’s advanced loot system has been one of your pet projects over the years. What were your contributions to it?
Schmidt: I didn't architect it, but I was the one to implement it after being here only a few months. It was quite the project. Our UI system is 20 years old. One of the continuous challenges of working on EverQuest is trying to keep the game running well, especially in respect to the UI. Advanced loot was not a mature system.
We said, "We're going to design a loot system that doesn't exist in any modern MMO." It's very complicated, but it has to be: The number of things players want to do is vast. We can't make it work the way one specific person wants to use it. We make it work for the person who's running a guild, and the person who's running a raid, and the person who's running solo. That system was about making players' lives better.
Craddock: You came on board Daybreak Games as a senior engineer and are now a lead programmer. What change in responsibilities did that promotion bring about? For example, are you still able to write code for the game, or is being a lead concentrated more in management?
Schmidt: I manage and write code. I look for people who are self-sufficient and self-motivated, and then help them be successful. If I can help them be successful, then I have time to do code changes myself. I'm working on stuff right now I wouldn't be able to work on if I didn't keep everyone else productive.
Craddock: What are your current projects on EQ?
Schmidt: We're adding two new progression servers for EverQuest's 20th anniversary. They're a bit different [than other servers], although players have had the opposite reaction to what we expected. We're providing a new experience to go through. It's always tough to make something new because players will always say they wanted it to be exactly another way.
The problem is that every player has a different set of expectations, and some players are more vocal than others. Some players might want a no-rules server where everyone can do whatever they want, and there are no restrictions. And that's great, but if that's not really the experience we're trying to give players at the time, it doesn't work out. For the 20th anniversary, we want to be inclusive. We don't want to cater to one group of people, so we're making a progression server that's faster than any we've done before. for instance, quicker unlocks between expansions.
That will cater to two different kinds of people: the kind of person who says, "I didn't want to experience this content again," won't have to sit around waiting for the next content update. They want level increases to be quicker, so they'll have an experience on this server that they want. Also, for the people who are super-hardcore about, "I want to progress as fast as possible," they'll get something out of this.
One of the biggest challenges is what we call this type of server. It caters to two groups of players looking for two different experiences, all on the same server. It's hard for players to understand that because their view of what they want can be very narrow. Servers aren't one-size-fits-all, but they also can't be made for one specific type of players, because that wouldn't be successful.
Craddock: What’s the collaboration between programmers and designers?
Schmidt: The software engineering team has a seat at the table, but a lot of EverQuest's design comes from the design team. Whatever we determine is the correct path, as a team, we do a lot of support work to make sure that happens when we needed to, while also getting a bunch of other stuff done.
Making a new progression server takes a lot of design work as well. It's not just for us, but in this case, we put in some new things that progression servers have never been done, like knobs you can turn for other things such as special events throughout the year. You support different player bases in different ways, and you support designers to make the progression server.
There has to be [collaboration] in production. You can say, "I need this thing by this time." Well, we could do that, but it's going to cause this problem, which we could get around by doing this. Either that's worthwhile to them, or it's not. They can say, "Yes, we still want the original thing," and we'll say, "Okay, here's how long it will take." And maybe they'll respond, "Well, maybe we can dial it back a little bit."
Craddock: The fact that EQ will turn 20 years old this year when so many other MMOs only survived a handful of years, is that, is quite remarkable. So is the game’s content schedule: One to two new expansions per year. Since there’s always something new in development, how far ahead do you have to plan for new features and changes on the engineering side?
Schmidt: Sometimes years. It depends on the content. The 20th anniversary's content has been years in the making. Toward the end, things grow more intense as far as priorities. Right now, my number-one priority is making sure March goes well: making sure we have our progression servers out, that we have the right hardware out and that it works smoothly, that we have support available for when the servers go live and we have issues. There are a lot of different pieces running.
Craddock: If you could design and implement any feature for EQ, assuming resources were not an issue, what would it be?
Schmidt: If time and resources were no object, I would want to completely overhaul our UI system. That, I think, would have the most positive impact for players. It would be more usable and less buggy. I'll also say I'd like it to be 64-bit instead of a 32-bit client, but there are a lot of restrictions, there. The UI could be done now, but a 64-bit client is a way off. We're talking years.
We've been modernizing our UI since I started here. That's always been important to me. I don't want you to have to read a manual to use your interface, because that's not just UI: That's user experience. Everything you do in the game consists of tiny checkboxes that fill up your screen with buttons you have to click. Making that system is something we can do.
Another UI thing I did was adding a modern version of the quest window that takes up less space on your screen. You couldn't see anything before; now there's a little tracker running along the side. There's more we can do to bring our UI up to date.
Craddock: A game you’ve help shape both as a player and a developer is going to turn 20. What thoughts and emotions does that stir up?
Schmidt: It's special to me. My career really has come full circle: To get a job working on the thing you went to school to make? I never thought EQ would exist this long. Neither did the original developers, which causes all sorts of fun, interesting things you find in code. It's been very fulfilling to get to work on this. I joined around the 15th anniversary, so I got to see that. To now be doing the 20th anniversary... it's been on everyone's mind.
The team has been saying, "What can we do to make this as good as possible?" That, and still doing expansions every year, and keeping everything running—it's been a great challenge. When I'm looking for a job, that's what I want: A job that will be challenging, that I'll make some impact on, and that I can help people.
Craddock: What advice would you give to players who want to make their living programming games?
Schmidt: One piece of advice is to go to school. That's very important. They should get, if not a computer science degree, then something related. Be good at math, be good at something. Have some distinguishing characteristic about yourself. Even though I minored in math, I wish I'd done more. I would have taken slightly different coursework if I could have.
Another piece of advice is to go to a school that's affordable for you. Know that you're going to have to pay for it. Going to an in-state school that's a third of the cost of going somewhere out of state will be a huge stress reliever for a really long time. I know a few people who work here feel the weight of their student debt, so I can definitely appreciate that worked, and got as many scholarships as I could, to reduce that burden.
They ran out of graphics classes I could take as an undergrad, so I just started taking graduate-level courses. I haven't gotten to put that to huge use, but at the same time, I know a lot of the theory that's maybe glossed over in other classes. It may not be useful to know how to render a line from here to there, but knowing how that works could be useful. There's a lot of base knowledge you'll end up gathering if you take a broader CS degree rather than a targeted degree, such as a gaming degree with a specialty in graphics.
At another job, you could get knocked out of your comfort zone, or run into a roadblock you can't get around. I've been lucky enough to help hire a couple of people right out of college to work on the EQ team, and they're just great. Some have EQ experience, some don't, but they're all well-rounded software developers who are passionate about games.
That's another key point: Be passionate.
