Most of the autobiographical essays that I have written so far have been about successful projects, or at very least, ones that accomplished something noteworthy before they died. However, in the interest of completeness I want to talk a bit about some of the others — the ones that weren’t so successful.
During the period from 1996 through 2002 I worked at four different startup companies. Each of the four projects that I worked on failed. That alone is not remarkable, as most startups do fail. However, they each failed in a different and interesting way.
Before I begin, I want to make a couple of disclaimers: I have a lot of complex feelings surrounding these memories, and a lot of them are negative. Although I do have critical comments about some of the decisions that were made, none of the people in this story were idiots or ill-intentioned — for the most part, the mistakes they (and I) made were ones that anyone could make, and if there is fault to be found, it is that we were simply not extraordinary enough.
Also, what I will describe is what I remember, but not necessarily truth. Think of it as a post-mortem with a bit of snark.
I would also suggest that if you are looking for stories about the exciting triumphs at the birth of the computer game industry, some of my other essays (listed in the appendix) would perhaps be more to your taste.
1996: Ten-Six / PostLinear Entertainment
I don’t remember exactly how I got hired at PostLinear, I think it may have been through a recruiter that I met via my game industry contacts. This was the period where The Dreamers’ Guild was going through bankruptcy and I was finishing off the last bits of Faery Tale 2: Halls of the Dead.
(Even though The Dreamers’ Guild failed as a company, I don’t consider it a “failure” — we successfully created a number of quality games and had a lot of fun building them.)
PostLinear had been founded by game industry veteran Ron Martinez. At the time, Ron’s biggest claim to fame was his groundbreaking 1988 game, Hidden Agenda, in which the player takes on the role of the leader of a small, impoverished Latin American country.
The company was located in the iconic Mission district of San Francisco, a hotbed of nascent software innovation. Nearby were a number of mechanic shops where you could see occasional Burning Man art installations taking shape. The company itself was located in a kind of two-story “flex space” where several different computer startups shared the same office.
I was hired as a programmer on the massively-multiplayer game Ten-Six. I moved to the SF bay area, doing my usual “living out of a sleeping bag in a friend’s living room” for a few months until I could get myself settled. Eventually I found a flat in Noe Valley, on one of those hills that are so steep that the sidewalks are stairs, with a panoramic view of the bay from my living room window.
PostLinear was simultaneously working on several other games besides Ten-Six, including Flying Saucer and Vigilance. Both of these games were eventually released, but met with limited success in the market.
The name “Ten-Six” was intended to represent ten to the sixth power — 1,000,000. This was the number of players the game was intended to support.
At first, I was excited to be working on the project — this would be the first time that I had actually worked with game industry veterans (as opposed to self-taught independent coders like myself). I was anxious to learn how to do things “the right way”.
However, it quickly became apparent that the project had deep problems.
The first thing I noticed was that the technical lead of the project, Charles, had very odd ideas about how code should be written and how games should be designed.
In fact, as far as I could tell, he had never done a game before.
For one thing, the code that he wrote was very inefficient — not just by a factor of 2 or 3, but sometimes by a factor of 100. Apparently Charles was an “academic” programmer — someone with a shiny new computer science degree who operated on an abstract, theoretical level and didn’t concern themselves too much with practical realities.
For example, when I pointed out that the code was wasting a lot of machine resources by constantly allocating and deallocating memory many times a second, his response was that programmers shouldn’t worry about things like that, any “modern” operating system would take care of it.
I remember at one point sitting down with one of the other programmers on the team and forcing them to step through Charles’ code in the debugger, one machine instruction at a time. “Oh my God!” he exclaimed, seeing how a small fragment of deceptively simple, highly-templated C++ code — code that should have been a single machine instruction — got compiled into hundreds of machine instructions and multiple operating system calls. But hey, at least the code was pretty.
Another example was the fact that Charles had written several core parts of the game server in CAML, an obscure programming language favored by CS researchers. No one else on the development team knew anything about CAML, which means that no one else could work on that part of the code. In any professional software development team, this would be considered a serious red flag.
I also became aware that the team did not have good morale; several of my team mates members were dispirited and sullen.
Part of this was due to the way PostLinear funded its projects. Basically, Ron would pitch ideas to major game publishers like Activision and get them to pay for developing a project. However, he could only afford to hire staff for the duration of the project; once completed, the creative team would be laid off until funding could be secured for the next project.
Or, as one of my team mates told me: “If you ship, you’ll be fired.”
The game also had problems in its design. The biggest, I think, was that the game world and story were essentially sterile. The overall premise was that the players were settlers competing in a “land rush” on a lifeless, airless planet, eager to set up mining colonies and begin extracting resources. However, on an empty world full of untapped resources, there’s not much reason for players to interact or fight, so the design had to include artificial and relatively flimsy motivations for doing so.
Worse, because the 3D environment was mostly randomly generated barren rock, it all started to look the same after a while.
(If you think about it, the fact that the game was named after the desired size of the player population — as opposed to any thematic, dramatic or other salient feature — should have given a clue to its lack of character.)
There were some memorable highlights from that time. The ones that I remember most vividly were the ones in which I played a significant role. (I know that there were a lot of cool inventions by my team members — unfortunately I just don’t remember them.)
One problem we had to deal with was the fact that “running” was too slow.
We wanted the game to be a fast-paced action shooter, with characters zipping around the landscape at high speed. This was especially true given the large size of the play environment — if the characters ran too slowly, it would take many minutes to get from one side of the field to the other.
However, when we sped them up, the characters’ walk animations no longer looked realistic — instead of striding across the terrain like Olympic sprinters, their little legs flickered like hummingbird wings. And if we tried to slow down the animation, the feet locations no longer “tracked” the ground — instead they looked like they were skating. That just wouldn’t do.
However, this was 1998, and “Back To The Future 2” was less than ten years old. Taking inspiration from the movie, I said, “Why don’t we put them on hoverboards?”
We quickly implemented a prototype, and everyone on the team loved it. Particularly, the physical mechanics of standing on a hovering platform, slowly bobbing up and down, with simulated friction and glide, was much more exiting than all that tedious running from place to place. Later one of the graphics guys added animated contrails behind the hoverboards, which made them even cooler looking.
(As someone once said, “invention comes from ideas having sex”.)
Another, similar idea came a few months later. You see, Ten-six wasn’t just a first-person shooter, it also involved some “tower defense” elements. Your player could control a number of “rovers”, which were large, slow, autonomous combat units. You could click on a rover and tell it to proceed to a destination or attack a specified target, and it would do so without further intervention.
My task at the time was to implement the game physics — the collision logic between the player and the various elements of the game. One day, I asked myself, “what happens if a player’s hoverboard lands on top of a moving rover?”
I already knew what would happen if the player landed on a rover that was not moving: the hoverboard would hover just above the rover’s collision box, resting on it like a platform. However, if the rover started to move, the hoverboard would not move along with it — instead the rover would slide out from under the hoverboard, and eventually the board would fall to the ground. It’s as if the hoverboard’s anti-gravity field were perfectly slippery.
As an experiment, I decided to see what would happen if I added a friction coefficient to the rover’s top surface. Now the player would be carried along with the moving rover — you could ride rovers! This introduced a whole new tactical element to the game — it meant, for example, you could shoot in any direction, regardless of which direction the rover was moving.
There was also the time we pulled a prank on one of the game designers. You see, he was an avid Star Trek fan (more so than the rest of us, if you can believe such a thing) and was constantly making references to Picard and other characters from ST:TNG. So while he was on vacation, we replaced his keyboard, mouse, and monitor with “Star Trek” themed accessories — including a mouse pad and a floppy disk holder with a picture of Wesley Crusher on it.
One of the team members on Ten-Six was Joe Pearce, my former business partner and Dreamer’s guild co-founder, who had been hired at PostLinear a few months after I was (partly due to my own machinations).
One of Joe’s self-assigned tasks was to do load testing on the Ten-Six server. He wrote a “monkey client”, that is, a program that would connect to the server and perform random player actions (like the proverbial infinite number of monkeys). The monkey client was written very efficiently, which meant that a single desktop PC could simulate the actions of dozens of connected players. The plan was to commandeer every desktop machine in the office (usually after hours when no one was there) and connect them all to the server to see how much load it could handle before it would crash.
The first time we ran the load test, it crashed at ten players. This was due to a bug in the server code.
We fixed that bug and ran another test the next day. This time it got up to 50 players before it crashed.
A few days layer we got it up to 100 players. A week after that, 250. We were making progress.
However, at this point we were very late in the project schedule — we’d been working on the server for almost a year, and no one had thought to do a load test before this. The client, Sega, was growing impatient.
Sega eventually canceled the contract with PostLinear. They took all of the code we wrote, the game designs, and handed it to an internal Sega team to finish. I don’t know whether they used any of what we made (I suspect they didn’t), or what the final game looked like. I know that the game was eventually published, but hardly anyone I know has ever heard of it.
PostLinear needed to get new clients to survive, but the problem was that the designers seemed to have run out of ideas. Or rather, they had ideas, but they weren’t very good. One designer would pump out short pitch documents for “awesome” game ideas like “awesome space fleet battle”, but the actual game mechanics weren’t that interesting, and no one wanted to invest in them.
As someone who had designed a few games myself, I was tapped to try and brainstorm some new ideas, but I wasn’t very successful. As I’ve written elsewhere, game design is hard — it’s easy to come up with a theme or premise, but coming up with a novel set of interesting play mechanics takes years of effort. It’s not something you can do on demand. This is why most games are just clones of an already-successful formula.
However, by 1999 Ron was focusing most of his attention on a new venture: Transactor Networks.
1999: Transactor Networks
I have a confession to make: when I claimed that I worked for four companies during this period, that is only true depending on your definition of what is a “company”.
You see, PostLinear spawned a separate company, Transactor Networks, which in turn spawned a third company, Brodia. Each was a separate corporation, a separate legal entity, and I worked for each of them in turn. In fact, I worked for three different companies while sitting at the same desk!
(Ah, the heady days of the dot-COM era! I wish I could relive those times — well, except for the suffering from clinical major depression part.)
The fundamental vision behind Transactor was the idea of “digital property”. Gamers would be able to earn or purchase digital goods — like a special sword or armor — which would give the player an advantage within the game. And Transactor would develop proprietary technology (patented!) to track ownership of these items, using advanced crypto and digital signatures, which it would license to other game development companies — for a cut of the transaction profits, of course.
In today’s mobile gaming world we are all familiar with “pay to play” games, where you get a basic game experience for free, but you have to pay real money to get extra equipment and skills needed to advance very far in the game. So the Transactor idea might not seem very special — but back in 1998, this was all brand new.
However, the Transactor vision went much further than this. For one thing, it envisioned digital good that were portable between games. So for example, you could buy a magic sword in, say, EverQuest, and then use that same sword in Meridian 59.
And Transactor also envisioned using its technology for non-game goods as well — such as selling images or movies.
Sounds great, doesn’t it? There’s only one little problem:
It’s a terrible idea.
The first problem is that Transactor was based on a complex pile of cryptographic technology. You see, “crypto” was the new hot thing and everyone was jumping on the bandwagon. (Gee, thanks, WIRED magazine.)
However, you don’t need complex cryptographic algorithms to track digital property — all you need is a big-ass database. Somewhere in that database is a flag that says “+2 Dragon-slaying sword belongs to David@Gamer4Life.com”. You don’t need much more than that — and any database programmer can whip up code to do it.
In fact, fancy crypto algorithms don’t even help you that much.
The second problem is that “pay to play” has pretty much ruined the game industry. Now, this is just an opinion, but it is an opinion that other old-time game developers (also known as ‘curmudgeons’) share. In fact, I wrote a paper about it at the time, titled “The Rich Kid Always Wins”. Nobody listened, of course.
(It’s interesting to note that the most successful modern games that offer digital goods are very careful not to convey any in-game strategic advantage for buying them — so you can have an awesome-looking hat or mount, but you are no stronger or faster than a character has not paid anything. The reason for this is simple: a non-level playing field drives customers away.)
Also, this idea of portable digital goods was a total non-starter: a magic sword in game ‘A’ has completely different properties and mechanics compared to a magic sword in game ‘B’. When a game designer places a reward within a game environment, they carefully calculate the effect on game balance. Giving out too-powerful rewards too early in the game ruins the challenge. Trying to create a reward item that has the proper game balance in multiple games is exponentially more difficult. It also robs the player of an opportunity to earn that reward in multiple games.
Finally, the idea of protecting images and movies — well, that’s just copy protection, which has been around since personal computers began. And we know how well that turned out.
I only worked for Transactor for a few months. The whole “digital property” idea fell by the wayside as Ron and the others realized that there was a much bigger opportunity: that instead of licensing technology to companies like Sega and Activision, they should find customers with real money.
Customers like Wells Fargo and Citibank.
2000: Brodia
Brodia was a complete pivot from Transactor Networks. The two companies only had two things in common: the staff, and the fact that they both had something to do with money.
You see, in the year 2000 banks had a problem: everyone understood that Internet commerce was the Next Big Thing, and the banks wanted to get in on the action. Unfortunately, for a company like Wells Fargo, which spends zillions of dollars on its “brand” advertising, all of that pretty branding goes away when you shop online. When you go to amazon.com, you don’t get to see stagecoaches or pony express riders fading into the sunset. What you see is something like this:
1234 2345 0987 2398That’s it. That’s what your bank looks like in an e-commerce transaction.
What Brodia was offering was a kind of “on-line wallet” — a little pop-up window, attached to your web browser, that would automatically fill in your purchase information (name, street address, credit card number, and so on). Moreover, this popup would be “themed” based on the brand of your credit card.
Banks loved this idea, and were willing to pay big bucks to fund the development of this technology, including a large engineering and marketing staff. And on paper, it looked pretty good — not only did Brodia have access to the patented “Transactor” system (which had nothing to do with web shopping, but hey, what’s a suit gonna know?) plus they had managed to hire e-commerce pioneer Ted Goldstein, formerly leader of the “Java Wallet” project at Sun Microsystems.
Brodia had a few other irons in the fire, all based around online shopping: for example, there was an effort to create a “shopping portal” that would give price comparisons for popular products.
I moved from Transactor to Brodia, and one of my first tasks was to implement a web server infrastructure for the portal and the wallet. At this point I had never worked with the web, but it wasn’t too difficult back in that simpler time. I was able to leverage my experience inventing scripting languages for games into creating a small Java-based templating language for the web. (It was called STEAM — Server Template Engine for Application something…I don’t remember what the ‘M’ stood for.)
A few months later the company moved from the Mission district to the Embarcadero, where I had a spiffy window office on the 22nd floor of a hi-rise. Over the course of a year I watched the Gap building being built next door.
I loved working with Ted, who was a super-smart guy who taught me a lot about being a professional programmer; and also how credit-card processing works. (Ted later went on to become a vice president at Apple a few years later, and then got a PhD in bioinformatics and is now trying to cure cancer at UCSC.)
I continued to work and have lunch with my old friend Joe Pearce (we now shared the apartment in Noe valley), and I roped in Mark Iennaco, another ex-Dreamers Guild alumni. We used to hold massive potluck parties in our flat on the hill, with nerds, goths, pagans, rocket scientists and renfaire types in abundance.
However, the problem with Brodia was that the entire business plan was based on a delusion. It was a classic case of “group-think”.
The first (but not least) of our problems was technical. The wallet app had to support two browsers, Netscape and Internet Explorer. Unfortunately, both of those browsers didn’t like the idea of one web page interfering with another one, or performing nefarious acts like filling out forms. The browsers would pop up big scary warning dialogs informing the user that the app they were trying to install was violating the security model. We spent many months trying to work around this problem, but never came up with a good solution for it.
(There was another competing app — Gator — which did the same thing, and had similar problems.)
However, there was a bigger problem, which is that end users were mostly indifferent to the value we were trying to provide.
You see, for the vast majority of customers, the problem of filling in your credit card information isn’t a problem at all: you simply go to amazon.com, put in your credit card information one time, and then never shop anywhere else. Problem solved! After all, who wants to expose their precious personal financial information to some fly-by-night merchant who will probably sell it to a Nigerian scammer anyway?
I learned a couple of important things during this time:
- Just because all of upper management is excited about an idea doesn’t mean its a good idea.
- In a three-way transaction (in our case, between us, the banks, and the shopper), it doesn’t matter how enthusiastic two of the parties are — the transaction isn’t going to happen unless the third party is also on board.
A few years later, browser manufacturers started incorporating automatic form-filling technology into their products, so the idea would have been short-lived even if it had succeeded.
One interesting anecdote: at one point the company started producing television ads, some of which were real head-scratchers. They also spent 20,000 dollars on a billboard in San Francisco’s Union Square. This particular billboard was going for rock bottom prices, and it was not hard to see why: the billboard was high up and not particularly large or prominent; not a great location. Nevertheless it was deemed worth the expense, a bargain really.
So what did they decide to put on the ad? A black and white photo of an attractive young man in skimpy attire, with the caption “even underwear models can do it”. That and the Brodia logo. No clue as to what the product was, or that it related to online shopping in some way. Just an ambiguously insulting stereotype.
Some time in 2001 I decided to leave Brodia. Part of the reason was that I believed that the company was doomed — the team had been working on the IE version of the wallet for a year and were nowhere near close to shipping.
I also wanted to work on games again. I met a fellow at a science fiction convention named Jason Ray who convinced me to join his small startup, Explorati. I remember Ron Martinez was very disappointed when I told him the news.
2001: Explorati
I had actually known Jason’s wife, Deanna Sue Ray, for many years — we both wrote articles for the same Dungeons & Dragons fanzine, Alarums and Excursions. (In fact I briefly had a crush on her.)
Jason and Deanna were both avid fans of pen and paper role-playing games. In fact, one of the things that Deanna was particularly known for within fandom was her highly improvisational style of game-mastering. Instead of challenging players with predetermined sets of monsters and traps, designed in advance, she invited players to participate in a kind of collaborative theatre. (There were other game masters who did this too, but Deanna was a well known example.)
Jason’s idea was simple: why not take that same concept of improvisational storytelling and implement it on the computer? In other words, to have the computer track what the player is doing and react to it by introducing new characters and plot twists — in other words, “make up a story”.
Of course, to truly replicate the D&D experience it would have to be a multi-player, in fact, massively multi-player game.
This wasn’t a completely novel idea. In fact Brenda Laurel had written an entire book about it a decade earlier. And game designer Chris Crawford had promoted similar ideas in talks at CGDC.
However, I was skeptical at first, because I knew that the process of making up stories is “AI-compete”, meaning that it is so hard that only a general-purpose AI can solve it.
Nevertheless, Jason assured me that their chief engineer, Ed, had a solution to the problem and had detailed design docs explaining how it would work. Moreover, he had recruited a number of game industry stars, such as Cory and Lori Cole, creators of the Quest for Glory series, to join the company.
I decided to take a chance. I left Brodia and joined the company. I also convinced my former colleague, Wolf McNally, to join the company as well.
Explorati had no permanent offices, the dozen or so employees were scattered across California, and so we all worked from home. Every few months we would meet in a central location, such as a lodge in Yosemite or a hotel in Oakland.
For the next year, I would find myself asking the same question over and over: “how is this going to work?”
I have come to realize that there is something hypnotic about this idea of interactive story generation. Everyone you describe it to thinks it’s a great idea. And everyone underestimates how difficult it is.
People would hear about this idea and then want to invest money in it. Heck, Epic Games even gave Explorati a free Unreal developer license (unusual at the time) based on a sales pitch we gave them at a trade show.
Humans are natural story-tellers. Our brains are wired for storytelling, both in our enjoyment of experiencing stories, and our ability to create them. This fools us into thinking that storytelling is easy, which it’s not.
Go to any professional author or screenwriter and ask them to describe how they do what they do. While they might be able to give you some vague generalities or guidelines on plot structure and character, they can’t actually give you an algorithm for what they do — because they don’t know. It’s all instinctive, like a baby picking up a toy (which, it turns out, is also a fairly hard computational problem).
Even the way we talk about writing stories is deceptive: we talk about “putting” a character into a book or a scene, as if the story was some kind of container, a bucket that you could just drop characters into. In reality, characters are woven into a story, and the addition of a new character has wide-ranging ripple effects impacting the other characters, as well as the overall plot.
I started to realize that Exporati had not, in fact, solved the problem of generative storytelling. It took several months for me to gain access to the aforementioned technical specification documents, and once I did, I noticed something: while most of the basic aspects of the game engine were described in meticulous detail, every time the document would start to describe something that was technically challenging, the text would kind of wander off into vague, airy generalities.
When I started to express skepticism about whether this was going to work, Jason, Ed, and several others told me that I was wrong — that the problem was not as hard as I was making it out to be. “We just need a large enough database of story elements” was one of the typical responses.
Let me try to explain what they meant. Let’s say your character enters a castle. The “author” module decides that not enough has happened recently, so it decides to spice things up a bit by introducing some new plot elements. It looks through its database of potential plots, and finds one with, say, a mad scientist and his creation. However, the plot doesn’t specify a specific mad scientist or a specific monster — rather those are ‘slots’ which are filled via another database search, this time on the cast of characters.
However, simply injecting characters into the environment is not a story. The characters have to react, to respond to the player’s action; and they also have to respond in a way that drives the plot forward. They have to have dialogue.
All of these responses have to be created somehow; I don’t know of any way to create them algorithmically, so they have to be scripted by hand, possibly using some kind of “choose your own adventure” decision tree.
The problem with manually scripted plots is that players are really, really good at recognizing patterns (as we saw with No Man’s Sky). They can sense when plot structures are being reused, even if you change the names of the characters and file off the serial numbers. Unless you’re willing to spend a fortune creating content, the game will quickly become repetitive and stale.
Worse, what happens when two different plots collide? You go into the castle and meet the mad scientist, but in the mean time the mummy from the previous encounter has followed you inside. How does the scientist react to that? He can’t, because all of his reactions are pre-scripted.
What if the player reacts in a way that was not predicted by the script author? Same problem.
And what happens when two players get together who are each following the thread of a different plot?
So when Jason and Ed would say, “we need a large database”, my next question would be something like, “OK so what does that database look like? What’s the schema for the data? What columns does it have?” I never got a clear answer to my question.
At one point I challenged Ed to come up with some kind of demo, proving that he had solved the problem. He spent a month coming up with a card game, where the ‘cards’ represented the kinds of story elements he was describing. The idea was that at the next company meeting he would “play” the cards, showing us all how the algorithm worked.
But when it actually came time to perform the demo, I could tell that he wasn’t using an algorithm — he was using his imagination. That is, he was selecting the cards, and deciding the interactions between the cards, using his instinctive human storytelling ability.
Because tensions were starting to run high, I decided to take a different approach to the problem. I had been busy working with the Unreal engine to try and give some sort of graphical demo showing characters interacting in a social environment. However, I took a break for a few days to create a simple demo program in Python. Basically, I said “OK, I’ll take you at your word. I’ll write the simplest possible game engine — a text adventure on a randomly generated map, set in a forest with various animal characters. I’ll create a little database in memory containing stories like the ones you have described. Let’s see how it plays.”
Well, it was pretty boring. But perhaps that was to be expected, since it only had a handful of entries in the database.
I then sent a copy of the text adventure, “animalworld.py” to the rest of the company, and offered the following challenge: “if you truly believe that you have solved the problem, then modify my program to be even slightly less boring than it is. It shouldn’t be hard, given how simple the program is.”
No one took me up on my offer.
Explorati had an additional set of technical problems. Even without the generative story-telling issue, their plans were incredibly ambitious.
There’s an adage among entrepreneurial investors that companies get to be special in one way. Explorati tried to be special in every way.
Often I think of this using the following metaphor: Imagine a toggle switch, like a light switch, which has two modes, labeled “easy” and “hard”. The “hard” setting might be twice as hard, or it might only be ten percent more hard.
When designing a massively-multiplayer game you have a bunch of these toggles, maybe fifty of them in all. Each one represents a design decision: are we going to do the simple, easy thing or are we going to do the ambitious hard thing?
Also, the effect of these switches is multiplicative: If you have 4 switches, each of which makes the project twice as hard, flipping all of them to the “hard” setting makes the game 16 times as hard: 2 x 2 x 2 x 2.
In the case of Explorati, every one of the fifty toggle switches was set to the “hard” position.
For example:
- Are we going to download new content while the game is offline? No, we’re going to download new content in the background while the game is running.
- Are we going to support a 3D graphical interface, or a text-based interface? We’re going to support both: players who are using a text based interface, perhaps on a mobile device, will have the graphical relationships translated into text: “John moved to the left of the cabinet.”
- The game will be extensible via plugins, and new plugins can be added without restarting the game.
I could go on, but I won’t.
While all of this was happening, the art team was attempting to put together a demo using the Unreal engine. Unfortunately things weren’t happy here either; for example, one of the artists refused to use the Unreal authoring tools (saying that they were too hard to learn) and insisted in doing all of her work in Maya and then converting the result to Unreal format, despite the fact that the conversion process had significant technical weaknesses and produced an inferior result.
The art direction was poor; although the team had decided to model a mediterranean island with a resort and a spa, what they produced looked more like Alcatraz.
After about a year it was clear that we weren’t going to succeed, we had run out of money and there was no more investment. I had been living off my savings for several months, and we didn’t even have a demo. I started looking for my next job, which turned out to be at Maxis.
I really wish that Jason and Deanna had not mortgaged their house; I saw Deanna a couple of years later, after they had divorced. She was heartbroken.
In some ways I feel kind of guilty. As the lone nay-sayer in a group of true believers (at least, it felt that way at times), I have to ask myself, “what if I was wrong?” Did my negativity somehow cause the company to fail?
But there is one simple fact that argues against that viewpoint, which is this: it has been nineteen years since that happened, and in that time, no one has managed to accomplish what Explorati was trying to do.
Yes, machine learning has managed to do some impressive things with generating text, but those are parlor tricks, mere manipulation of word patterns; the algorithm doesn’t understand whether it’s a comedy or a tragedy, and can’t prevent the story from eventually “going off the rails” into some weird surrealistic hyperspace. They aren’t stories.
The fact that companies with a hundred times more funding than we had have not managed to accomplish this makes me think that I was right, after all.
The story continues in the next chapter:
