Raphael “Raph” Koster is an award-winning game designer and creative director, whose work on Ultima Online for Electronic Arts and Star Wars Galaxies for Sony Online Entertainment has generated revenues exceeding more than a half-billion U.S. dollars.

A pioneer of massively multiplayer online games, Koster is regarded as one of the video game industry’s foremost authorities on games. His book A Theory of Fun for Game Design, published in 2004, is now a classic text used in classrooms around the world.

In 2006, Koster left his position as chief creative officer at SOE to start Metaplace, a venture-backed developer of virtual world technologies, with product development executive John Donham. Four years later, Metaplace was acquired by Playdom, a leading social games company, which was subsequently acquired by Disney Interactive.

Ramsay: How did you get started in the video game industry?

Koster: A friend of mine, Rick Delashmit, applied for a job at a game company called Moraffware. They asked for a sample: a board game done as a video game. He then asked me if he could port over a board-game design of mine that I had playtested with him called “Nexus.” He ended up getting the job, and I was paid a few hundred bucks for the digital rights to the game. In retrospect, the game was pretty terrible: the more we played it, the more we realized it was really susceptible to degenerate strategies! But, hey, it was my first real, professional game credit.

Moraffware was later approached to do contract work for Origin Systems. The way that story goes is that Rick and Starr Long got to talking about online multiplayer gaming. When Rick ended up working at Origin on prototypes for UO, he was asked to recommend a few designer candidates. Since Rick and his girlfriend, and my wife and I, all played the Worlds of Carnage MUD (Multi-User Dungeon) and worked together on LegendMUD, he suggested us. This did lead to oddities, like Richard Garriott logging into LegendMUD as “Lord British” and chatting with everyone there. No one believed it was really him!

Ramsay: When did you start working on UO?

Koster: We interviewed sometime in the spring of 1995, over our Spring Break, I think. We drove out to Austin from Alabama where we were going to grad school. We were offered jobs sometime before the semester ended, but they weren’t ready to have designers yet. They asked us, “How about you work in QA over the summer and then move to design that fall?” We said no to that, figuring that if we started in QA, we might never make it out. We waited until the actual jobs came through in the fall and kept our regular jobs around campus. Our start date was September 1, 1995.

I didn’t start out as lead anything on UO. When Kristen and I showed up at the Origin offices, we asked, “What’s the game like?” We were told that a lot of the game was based on materials we submitted with our applications! I became “creative lead” later, after the original lead designer was let go.

Ramsay: What materials did you submit with your applications? What was the interview and onboarding process like?

Koster: A few weeks before we got to Origin, my wife and I were told “you absolutely do not want to work there; it’s a sweatshop.” We laughed nervously and went on anyway.

The whole interview process was kind of funny and a testament to how important personal connections are. We were recommended for the job. We had the in-person interview with Starr Long and Richard Garriott logged into LegendMUD to check it out.

Then we started to get sent interview questions remotely as they worked to figure out whether we were qualified. At the time, designers at Origin were often called “technical design assistants.” There was scripting, there was dialogue writing, and so on. All the questions came from what was very much a single-player game slant. We were sent examples of code and asked if we could write code like that and find the bugs that had been intentionally inserted into the code. It was something like a misplaced closing brace.

But I also remember that we thought the architecture was wrong. We were used to running scripts on servers, so we were accustomed to event-driven architectures. These scripts actually ran inside the core loop of the single-player game. The scripts they sent us did things like have the light bulb check the switch every frame to see if it was on or off. We would have done that by having the switch send a message to the bulb when the state changed.

We were also sent sample conversation trees. As I recall, we thought dialogue trees were a very bad idea for a large-scale virtual world simply because of the sheer workload. UO ended up with a keyword recognition system instead.

Finally, we were asked for a sample quest. I sent them the entire code and text of my quest for the Beowulf zone in LegendMUD but then also said “but we wouldn’t do quests this way at all now.” Kristen and I had been working on a simulation system based on artificial life and economic theory. We basically sent in a description of our design work on that. It was a system that was supposed to simulate the behaviors of creatures and NPCs using a simplistic version of Maslow’s hierarchy of needs with abstract properties behind everything.

When we got to the office on our first day, we found that our examples were the way the game was going to be. It freaked us out because we had assumed there was already a game design, I suppose.

Ramsay: What was your role on UO initially?

Koster: Kristen and I started out as just designers. Not the lowest level, one level up, I think. We each made a salary of $25,000. And when we started out, we did things like spec out background fiction, the AI system, object interactions, combat, how the skill system worked, etc. A lot of these were a meld of what we wanted to do based on MUDs and what the Ultima series had established.

We were the only two designers at first, except for our boss, Andrew Morris. Eventually, there were more, and eventually, Andrew was gone. And of course, all the core programming team had a lot of input on design too. It was a small and very tight-knit team, very skunkworks.

All of the programmers and designers except Andrew came from text muds. There was a big, big gap between them and the Origin vets, most of whom did not play online games. This absolutely led to piles of tension later on when the U9 team was pushed onto the project.

But before that, UO was run out of a couple of rooms on a different floor of the building. You had to walk through an ad agency lobby or something to get to it. The artists had to sit in the hallway because there was no room. And later, when the ad agency, or whatever it was, left, they did a build out; there was a period where the rooms where we worked were the only drywall standing on that floor. You had to walk across the bare concrete to get to the door labeled “Multima” with a color-printed sign tacked up with tape. You could literally walk off the building and fall to your death!

The prototype server sat under the thermostat, so it was always freezing. We used to bring fingerless gloves to work to be able to type. We rarely saw the rest of the company. When Warren Spector’s entire group was dismantled, Richard came up to tell us, and said “as you have probably heard, we did huge layoffs today” and we all looked at each other in perplexity. We had not heard. We were skunkworks.

This was the period where we did things like launch our own marketing website, logo, and even a beta program that cost money, without letting marketing know.

This isolation continued after we moved downstairs back into the main LB production area. And that’s where tensions got uncomfortable. I mean, our team loved things like the Lego or PlayDoh sculpting contests just as much as anyone else at Origin did. Or the prank wars—constant and hilarious. But there was a lot of tension there around questions of technical competence which cut both ways, I think; online vs. single player design; and a big dose of the F.O.R. factor.

F.O.R. meant “friend of Richard.” It’s hard to judge these things now with greater distance on it all. Richard and I get along well. I don’t think any of this necessarily reflects on him. But there was always chatter in the halls about the degree to which the right friendships helped your career. I gather it was just as true for “Friends of Chris Roberts” and so on. There were fault lines in the company. They went between studios. There could be actual hostility if you went down the wrong hallways sometimes, but also within teams.

Ramsay: When you became creative lead, what were your responsibilities?

Koster: At that point, the alpha process where we asked players to send in money to get CDs had been launched. EA took notice and the Ultima IX (U9) project was put on hiatus and all those folks were merged into the UO team. And a lot of them just didn’t want to be there. Andrew was burned out, unhappy, and was let go. I was named creative lead but I wasn’t given managerial authority because, well, I was more junior than most everyone else. I wasn’t a manager. My wife worked on the team. She couldn’t report to me. But in practice, much of the game was built on the things that the original core team had done. Kristen and I were the two designers there. I suppose there wasn’t anyone else to ask to own the creative aspect of the project.

Add in the tensions from a team that didn’t want to be there. These things had big impacts on the UO product after the U9 merge. When Andrew was gone, we had Brian Martin and Joye McBurnett as managers of the design team. I was “creative lead” but I did not have the authority to tell anyone from the U9 team what to do. Well, I had no authority to tell anyone what to do, but the original UO folks would listen to me. Systems were redesigned; original designs were ignored, and so on. Sometimes this was for the good. Sometimes it was for the bad. The resource system, that original design for AI and abstract properties we had sent in as part of our application materials, was one thing that fell victim during this period. Some of it was because it was not going to scale. But a lot of it was because the programmers on it didn’t like it very much.

It was a very weird and awkward period. I had my own work to do, of course. I was still actively scripting things like artificial intelligence for the non-player characters, fruit trees, and object interactivity. I was doing all community management for our beta testers. I was the keeper of the patch notes and update cycle documentation. I worked with the programmers on system design—things like housing. I coded the original interface for that, actually. But I also had to try to herd the cats, and if something went off kilter, I had to persuade Brian to take action. I didn’t have a lot of direct control.

Ramsay: Since UO was a far more massive project than the text-based games you had worked on, were you overwhelmed?

Koster: UO was exhausting. I think we worked six or seven 12-hour days per week for nine straight months. There were so many moving parts. Almost no one had a good picture of what all of them were.

The biggest lessons for me ended up being about scale. Many of the tactics we would use on MUDs just didn’t work at a large scale. Players behaved differently. They were ruder to one another. They were far more powerful, collectively, when they took action. For example, exploiting a bug would cause catastrophic results within hours. We had very little time to respond in times of crisis and we didn’t know that at first. We couldn’t just talk to everyone and get a consensus going. There were too many people to talk to. Simulation systems that worked with a few players broke down with many. Simulation systems designed for truly large groups couldn’t be tested without deploying them to the live audience.

These were issues we never had to think about for MUDs and their smaller player bases. It was overwhelming, sure, but also really exciting. We were moving at top speed and trying to stay on the track.

Ramsay: Although you worked on the creative side, what did you learn about building an online game business during your time at Origin?

Koster: I wasn’t directly involved with the business. But I did get to see the very real and direct consequences of design choices affecting the business. The player-killer problem was probably the most visible of these, costing us tens of thousands of subscribers.

At the time, I held very closely to a philosophical ideal that this should be solved within the context of the sim, rather than with code banning all forms of aggression. I don’t feel that way anymore. My position is a lot more nuanced now. But that original position powerfully shaped the initial experience of UO. I tried really hard to solve a problem in a particular way so that the game would meet artistic goals while also trying to make the business better. I failed at it, and after I was off the team, the game was changed to simply not allow player killing in half of the world.

That was a wake-up call for me: the limits on what we can get an audience to go along with, the extent to which a statement can or should be there, and how much it can affect the bottom line. A lot of people were emotionally hurt by the player killing.

On the flip side, UO taught me that the value of community, marketing, and, in general, building a strong relationship with customers and players just cannot be overstated. Almost twenty years have passed since I first interacted with some of those players; we’re still in touch. That sort of long-term thinking is something that has been sorely lacking in games lately.

Ramsay: Why do you think UO has been able to continue operating for all these years? How long do MMOs typically last?

Koster: If it weren’t for the emergent qualities and the freedoms UO provided, UO would have never lasted this long.

We don’t know how long MMOs can last because we have never seen one be continually invested in over decades. UO is still running today, but it has not seen the sort of graphical overhauls that something like Runescape has received that keep the game fresh and available. If it had, it’d be a web-embedded client running in WebGL or Flash, it’d be available on iPad, and it’d look competitive with other isometric games in full 3D.

I think the longevity of UO speaks to the power of that immersive world, and the fact that it wasn’t built out of consumable content but instead out of the notion of creating a living fantasy world.

Ramsay: How did you go from working at Origin on the Ultima franchise to working at SOE on the Star Wars license?

Koster: There came a point where I wasn’t working on UO anymore. This happened before the Renaissance expansion, actually. I worked on a number of pitches for new titles, and eventually, one of them became a try at a MMO version of the Privateer license. This title was in development for awhile but was then cancelled. When that happened, almost all of our team quit as a unit and we joined SOE. After we went through a couple of pitches, we were asked to do SWG.

Ramsay: Your team voluntarily left? Why?

Koster: Well, the project had just been cancelled, obviously. And the cancellation was a bit of a political thing. We lost out in part because of another MMO being done elsewhere within EA. It had taken a lot of effort to even get started. I had done pitches for multiple other MMOs in the time since I moved on from UO, so it was, gosh, months without a project. I think we were all feeling like EA didn’t know what to do with MMOs.

Ramsay: What did your team do first after joining Sony?

Koster: At first we worked out of J. Allen Brack’s house—some of the other folks were his roommates—and we started developing pitches there in J’s living room. J went onto great things at Blizzard eventually. There was a pirate one, as I recall, and some other stuff that has faded from memory. Then, SOE actually opened an Austin office for us. I would not call the team my team though. It was really Rich Vogel’s team in most ways. He was the one who had the initiative to form a studio and it was he who cut the deal for us with SOE as well.

Ramsay: When did you start working on SWG?

Koster: I guess SOE wasn’t entirely happy with where the SWG project was at that point. Rich and I were asked to go out to SOE in San Diego to look at the games there. They asked us to do a review of where it stood. It was kind of problematic already. There were a ton of great people on it, but the poor guy in charge was designing and producing two MMOs at once which was just impossible. There were a lot of technical questions that were tough open questions. So, we told John Smedley what we thought in a report. And before very long, we were asked to take it over and make SWG more like a “worldly” game like UO than like EverQuest. There was concern about cannibalizing the audience for EverQuest and having a diversified portfolio.

Another big factor was that we had several team members who were veterans of the Wing Commander team. The cancelled project at Origin had been a Privateer MMO, so we had been working on solving action space combat in a MMO setting already. In the end, we knew we couldn’t get that done in time for the initial launch and decided fairly early on to push space combat to an expansion, later called Jump to Lightspeed. But we accounted for its eventual presence in the design of the ground game.

Ramsay: How much of SWG existed already?

Koster: There was a design doc there already, which was a few hundred pages long. A lot of that document was stuff like item lists and monster lists. The main game feature was real-time blaster combat using a “cone of fire” setup to cover up latency, which at the time was an unsolved problem. Planetside was a sister project happening at the same time, you see. The game was built around this feature, and we ended up making the call that, given the timeline, it was too risky to base the game on. Of course, we knew we had to solve this problem for the space portion, but it was a lot to take on for the initial launch.

The game design that was there was also basically about hunting monsters, in the EverQuest mold. That didn’t feel right for the license. I know that some people feel that SWG wasn’t Star Wars-y enough, but that first version was less so. That may be because it had been based on the design or tech of an earlier project called Exodus. Exodus had some really cool tech features in their prototype engine, particularly fractal terrain and freeform building stuff. That lined up really well with what we were thinking, which was also based on fractal terrain and players able to build. But SWG had moved away from the Exodus code base and was instead sharing technology with EverQuest 2, which was also pretty early in development.

There were two tech bases, a design doc, entanglements with two other projects that were at early stages, and a tighter deadline than either one. And we had to go through it all and figure out what was working out and what wasn’t. This was in mid-to-late 2000. Ultimately, we had to switch codebases entirely and redo most all of the design.

This was, politically, very uncomfortable. Resentment was piling up on teams on both sides. The San Diego team felt like their game had been taken away. The EverQuest II guys felt snubbed, too, because we had stopped using their tech. It created a nasty rivalry between the programmers in Austin and San Diego. A bunch of the San Diego team quit over it.

I know from later conversations with people who were on the project before us then that we came off badly when we first showed up; like we were the saviors showing people “how it should be done.” And then we had to build a new relationship with LucasArts, specifically with Haden Blackman, and get a whole bunch of stuff approved all over again.

Ramsay: How do you figure out what works and what doesn’t in a game that isn’t quite a game yet?

Koster: These days, my answer would be small prototypes. Take small parts and build them almost as standalone minigames and try them. Back then, that practice was not widespread. On big projects, it was still mostly all about excessive documentation. You had to try to anticipate everything you could in the design phase. Your chance to tweak the design once you had gameplay came after it was implemented.

On SWG, we did a very extensive alpha period with actual players. This was incredibly unusual at the time. We picked the best posters from the forums, tried to get a good representative spread of player types, and invited them in for testing very rough versions of the systems.

Ramsay: What is a “player type”? Why was a good spread important?

Koster: Different players all approach a game differently, but they do tend to cluster into certain behavior patterns. There are a bunch of different models for thinking about the ways players approach games, including Richard Bartle’s player types, Nick Yee’s research, and personality assessments such as OCEAN, for different market segments.

By having a diverse set of testers, you can better assess when you open the doors to the public and get all sorts of players suddenly showing up. We used mostly Bartle’s model, which was widely used by everyone. Yee’s wasn’t done yet and I didn’t know about OCEAN. We also created forums for various specialties and interests to draw on from a cross-section of players.

This testing was completely invaluable. We were able to do things like test the chat system, the combat system, some of the artificial intelligence, and other things that were completely in isolation from the rest of the game, like just standing in a desert on Tatooine.

Ramsay: How does stranding people in a desert help?

Koster: By putting them in a desert, we were isolating them from contact with anything else in the game that either wasn’t ready for them to see or was not on the testing agenda for that day. It was a way to focus in, to concentrate on specific systems. If you’d put everything in the game in front of the tester, then each system wouldn’t get as deep of a going-over.

Ramsay: What would you try to anticipate in the design phase on a big ­project, especially an online game?

Koster: Everything. Exploits. Fun factor. How hard or easy to implement it might be. The interface design. Player behavior. Interactions with other ­systems. With a big project, you don’t get to iterate in the same way that you can on smaller projects. It takes so long to make things that you don’t get to go over them and redo them multiple times. As a result, you have to do more planning in advance and you have to try to anticipate every contingency of every sort. Unforeseen interactions in systems, how players might behave, what the eventual interface might look like, what happens if there’s a bug… all of those need to be planned for, so that when something does go wrong during the operation of the game—since it will—you have some idea of what to do to fix the problem.

Ramsay: Managers might call that scenario planning. How much documentation does this approach produce? How do you manage all that information?

Koster: I don’t want to give the impression that this was about building scripts to run in the event of bad things happening. We did have run books like that, but they tended to be for operational things like servers going down. In a game design context, it was more about anticipating this stuff and then trying to design the systems so that these things wouldn’t happen.

It can create a lot of docs, but more because you explain your logic than ­anything else. Ironically, despite our ending up with a design bible that was hundreds of lavishly illustrated pages long, that doc probably failed in that respect, because history shows that, by and large, teams running the game don’t always understand why some things were the way they were. I think that is a common problem on large projects. Even if it were all documented, who’s going to read that doc? It’s too big to update and full of obsolete detail. I don’t use giant docs like that anymore.

But you couldn’t necessarily tell from the resultant doc what problem the spec was meant to avoid. A classic example was around the buffs system in SWG. The whole game had been designed around a cap on player statistical advancement, meaning that the power gap between a newbie and a veteran player was supposed to be no more than around 10%. This limited the possible advancement in the sense of raw firepower, damage per second, that sort of thing. Very much not the mainstream current of MMO design – usually you let players get crazy powerful as they level up. In SWG, we were trying to drive cooperation more, and so we said that a single player never became that much more powerful. Instead, for big targets, they needed to cooperate to take them down.

Some folks on the team didn’t understand that or didn’t like it, so they made the buffs system, a system for temporary enhancement of player power up to 400% capability. Nothing in the game was scaled to take that into account. Player progression through the combat game was ruined pretty fast. We had players who figured out how to take down the most powerful things in the game completely solo within a few months.

Ramsay: How often does reality surprise you by either never throwing you into certain planned-for scenarios or putting you in a position where you have no idea about what to do?

Koster: Daily. It’s impossible to anticipate everything, and impossible to think that you can.

Ramsay: Since you can’t anticipate everything, what can you do to spend your time and resources wisely on things that matter?

Koster: Your instincts. Some things are obvious, like possible exploits or player behavior around maximizing reward: “they’ll sit here and do this over and over again for the credits or gold.” Some things are weirder: “they’ll hoard so much gold that they’ll fill up our database to the point of causing slowdowns.” Foreseeable, if you get deeply cynical about human nature, but this stuff is much more likely to catch you by surprise if you haven’t dealt with it before. Some are downright nutty, like players intentionally creating “black holes” by dropping so many objects in one place that anyone coming close would lose their connection, thereby becoming another stuck object and making the black hole grow. That one happened to us on UO.

Ramsay: Public testing obviously helps you find exploits and the like, but you said that the SWG alpha was unusual. Why?

Koster: Alpha tests are common, but what was special about the SWG alpha test was the size and way it was conducted. It was much more like a focus group. We didn’t just let people in to play freely, like the way we ran the UO alpha. Instead, we logged in with the players, walked them through features that were limited to just the ones in the test that day, watched them try them, and asked questions of them on the spot.

Ramsay: Why didn’t more online game companies run tests like that?

Koster: Focus groups are far more common now, but I think there’s always a reluctance to show work that is clearly unfinished or broken. Back then, we only did it because we were up against a deadline and had promised we would be in alpha, but we simply were not ready to run the traditional alpha test. Our alpha was an accommodation to reality that ended up being crazy valuable. You could really tell when the game shipped which systems had gone through that phase of tests and which hadn’t.

Ramsay: After the game shipped, what wasn’t working in early SWG? How did you plan to solve those problems?

Koster: Oh, God, all kinds of things. Not very long before launch we found out that the deployment servers didn’t have as much CPU power as we had planned for. We had hardcoded combat ranges and limits. When the servers groaned under the weight of what we were demanding, we had to go in and manually cut the distances for combat in half, the AI update radius in half, and so on. The entire combat game fell to pieces, in my opinion. Our rifles were designed to be optimal in a combat range that suddenly didn’t exist; it was outside the network update radius!

I am still not sure whether that was related to the issues we had with placement of structures on dynamic terrain, but something simple like “check if this space is empty” never seemed to quite work right. But we didn’t have time to redesign game systems.

Ramsay: What were the biggest problems with early SWG that you, personally, had to solve? How did you solve them?

Koster: One of the biggest was the dupe bug. These days, it is common to have live updated dashboards that generate reports on aspects of your game: how much money is being spent by players, what they are fighting, how fast they are advancing, etc. Back then, we had to do manual database queries. I used to get a report from Chris Mayer with raw data every week. I would spend hours trying to piece together what the data was telling us.

This was how I was able to see that krayt dragons were being soloed far too often—the aforementioned buffs issue. It’s also how we spotted that there was an inflow of money into the economy that was far faster than the amount of currency we were actually spawning. Because the sources of credits were tagged, we were able to identify the problem: players had found ways to duplicate currency, effectively counterfeiting it.

After fixing that bug, we still had the issue that there was a lot of cash sloshing around in the system. We did various things to drain it out, like providing luxury goods at high prices and plain ol’ lowering the “income” level by reducing how much money everything in the game created. We actually ran the game economy at a net loss for awhile, in order to get the amount of cash in the system back into the range we wanted.

We posted up articles about this stuff at the time. They can be found via the Wayback Machine. Graphs, even.

Ramsay: One of the key original features of SWG was the era. Set in an era between A New Hope and The Empire Strikes Back, the Jedi were all but extinct. There would be only a handful of players who had unlocked that class. Some players believed this was changed because the number of subscribers was in decline soon after launch.

Koster: Actually, SWG did not have a steady decline in subscribers during the first few months. The subscriber base grew steadily month after month until the “Holocraze.” I still believe that the Holocron debacle was what stopped the game’s growth and started its reversal. Well, that plus the launch of World of Warcraft.

When we originally specced the Jedi system, it was supposed to unlock in a much more complex and nuanced way than what it eventually was. We had a huge list of all sorts of actions and activities within the game. Climbing the highest mountain, using a particular emote… all sorts of stuff. Every player had a different list; basically, it was a personality test.

We had grouped all of the actions in the game into the four Bartle types. We wanted Jedi to be those players who demonstrated the closest balance between all four or who moved through all four.

Then it turned out that we couldn’t add all that tracking. We had to make a last-minute decision to track something much smaller. That turned out to be skills, as a reasonable proxy. But the issue there was that the means of becoming a Jedi was secret—even most of the team didn’t know how it was done. By reducing the process to skills though, becoming a Jedi was something reducible to a trivial algorithm. As soon as some players noticed the pattern, it would be obvious to all, which is a perfect example of not extrapolating the consequences.

When the LucasArts marketing folks asked when we would see a Jedi, we ran the numbers and the answer was three years. They said, “Start dropping hints to speed it up.” We implemented Holocrons, but dropping hints didn’t just speed it up, Holocrons gave away the secret. This then hugely distorted the play of the game. Jedi were the big prize, you see. Until then, people played the way they liked. People who liked being musicians played as musicians. People who liked harvesting minerals harvested minerals. People who liked killing rancors killed rancors.

Then everyone saw how to become a Jedi and the path was clear: play all those skills that you didn’t like, and that led to everyone botting the skills they hated, people grinding through professions they despised, and so on. Some players learned about stuff they wouldn’t have thought about doing, I’m sure. Maybe that was good for them, but mostly, people gritted their teeth and played the game in ways they hated for the sake of a booby prize called Jedi. That was when the number of subscribers started dropping—not until that feature was in the wild.

Ramsay: Another key feature of SWG was the crafting system. That system was so successful that it hasn’t been matched by any game to this day. Was crafting originally designed to have so much depth?

Koster: Crafting actually got deeper as it was designed. In UO, we had the concept of abstract resources that underlaid everything. We ran into issues when doing things like different types of metals. There wasn’t a way to say “GOLD and STEEL are both METAL,” so I had to hack that in on top of the system. In SWG, we wanted to address that. We started out with the notions of inheritance types: GOLD and IRON are both types of METAL; and the idea of stats, so that IRON could be tougher than GOLD. We also knew we wanted to have turnover in the resources to cause the game economy to have churn and obsolescence.

But the sheer volume of stats that went into it was a surprise to me. Reece Thornton was the designer who really pushed that forward. He added not just stats but a bunch of ways in which they mattered to the crafting system. He elaborated out the “gambling” aspect of the crafting minigame. We kept pushing him to hurry up. We thought that the crafting system was getting overcomplicated. In the end, I think we happened to land at a sweet spot.

Ramsay: What other takeaways from UO did you apply to the redesign and reengineering of SWG?

Koster: Tons and tons. They really were very different games in many ways though. UO had a pure use-based skill system: the more you did something, the better at it you got. In SWG, we changed that for an experience point system, but one where you earned points for a wide array of different activities. Basically, we added one layer of indirection into the mix. This let us have skill trees with some branching choices whereas UO had a linear path for every skill.

UO had also taught us a lot about the value of dynamic environments, the way players loved housing and building, the way they loved pets, and so on. All of those things in SWG were about capturing that and trying to make it even better.

Ramsay: What about content? I don’t remember that UO had much of the linear, directed quests we see today.

Koster: SWG was supposed to have lots of content, but we ran out of time to implement even a decent quest system or even a library of reusable scripts for quests. The scripting in SWG was dramatically harder to use than in UO. I had expected scripters to build cool custom quests like the ones we had done back in the LegendMUD days. Instead, it was so hard; we barely got anything in at all. The industry then moved on to fill-in-the-blank Chinese Menu quests; we didn’t even manage that. Basically, I think of content in that game as a big fail.

Ramsay: Earlier, you mentioned that you accounted for space combat in the design of the ground game. What do you mean you actually did?

Koster: In planning the skill trees, we designed it in such a way that it was easy to add crafting stuff related to ships and new professions. The systems for joining the Rebellion or the Empire were also set up to accommodate eventual piloting. We knew we wanted mouse-driven space combat, so that part was basically partitioned off. It was more about leaving the space for the space parts so that they would slot in naturally when the time came.

We could have used design elements that were better left to Jump to Lightspeed, for example, by putting spaceship engineering into the ground game and having it just generate cash. By holding off, we made it tie together better. We could have made the way you advanced in the Empire or the Rebellion not work well with the eventual addition of having ships. That sort of thing. But, really, one nice thing about the skill system in SWG was that it was easily expandable in those directions.

Ramsay: Speaking of the ground game, was there a reason for debuffs, or “state attacks,” like Dizzy and Knockdown, which made the player unable to move for an extended period? I’m sure there are SWG veterans who would love to know who thought those were good ideas!

Koster: State attacks were directly inherited from classic DikuMUD gameplay, which included stun effects and the like. You would try to stun an opponent to be able to deal extra damage. Every state was supposed to have counters and defenses though. Frankly, the system was never well-balanced. In particular, these effects suffered a lot because the core Health-Action-Mind statistical system wasn’t working right. It wasn’t tuned to match what was originally intended, which was a much faster regeneration rate, so we don’t even know whether it would have even worked out as designed.

Ramsay: Over the years, SWG changed radically, reportedly due to pressure from LucasArts—from the buffs system to the Holocraze and later to the Combat Upgrade and New Game Enhancements in 2005. Was there ever a singular, overriding vision? If not to provide that vision, what exactly was your role as creative director?

Koster: I don’t think all of the changes were the result of pressure from LucasArts. I think—and this could be my memory playing tricks on me—that the Combat Upgrade happened because of internal team pressure to fix broken combat, which was in turn caused largely by the buffs problem and the broken Health-Action-Mind statistics implementation.

There certainly was a singular vision early on, but a singular vision doesn’t mean a shared vision. You have to ride hard on it and people have to commit and recommit to it. I think that after awhile, the vision just sort of evolved. There were folks who bought in. There were folks who didn’t. There were people who didn’t even know what it was. Particularly in the face of live operations, it’s often deeply impractical to privilege a vision over the day-to-day of keeping your players happy.

As far as what a creative director therefore does, the creative director tries to set and enforce a vision to maintain consistency across the game while serving a master—in this case, multiple masters, because we had a license holder in the mix. But I don’t think of the role of creative director as a dictatorship, which I have been told is a failure of mine!

Ramsay: You’ve mentioned how SWG was influenced by DikuMUD and UO, but when we started talking, you said that the cancelled Privateer Online project at EA was a big reason why SOE brought the Austin team into the fold. How did your experience with Privateer Online shape SWG and Jump to Lightspeed?

Koster: Privateer Online was intended to be a procedurally created galaxy worth of planets with active trading between colonies on different worlds. For this, we were exploring a variety of procedural techniques, as well as thinking about means of doing economic structures in games. Both of these turned out to be very important directions for SWG, but both had to be completely reinvented because the games were so different.

For example, in SWG, we had only a few planets, not hundreds, so everything we had done around procedural planet generation was useless. Using procedural tools did unlock deformable terrain, player housing, vast planets, and a lot more. We had opened new doors by extrapolating from older thinking, although the new use case was completely different. The in-world economy was a similar situation. I’m not sure we would have arrived at such a dynamic economy in SWG without the thinking we had done on Privateer Online.

Ramsay: Can you tell me about the economy? What made the economy so dynamic and central to the game?

Koster: SWG generated new resource types on the fly, based on the master resource types. The master ones were set up in an inheritance tree, so we had IRON as a child of FERROUS METAL, which was a child of METAL, and so on. Each type had a range for its stats, so we could roll up variants. They could then get mined out and be gone, like really actually gone from the game. Eventually, we’d roll up new stuff, but it wasn’t at all guaranteed to be direct replacements. It might be NON-FERROUS next time, for example.

When a player crafted something, they experimented with it, which was basically a little gambling and point allocation game. They could use any materials at hand. When they got a result they liked, they could “freeze” that result into a blueprint, which would then forever call for exactly the specific materials used in that run. Players could then mass produce that item, but when materials ran out, the blueprint became obsolete. The item couldn’t be made anymore and maybe couldn’t get major repairs anymore.

This resulted in constant turnover in the game economy. You couldn’t just sit on your laurels. There was always a competitive crafting environment.

Ramsay: In the middle of your efforts to bring SWG to market, there was politically uncomfortable tension between the teams in Austin and San Diego. Did that tension ever subside?

Koster: Gradually. Split locations always meant communication problems. Those issues never went away, but I’d say that a year in, the worst of it had passed. Once people start working together on a daily basis and get to know each other, stuff like that just dissolves.

Ramsay: In retrospect, what could you have done to foster greater cooperation faster?

Koster: I honestly don’t know what we could have done to make cooperation go faster. I think we probably laid groundwork for the challenges from the very outset by coming in with an attitude of “we need to get this going” rather than a very conciliatory attitude. We, meaning the Austin team, aggravated the early tensions by coming across as know-it-alls to a team that had just suffered a big disappointment. It took us a little while to realize that was what had happened. I think we did a lot to try to fix that, but we had gotten off on the wrong foot.

Ramsay: When did you leave the SWG team?

Koster: Close to the end of the development cycle for SWG, I was offered the chief creative officer role. I think I officially started just as SWG wrapped in June 2003. I worked out of the Austin office at first. Six months later, I was living in San Diego. In that job, I consulted on titles in development, trying to help them out. I did a lot of public relations work. I helped out on pitches and business meetings with potential partners. I also ran a small R&D group focused on speculative technology and gameplay.

Ramsay: What do you mean by “speculative technology and gameplay”?

Koster: I can’t talk about most of what we did, but it was quite a mix of “stuff.” The purpose of the group was to push at boundaries, basically. There was work involving social graphing that was way ahead of the curve, there was graphics technology, and there was a game project. From a technical point of view, the biggest thing that came out of that group was actually submitted as a patent. That’s in the public record and you can find it by Googling me, so I suppose I can mention its existence. The work involved using the principles of cellular automata and artificial life to generate living landscapes and worlds. The goal was to make simulated virtual worlds that were way more interactive and responsive than what was around at the time.

Ramsay: Why did you break out on your own with a new company? It doesn’t sound like you were designing games. Was that a factor?

Koster: My duties at Sony had me attending a lot of web conferences and meeting lots of folks from Silicon Valley. By going to events like Web2.0, Supernova, ETech, and so on, I was exposed to a lot of Web 2.0 thinking. A lot of it was radical and different thinking, coming as I did from the MMO role-playing game (RPG) market, which itself was a big shift from packaged-goods games. A lot of it also resonated very strongly because, of course, virtual worlds were on the cutting edge of the online community in a lot of ways.

Many of the practices we take for granted today in online social software—persistent profiles, reputation systems, badges, titles, and so on—were pioneered in virtual worlds. It took a long time for some of this stuff to make it to social networks, which didn’t come along until a few decades after virtual worlds did.

I saw a convergence coming. I would return from these conferences and try to convey to folks back at the office the things I had heard about—ideas like the long tail, digital distribution, user-generated content, and the rise of browser applications. Sony was interested in these things, but it does take a long time to turn a ship that big. The very long development cycle of traditional MMORPGs—where thousands of people run around in the game, slaying monsters, gathering up treasure, and making their characters more powerful—meant that it would take quite awhile for some of these lessons to be absorbed. The traditional MMORPG model was largely taken from their predecessors which were text-based MUDs. There aren’t many MMORPGs that aren’t like this. There was a lot more diversity in the text-based days.

In parallel with this, there were some changes in my duties at the company. I had been working in a role where I wasn’t making games directly and I missed it. As some organizational changes happened, it just seemed like the right time to go exploring this new territory. So, I set out to do something that was webby, independent, and centered on user-generated content. Luckily, all that time spent in the Valley meant that I had gotten to know a lot of well-connected folks from the venture-capital community.

Ramsay: What happened that caused you to leave?

Koster: Well, the core trigger was the disbanding of my R&D group. I had been spending an awful lot of time on meeting with people in Hollywood and those meetings never seemed to pan out. It just felt very unsatisfying, so I began to miss being involved with the hands-on creation of games. I had discussions with my bosses and got an R&D group started. We were working on some very cool speculative technologies for virtual worlds, many of which are still unmatched today in my opinion. But because of some high-priority projects that needed to ship, my team was gradually reassigned to work on game teams. Soon after, I was asked to head one of those game teams, too. The project was one that I didn’t have passion for. On top of that, the things that I was interested in were pretty divergent from the product plan at SOE at the time—I wanted to chase after web technologies, social networks, the social web, user-generated content, and so on.

Ramsay: When did you begin talking to VCs? What was your experience with raising capital for Metaplace?

Koster: I didn’t have any experience with raising capital at all. I had met many VCs and angels while I was attending these conferences. Among others, I had made contact with Reid Hoffman, who is incredibly well-connected in the Valley; we were both attending a conference in Switzerland for several days. It turned out that an old acquaintance from the days when I worked on multi-user dungeons (MUDs), the old text-based virtual worlds, had started working in venture capital—Susan Wu. I had met a variety of folks from the Valley at conferences, including Jason Hable and John Borchers of Crescendo Ventures, and had phone conversations with them about industry trends. So, there was a lot of informal stuff: just happening to meet people without any formal contacts or anything. At the time, I wasn’t contemplating raising money; I was just doing the thing I usually do at conferences, which was meeting people and chatting.

I didn’t start formally talking to VCs until after I was gone from Sony, of course. It turned out that several industry friends were starting initiatives of their own around the same time. Some of them were founding companies, like Jim Greer at Kongregate. We overlapped briefly way back at Origin. Some already had companies, but they were exploring projects in the Web 2.0 space, such as Daniel James at Three Rings, who was a friend also going back quite awhile. So, I had people to reach out to for advice.

Reid was probably the biggest single help early on, spending a long lunch with me and giving me introductions to a half-dozen possible sources of funding, to law firms, and so on. Our company lawyers, Stubbs Alderton, came out of that conversation, and really, from that point forward, Scott Alderton was my chief adviser during the funding process. None of the funding introductions Reid provided panned out in the end, but I got to meet a lot of great people. And I approached everyone in terms of asking for advice, not in terms of pitching something, at least not at first.

I do think that having a track record and a reputation was a huge help. It allowed entry into conversations, made it far easier to cold-call people, and made people more interested in what I had to say. But the biggest way to build that reputation is to share things yourself. By sharing ideas and information at conferences, I had made myself someone interesting to talk to, and someone perceived as, if not an authority, at least someone who was paying attention to the space.

The other thing that I suspect helped just as much is that I started building a prototype in our spare bedroom and was getting something working. I had agreed with my wife that we’d try to get something going for six months or so and see how far we could get. I wasn’t going to wait for money to show up. I just started working the phones and the compiler on the day after my Sony contract expired.

Ramsay: Why were you meeting with VCs?

Koster: Well, at first, I didn’t really quite know what I wanted to do. I assumed I needed to raise money and get a team to be able to do anything. But I started sitting down to code to try stuff out and stuff just sort of started to click. I had thought that I would just try sticking a graphical front end on a text MUD as a starting point. Keep in mind that my programming skills were pretty atrophied. I had been making puzzle games for fun on weekends but I hadn’t done any coding for work while at SOE at all.

I started out getting a basic 2D engine going then slowly added isometric views and networking code and the like. It was a lot of fun because I basically had to relearn how to do everything. I had never written a user interface library before but I had to learn how to do this.

Meanwhile, I was meeting with a lot of VCs, at first just for advice. I started out with just “virtual worlds for everyone; let anyone make their own.” The further I got into my prototype, the more it crystallized. I went and got a logo done. I put together mockups of the possible portal page for the user worlds. It looked a lot like a YouTube for virtual worlds, with featured worlds, categories, and all that.

One VC flew down in his private plane. He liked to fly, so I guess meeting me was a good excuse. For others, I flew up to San Francisco or Palo Alto. A lot of these meetings I got thanks to Reid Hoffman’s introduction. I was new to the game. I didn’t go in pitching. I went in saying “I’m thinking of doing this,” and not at all like what I later saw in the Valley game of pitching up and down Sand Hill Road.

Crescendo Ventures showed interest pretty early on. And at one point, I told John Borchers, “I’m getting far enough along that I wonder if I shouldn’t just launch this.” That was apparently part of what pushed them over the edge into offering to invest.

Ramsay: Sounds like you were asking a lot of questions during this time. What didn’t you know? What questions were you asking?

Koster: Who should I talk to? What should my pitch deck look like? How much should I be raising, and what valuation should I look for? What do venture capital deals look like? What sort of team do I need to maximize my chances of funding?

Ramsay: What did you expect to gain by asking these questions? What goals were you intending to achieve?

Koster: Well, the most basic answer is that I hoped to get funded! I figured that knowing more about the process—remember, I had never done anything like this before—would increase my chances of success. As it happens, the introductions and the advice that I received through this process netted me a lawyer, important contacts, and, in general, helped enormously. The advice of people who have done it before is worth a lot.

Ramsay: You designed the Metaplace platform to “enable anyone to create virtual worlds.” How did you come up with that idea?

Koster: It’s important to realize that user-created virtual worlds weren’t a new idea at all. It was how the field had started, and the biggest reason the field had drifted away from it was because of the requirements that 3D graphics imposed. But Second Life was out already, the apartment idea was being executed very successfully by Habbo Hotel, and there were many other projects going with a “user-created virtual world” bent.

I had been tossing around the idea of user-created virtual worlds literally going back to the UO days. At one point, I proposed that we would allow players of UO to make their own parallel worlds, as a response to the “gray shard” phenomenon—users were creating their own servers that were compatible with the UO client. I figured that meant there was pent-up demand. But that idea didn’t go anywhere. We, of course, did player housing.

For me, this was a natural evolution from the text MUDs—the text-based virtual worlds. They were based on the idea that there was a server codebase that was publicly available, and in many cases, the creativity and advancement of the medium came about because people took the existing servers and reworked, extended, or simply used them well to create whole new worlds and rule sets and experiences.

With SWG, we had done not only housing, but player cities. We really tried to allow players to affect the map in greater ways. And later, in talking about webby stuff with Sony, I had brought up the idea of creating something that allowed people to basically build their own apartments and connect them together and create objects to put in them. It was still a heavy 3D sort of environment in conception though and still in the mold of the MMORPGs so to speak, rather than what we ended up with. That project also didn’t go anywhere; in fact, for a little while, it morphed into an action role-playing game!

Once I was off on my own and contemplating making something, the prevailing currents of Web 2.0 thought were very much about users contributing content and creativity. And I was driven in part by the fact that I saw the MMORPG industry hitting a wall because of the rapidly rising costs of developing these giant 3D extravaganzas. In approaching the very general notion of user-created virtual worlds, starting from the webby premises, I landed in a very different place. I wanted to “do Second Life right” in a sense by tackling what I saw as core architectural issues that limited both its accessibility and its scalability.

Ramsay: What issues were those?

Koster: Well, to my mind, Second Life had several big issues. First, Second Life had technical scalability problems. There were aspects of the system that were baked in early on that led to challenges later.

For example, individual objects in Second Life were very heavy. To get nice-looking objects, you had to compose them out of primitives, or “prims.” Prims were mathematical solids that had a few parameters attached to them. This meant that making something with complex geometry required you to use a lot of prims, so then you started having things like prim budgets. Since the world was seamless, but chopped up into little regions called “sims,” which is short for simulators, you had to worry about budgets per sim. The use of prims also meant that bringing in content from outside was challenging. It wasn’t until much later that Second Life allowed users to import standard 3D object formats.

You also couldn’t easily make something that truly felt like a different place—say, with different rules of physics—because you were sharing one world with everyone else. It wasn’t a Web-friendly platform in other ways, too. You needed to run a pretty demanding 3D client at a time when lightweight experiences like Facebook and Twitter were gradually taking over our Internet lives. All of these things together, in my opinion, led to Second Life really limiting its eventual audience size.

Ramsay: You wanted to do something webby, independent, and focused on user-generated content. How far did you get with the prototype?

Koster: When I started out building the prototype, I was limited by what I could make in my spare bedroom. That meant I couldn’t do advanced graphics for one. I also had to rely on extremely simple forms of network communication. I basically had to learn a whole bunch of programming I had never done, like networking and user-interface stuff. I built the prototype client in BlitzMax, which is a sort of object-oriented variant of BASIC, and for a little while, I used a MUD server just as something to hold stuff to send down to the client. The architecture was tag-driven, using plain-text tags, so I just put the tags in the room descriptions!

The prototype ended up able to load a map that was a 3D heightfield, display it in the client, move a simple little alien dinosaur thing around on the heightfield, and load up terrain tiles and objects with images attached to them. It could save and load world data up to a remote site. I got pretty far with the terrain editor, too. I had also found a web plugin that enabled me to wrap this client into an ActiveX control, so you could use the client on a web page. I had conceptualized the notion of a tag language for the network protocol. And I had started putting together the high-level architecture design for how the technology would work, basing it on the LAMP stack that was driving so much innovation on the web.

The prototype evolved over time into a Metaplace client that we actually kept alive for another full year or more.

Ramsay: You had a big vision for the platform early on. Can you tell me about the role you saw Metaplace playing in the future?

Koster: Metaplace was explicitly designed to become a standard platform for virtual worlds on the Internet. Basically, it was designed to mimic the web stack because we saw that as the enabling force behind the explosion of web technologies and companies. It was architected to have components much like the LAMP stack: a generic browser, a text-based tag language, a generic server, a scripting layer equivalent to CGI, a name service layer for running a distributed network, and semantic tagging for search.

The plan was for there to be clients on multiple platforms, so that you could experience the same virtual-world content on any device. We never delivered on this promise to any end users in the user-generated content days. We pretty much focused on Flash as we pushed the “network of virtual worlds” product. Once we started deploying Facebook games, we made technology choices that locked us into Facebook and Flash more tightly, and that required work to undo. This made transitioning back to the multiple-client model harder, but not impossible.

In terms of a business model, we saw ourselves starting out with providing hosting for worlds, and evolving over time into running the network, owning search, and the like.

We were also chasing democratization. The Web 2.0 experience was one where users were empowered to contribute content. We were definitely interested in making the platform as open as possible for people, and putting worlds on the web as widgets, basically. The prevailing mode of virtual worlds was very much full-screen clients in heavy 3D with some thoughts that, a la Snow Crash, the worlds would swallow the Internet. We saw the reverse happening: the web swallowing up virtual worlds.

This turned out to happen, of course, only far more thoroughly than we thought. The “placeness” of worlds got lost in the process, and today, we have Facebook instead!

Ramsay: When you presented your vision to prospective investors, how did they react? Were there any concerns?

Koster: At the time, virtual worlds were a hot area for venture-capital investment and so were various sorts of web games. Generally speaking, there was a fair amount of receptivity to the pitch.

I went into the pitches, explicitly stating that I was not intending to be the chief executive of the company and that role was not what I preferred to do. I think that this allayed some of the concerns investors might have had about my experience, which was all in big companies rather than startups.

Some of the folks I talked to didn’t know the space at all. I got the best rejections from those who were completely upfront about that and backed out, saying that they didn’t really know what they would bring to the table.

Ramsay: Best rejections? How can a rejection be good?

Koster: When you are fundraising, one of the worst things is to be left dangling.

Ramsay: At what point did you start putting together a team? Who was your first recruit for the team?

Koster: In practice, the process of going from zero to having an office, having funding, having a cofounder, and being able to hire a team took six months. We didn’t start hiring really until January 2007.

But the first team member was my cofounder, John Donham. We had worked together for years, starting with SWG, at SOE in Austin. Later, we moved to San Diego, although not at the same time. When he took over running the San Diego development studio, I took the chief creative officer role. I think he was the one who suggested to John Smedley that I might be a good fit for that job.

Ramsay: Tell me about your first office. How did you choose the location?

Koster: We looked at a number of neighborhoods around San Diego. We used a commercial real estate company to help us find the location. We were limiting ourselves to certain budget ranges—class-B office space and that sort of thing. We didn’t need too large of a space either. There weren’t many different locations that met those criteria, and in the end, we ended up in a building in Rancho Bernardo. We were quite close to where I lived, too. I could actually walk to work! We ended up remaining in that building for most of the company’s life, but we moved offices within the building twice more as our employee count changed.

Ramsay: How did you determine your initial staffing requirements? What capabilities did you need?

Koster: There were a few roles that were tricky to fill, where we had to make tough choices, but the initial needs were pretty simple. We needed someone to work on the server, someone to work on the Web, someone to work on the client, an art director… you get the idea. We wanted to be highly community-driven, so having someone who was a community person early on was also important.

The first few roles on the team were pretty apparent early on. If I had to identify a need that we didn’t really satisfy at the start, and should have, I’d say that business and marketing were underserved. We had someone doing business development and the day-to-day management needs were met by John, my cofounder. But we really could have put more effort into narrowing down our possible target markets. We just had too many of them.

Ramsay: Your technology was still in its infancy at that point, right? What was your next big challenge?

Koster: The immediate challenge was building the technology. Although, in retrospect, we spent more time working on the technology than we should have, and we spent less time working on marketing than we should have. We should have built the technology platform and developed one game: one game that the audience would want to play and build on. Having that one game would have unlocked the modding community, which would have possibly grown to the other aspects of the platform’s potential.

In practice, most core elements of how the technology worked were established relatively early. The big questions ended up being about the purposes of the technology. In some ways, that was a challenge we never overcame. These days, that’s called product-market fit on the entrepreneur blogs.

Ramsay: Why was building the Metaplace platform difficult?

Koster: Well, first, there was the infrastructure for the content. To make user-generated content for a virtual world, you need a virtual-world skeleton to start with! There’s the world server, which runs the simulation, etc. Then you need a way for the server to talk to clients and a way for the user-provided assets to get to clients, which if anything could be moderately challenging. Then, of course, uploading just pictures and sounds isn’t as compelling as creating behaviors for things in the world, so you then have to start working on a scripting system.

And after you have all that, people will ask for tools and capabilities. How about physics? How do I make my image anchor at the center rather than the top left? How do I display user interfaces? We ended up creating a whole user-interface markup system for that.

In the end, the core capabilities of the system came relatively swiftly—in months. The tools to actually use those capabilities took years, and we continued to work on them post-acquisition.

Ramsay: That’s right, Metaplace was live. When did you launch? Did live, feedback-driven development challenge any of your assumptions?

Koster: We started letting in alpha users toward the end of 2007 after launching at the TechCrunch 40 conference. We let in a fairly limited number of alpha testers, as well as some potential business-partner developers who were trying out the system and considering using it for their own commercial projects.

We were immediately drowned in feedback. The tools were too complex! They were too simple! We needed to have dedicated support for professional developers. We needed to make everything self-explanatory for consumer-level customers. We needed a friendly web-based editor. We needed deep integration with Eclipse, a common professional-grade integrated development environment. We had not been selective enough about the types of customers that we wanted, and as a result, we got unclear direction back on how to alter the product.

The fundamental issue was that we had a system that solved many separate problems for separate audiences. And it was very hard to pick a specific audience once you had a Swiss army knife that did the trick for several markets because doing so meant giving up the users we had. Supporting multiple levels of user turned out to be our Achilles’ heel. We were prevented from making the product awesome enough for any one of them.

Put that way, it sounds simple, but the architecture and business model depended on having an ecosystem of more- and less-advanced users. So, drawing the lines was very hard.

Ramsay: Was there ever a point at which you thought “we need to find a new business model because what we’re trying to do just isn’t working”?

Koster: We did this several times. One pivot was from a more tools-centric website that was focused on builders to an entertainment destination website with a central virtual world where users could explore everyone’s worlds. Basically, one looked like YouTube and we pivoted over to a product that was more like Second Life in a web page. There were four or five different tries at a product there; none of which succeeded.

Ramsay: What were the other tries at a product? Why didn’t they work out?

Koster: I don’t want to overstate the word “product.” We suffered from a lack of very specific product direction.

At one point, we were discussing being a tools company. The orientation then would have been toward doing middleware. We even had an external developer who was working on a commercial project using the tools at one point and hired someone just to support them. But this was a direction we did not pursue; although, Unity eventually proved this strategy very successfully. We did live with the legacy of supporting advanced developers from then on though, which meant that we never focused purely on casual consumers.

At another point, we were in the habit of referring to ourselves as a studio and talking about creating content internally. We had vision docs for two separate web-based MMOs that we were going to build with the technology. Neither one got anywhere because being a content company, as opposed to a platform company, was not the sort of thing that a VC-backed firm did then.

At yet another point, we had deals on the table—this happened more than once—to build web-based MMOs for other companies. We walked away from being a white-label studio for much the same reasons that we walked away from doing original properties. It’s worth pointing out that at least one of the deals we walked away from was picked up by someone else and became extremely successful.

We tried being, essentially, an online virtual-apartment sort of builder. We were way too complex for that because of the scripting legacy, but we also simply never marketed. Other companies, such as MyMiniLife, were able to build giant audiences with relatively simplistic technology. They eventually became the technical backbone for much of Zynga’s game portfolio.

We tried doing embedded worlds and games on websites, but we didn’t sign any partners. And the fact that we weren’t making content for them meant that they had to do all of the heavy lifting. We also talked a lot about being a distributed virtual-world network, but we didn’t pursue the extremely important feature of allowing users to cash out.

And we launched on Facebook with a super simple, little chat space in early 2008 at a time when we likely had by far the best technology for Facebook games on Earth. But we backed away from Facebook and didn’t try again until much, much later—and unsuccessfully even then. We never even considered launching casual games on Facebook, which was likely a massive mistake in hindsight.

I could go on, but the common thread is we lacked a deep commitment to a single direction. All of these were potential uses of what was, in the end, an extremely cool and powerful technology. With time, perhaps all of them could have come true. But we needed one profitable one early on and we needed to focus on that one way of using the technology.

Ramsay: Where did you finally end up?

Koster: The biggest pivot was moving away from user-generated content altogether, closing down the public virtual world, and switching to using the platform as an internal tool suite for the development of social games. This turned out to be successful, leading to two successful Facebook titles and then our acquisition by Playdom. It was an extremely painful pivot though.

Ramsay: Extremely painful. That’s an interesting way to describe a change in strategy. Why was this pivot so?

Koster: Changing over was pretty traumatic. We had to shut down the live user-generated content service because, as part of the pivot, we could not afford to devote resources to it. There was a strong albeit small community there, but we were running up against huge financial pressures. We had to move really quickly. As a result, I fear that it felt pretty abrupt to a lot of folks. We tried to do everything we could to soften the blow, but it was still very painful. We held a party on the final night that the service was live. I played a live concert that we streamed out to users who showed up. It was a pretty emotional night.

At this point, as part of the pivot, I also wasn’t running the company myself. I had asked John to take over as the chief executive since our focus was very much moving toward internal production.

Ramsay: Why did you ask John to take over your role as chief executive? Were you unhappy in that position?

Koster: It was an exhausting role, certainly, but the reasons were more complicated than that. It increased the chances of our landing the bridge funding that we needed to pivot to social games. John’s background was specifically game production. Having someone running the company whose primary expertise was “shipping games” seemed like a smart move, given that we were engaging in a very specific strategy of shipping high-quality games at a rapid pace.

Ramsay: What changes did this pivot entail? For production? For the product?

Koster: We had a lot of process changes, and yes, design and technical changes, in order to better suit the platform for social-game production. Architecture choices had been made based on the idea that nontrusted users from anywhere in the world were going to be using the tools. There were compromises, too; security systems, fail safes, and much more had been put in place for that particular audience. The core of the technology remained intact, however.

Moving to an internal programming-savvy audience meant a very different set of demands. Ease of use, and robust yet simple tools, were still very much virtues, but there was plenty we had to change in a real hurry. We ended up making those changes largely due to the pressure of success. We made our first game, Island Life, in about a month, and launched it and got more users on the first day than we had ever gotten for Metaplace.

Trying to scale the game really quickly to the sort of audiences that exist on social networks led to many changes to the technology. We had to scramble on many fronts: the persistence system, the metrics system, greater support for Flash as an asset type in the engine, and even platform features that needed to be taken out or redone to improve performance.

We also had many cultural adaptations to make when we changed over to the heavily metrics-driven environment of social games. This was particularly challenging for me. I am a huge fan of metrics, but I also like digging for the why of things. Metrics, as practiced in the industry at that time, didn’t much care about why.

Ramsay: Did you adapt to that “unscientific” metrics culture? Did you continue to ask “why?”

Koster: I wouldn’t call it an unscientific culture! Rather the opposite. I’ve always been an advocate of better metrics in online games. I used to do quite a lot of metrics gathering and analysis on SWG and other titles. The culture clash though was very real because the emphasis on metrics penetrates everything and causes you to re-evaluate what your definition of “a better game” is. But the biggest hurdle for me was getting used to releasing things as tests first instead of as updates. There are some folks who make companies because they are excited by the process of making companies. And then there are some who are excited by making a specific company. There are some designers who are excited by the process of creating something that meets any need whatsoever and then some who are excited by making a specific product. I happen to be the latter sort. That means that testing to identify a product is something that just feels weird. Tests only seem to work for some types of products, some types of approaches, and they encourage having little loyalty to a given idea. Don’t get me wrong: I am a huge fan and advocate of metrics and playtesting, but it definitely took a mental adjustment for me.

So, testing changes that were largish wasn’t something that we had figured out early on and many possible updates to Island Life in particular were left on the cutting-room floor. Many of these were pretty frustrating for me because I believed that these changes would be for the better.

Sometimes we did things without testing, too. An example of that would be the way we handled land expansion in Island Life and later in My Vineyard. Rather than simply expanding the grid—the way that virtually all social games did—we let the player expand their space piecemeal, which added a bit of a sculpting element to the game. You could shape your island into particular shapes. Today, many games do expansion in a similar way, including the market leader. But at the time, we didn’t test that one, and we got lucky. Early on, our hunches were only right around 10% of the time.

Ramsay: What were some of the hunches that were wrong?

Koster: Oh, we were wrong many times when tried to apply what we learned from MMO games to web-based games. The area where we were most often wrong was usability. We were wrong about the degree of tutorials needed. We were wrong about the impact a given feature would have. We just made things too complex. Just over and over and over again.

Another side to the metrics lesson was that metrics really don’t tell you “why.” You have to tease that out, and for that, classic design training is enormously helpful.

Ramsay: How does your classic design training help you tease out the why from the metrics?

Koster: If you operate with just metrics in a vacuum, you can see when A versus B has differing results. Anyone can form a hypothesis, but having a broader background in design helps you to faster reach an accurate one. Sometimes, of course, that same background can prevent you from acknowledging the truth, too.

But when the time comes to forming a new idea about how to push the metric dramatically higher, that’s where design comes in handy. Metrics are best suited to tuning and iteration, not to quantum leaps pushing you forward to new heights. Metrics optimize the peak you are on, but they don’t find new mountains for you.

Ramsay: Let’s switch gears. You have a family. What impact did the startup have on you and your family?

Koster: Well, it was hard at times. I missed all of the family vacations for nearly four years. I barely took any time off for those years, too. And the years that I missed were the last years before my kids became teenagers and began to pull away. Work was all-consuming. If my wife hadn’t been supportive, I don’t think I could have done it.

At first, I worked out of our spare bedroom and there the challenge was teaching the kids I was working, and not just at home to play with. But during that period, I was pretty accessible to the family.

For the middle phase of the company, our offices were quite close to where I lived—a three-minute commute that was walkable, if I wanted. It was then possible for me to stay home later in the morning, or to go home for lunch, or to go home for dinner and come back after. Although, honestly, I usually just got home very late.

When we pivoted to doing social games, we moved offices, as part of effecting cultural change at the office and getting a clean slate. I suddenly had a 20- to 30-minute commute. And that change, along with the shifts in responsibilities and changes in what we were trying to accomplish with the company, led to a lot of personal re-evaluation.

I very much regret having missed those years; although, I don’t regret trying to chase the dream that I did. But I also promised myself that I wouldn’t compromise home life for something I didn’t believe in passionately, and now I maintain a more rigid line about bringing work home.

I’m about to turn 40. I don’t want to sugarcoat it: I gained over 30 lbs. I developed high blood pressure. Entrepreneurship was a very stressful process. While I loved doing it, I also love other things about my life, such as my family. I did not know the toll when I started. I probably would have been a bit more invincible when I was younger!

Ramsay: How did the acquisition by Playdom come about?

Koster: Once we had pivoted to social games, we had basically pivoted into a pretty frothy market where many companies were making acquisitions for growth and strategic reasons. With our first couple of games, we got enough traction to attract the attention of several of them.

A big part of what people noticed was the pace at which we were able to release the games that we had made, which was attributable in large part to the technology base we had. Some of those conversations grew more serious, and one of those conversations was with Playdom. We ended up deciding to work with them because of their amazing reach in, and knowledge of, the social-games space.

Ramsay: Who was involved in the discussion about selling to Playdom? What did you talk about?

Koster: The executive team: me, John Donham, and Jason Hable. Playdom was only one of a few candidates who were speaking with us. The decision came down to factors like whether we were confident in the future of the acquirer, what their plans were in the video game space, the length of the lockup period in our contracts, what roles they wanted us to take, and the size of the deal. All of those issues played a part in our decision.

Ramsay: How did you personally feel about giving up independence? Was owning your destiny ever part of Metaplace’s identity?

Koster: It was hard. Owning our destiny was a big part of the original Metaplace story. And here we were putting ourselves not only back into a big company but into Disney, one of the largest ones out there. For me, personally, I was excited about the potential for Facebook games within a large company. I had correctly forecasted that smaller players would be forced out of the market, but I also knew that there would be a lot of hoops to jump through to get anything greenlit.

Ramsay: Disney bought Playdom soon after Metaplace joined Playdom. What was that like?

Koster: From where we sat, that all happened simultaneously. A deal as large as Disney’s acquisition takes a long time, so that deal was being made in parallel with our own. In a lot of ways, I ended up doing more work with Disney than many of the Playdom folks.

Ramsay: How did you end up doing more work with Disney?

Koster: I don’t know how much I can say. Basically, because of the technology that Metaplace brought to Disney, I ended up having conversations with a lot of folks in the larger Disney organization from pretty early on. There were a lot of folks who I knew within Disney from earlier work, too. I knew Lane Merrifield from the days when Club Penguin was a startup on the conference circuit. I knew Starr Long from UO, of course.

Ramsay: You seemed to be drifting farther from Metaplace under the Disney banner. Were you?

Koster: I wasn’t in charge of the Metaplace technology anymore. Early on, I was involved with executive-level stuff at Playdom, but after awhile, as the union with Disney progressed, there was less and less of that. I was doing “internal consultant” sorts of things for a bunch of titles while I was there. Several shipped; a few didn’t. None of the ones that shipped set the world on fire. A lot of those were very “light touch,” so to speak. I was not very involved.

Through accidents of history, the teams I worked with weren’t the one in San Diego. I was traveling a lot. When I was in San Diego, I was kind of lonely even when I was surrounded by my former team. I did a lot of game pitches but none of them were ever kicked off. I was pitching without a team, too. I was sort of at loose ends a lot, feeling underutilized. It was very stressful. I was grinding my teeth in my sleep so much I shattered a molar in my jaw. I had a heart scare and ended up hospitalized for a weekend and put on blood pressure medication.

Eventually, I ended up working directly on just one game in Austin, which meant flying back and forth a lot. It was tough and bad timing in terms of family stuff—kids dealing with the stress of being teenagers in junior high, you know. When that game was cancelled, there were layoffs.

We tried to find somewhere else in Playdom or Disney that made sense but there wasn’t anything. There were some opportunities on the Disney side, but nothing that felt creatively satisfying. My contract had been over for awhile anyway. So, I just let myself be laid off in a sense. I was exhausted. I didn’t particularly try to keep my job.

Ramsay: Was your departure a good decision on Disney’s part? Was leaving good for you regardless?

Koster: Playdom and I were ships that passed in the night. We ended up not a great match for each other, I guess. We never found a way for me to work there and both feel like it was a success. I am sure they were disappointed with me in some ways. In that sense, my departure was a mutually beneficial situation. There’s no sense in prolonging a relationship if the two parties aren’t happy with one another.

For me, it turned out to be a very good thing. All in all, I see the Metaplace-to-Playdom journey as one long, stressful series of events—a real rollercoaster. It was most fun near the beginning when we were chasing impossible dreams, when we had a small team, and when we were being creative and pushing at what was possible. That’s when I was having the most fun and also when I was most productive.

Looking back at my career as a whole, the best times in terms of personal satisfaction and productivity were those times. It was the skunkworks team when UO was born, having to invent everything. It was the small team at the start of SWG, developing the cool fractal terrain technology. It was the brief period with my R&D group at SOE, where we developed some really groundbreaking stuff. I just had a patent for one of those things come through. It was the first couple of years of Metaplace, when we once again reinvented everything. Small teams, common vision, and crazy big obstacles—there’s where I feel I was at my best.

In that sense, leaving was good for me in a lot of ways. I have taken time to try to get healthier. It took a couple of months of not doing anything at all before I felt relaxed. I haven’t been tackling crazy big obstacles, just small games and more like what I used to make for fun on weekends. That’s what I’ve been doing but it feels good. I am sure I will gather up a small team and find a new windmill to tilt at sometime soon but right now feels like a time to recharge.

Ramsay: What happened after you left? Do you know?

Koster: The old Metaplace office is still there. The game team has made successful games for Facebook and mobile, and the technology is still in use. So, it is fulfilling its promise.

Ramsay: Where Metaplace ended up was not exactly your vision at the beginning. Would you say that you failed?

Koster: True. It definitely has not yet done what it was designed to do. There’s still time though! I can count Metaplace a failure in that sense though. I can also count Metaplace a success from the point of view that we came close to building what we set out to and that it touched people. Of course, financially, it worked out well, and in that business sense, Metaplace was not a failure, although it sure came damn close.

Ramsay: How might you have turned things around? Was your impossible dream even possible?

Koster: The dream was possible. We’ve already seen elements of that dream come true: kids running Minecraft servers in their houses and an explosion of indie development. Of course, the technology did actually do most of what we were trying to do and the rest was within reach.

I think that we built the wrong product though. We tried to get into too many markets and didn’t focus down the way we should have. Furthermore, we didn’t provide enough of a core for the market easiest for us to reach. I bet that had we simply made a fun MMORPG and then allowed players to extend the world, we would have had quite a lot more people interested.

Ramsay: What are you doing now?

Koster: I’m developing new concepts, working out of my house. I’ve got a tabletop card game going, a few puzzle games, and an art game. I’m having fun getting to be creative and do small projects. Now is an interesting time in games where experiments are actually being welcomed by the audience. I am sure that sometime soon I will end up getting pulled back into online development in some way. But I don’t want to give up the sense of creative contentment that I have now. It will have to be the right project.