Archives

Interview with Edward Chen, Lead Developer for Cleric, Pt 1

| 2 Oct 2003 14:16

Edward Chen is the Lead Developer/Business Developer for Plutonium Games, the folks working on the Survival Horror game Cleric. You can check out what Cleric looks like at the Cleric Images gallery, and see some past interviews with Matthew Doyle (the CEO of Plutonium Games) here and here.

Mystery: To begin, can you please tell us who you are, and what you do?

Edward: My name is Edward Chen and I wear two hats right now. I advise Matthew on business affairs, and I am technical lead for our company. Previously, I was a technical manager at Ameritrade's institutional day trading subsidiary, TradeCast.

Mystery: Game systems and business systems hold many of the same concerns when it comes to interacting with the user. How did you use your experience with TradeCast when it came to developing the demo for Cleric?

Edward: They're more similar than one might think. The nature of high-throughput server software like what we built at TradeCast is that it's focused on the reliable, asynchronous, high-speed movement of data from one place to another, with a relatively simple processing pipeline. Think of them as fast data processing engines. In a game engine, the formats and processing are a little different (there's more math), but mechanics of writing an efficient processing pipeline involve many of the same kinds of problems and solutions.

However, the kind of programming associated with "enterprise software development" is different from what I did at TradeCast. Enterprise programming is usually more about abstract problems than thinking about how memory access patterns and thread quantums should be tuned. I prefer working on the mechanics of real-time software engines, like ones that power interactive games.

On the process side of things, game programming has grown enormously in the last ten years to where small, self-managed teams generally aren't enough. Game programs now span between 300,000 to 1 million or more lines of code. For that you need a team of programmers, and if you have a sizable team, you need some kind of organized process. The game industry is just beginning to discover the formal software development processes that have existed outside of the game industry for many years. Programmers who have only worked in the game industry may even feel uncomfortable with the idea of having a formal process, because they perceive it as unnecessary overhead that cuts productivity. Sure, there is such a thing as too much process. But most programmers tend to think about how their personal daily productivity is negatively affected, and not how the productivity of the entire team over the lifespan of a project is positively affected. That's the trade-off. The fact is, doubling your programming staff will not double your productivity, and it never will (I encourage those interested to read "The Mythical Man-Month" by Frederick Brooks). In any case, designing a carefully balanced process to complement the strengths of a solid programming team is something else I've brought over from my years at TradeCast.

Mystery: Being a developer and a sales person for Plutonium must get hard on the nerves after a while. Do you find yourself having to switch gears so that you're not speaking like you would to fellow developers, or do you find that the publishers and funders are receptive of technical jargon these days?

Edward: Switching gears has never been a problem. I do it without even really thinking about it. It isn't just a question of how technically adept the person I'm talking to is; it is about what their interest or focus is. I am prepared to talk about any aspect of the project: the financial risks and rewards, the marketable features, the cost justification, why it is fun to play, and the technology behind it.

In this business, there is a wide variance in how comfortable people are with technical jargon, and I still get surprised every now and then. A few weeks ago, a VP for one well-known publisher asked me about finite state automata used in our game. That was kind of unusual.

Mystery: How did you get your start? Do you look back on your life and imagine that this is what you thought you would be doing in 2003?

Edward: Honestly, I got my start the day my dad brought home our family's first personal computer, a Commodore VIC-20. It was love at first sight. I was 13 years old at the time, and I had no prior concept of, or interest in computers. On that first day I had the computer, I entered:

10 PRINT "HELLO WORLD!"
20 GOTO 10
RUN

And I was hooked. That day changed my life forever. Before that day, I had no idea of what I wanted to do for a living. After that day, I knew exactly what I wanted to do. As a kid back in the 80s, I ended up writing for games that my friends and I could play in high school. I got an Apple //e because that's what everyone else had, and I taught myself Motorola 6502 assembly in pursuit of writing high-speed graphics routines. I remember it was a challenge on the Apple because the high res graphics memory pages were nonlinear, so it was really cool when I mastered it and hooked into the vertical retrace. When I got into college, my parents insisted that I pursue a degree in medicine, and I rebelled. My first year in college I was pretty unhappy-I remember skipping some of my classes to sit in on lectures going on in the Computer Science building. My folks acquiesced after the first year, and I applied for and switched majors, and in only 3 years and a lot of hard work (I had a job on the side plus I was taking summer courses), I had obtained my degree in computer science.

But when I finished school in the early 90s, the computer games industry didn't exist like it does today. The conventional wisdom coming from my parents, peers, and career counselors was that I should get a "real job" working for some big company like IBM, so that's what I did for most of my career. It seemed like they were right: the Apple // was dead, Atari and Commodore were on their way out, Macintosh was this little 7Mhz black & white computer, and the IBM PC as not designed to play games (until id released Commander Keen, I still have my original copy on a 5.25" floppy). Id software, more than anyone else, changed my perception of what a PC could do, and their exciting and technically brilliant games kept me close to the PC game industry as it emerged during the 90s to become the serious career path for programmers and artists that it is today. Now I'm 34, but I never lost that love of games, of the technical challenges and the sheer geek thrill of making game code. I've been able to marry that to the work ethic, responsibility, and business sensibilities that I've developed while working in the consulting, telecom, petroleum, and financial services industries during the 90s. For me, I knew this was what I wanted to do since I was 13; I just had to get over the idea that it wasn't a "real job."

A fond thanks goes out to Edward for taking the time to answer my questions. Stay tuned for Part 2!

Username:  
Password:  
Video of the Day
Featured Videos