Todd and Peter sat in the middle of the room, parked on some couches they had bought from the bankruptcy next door, and marveled at the havoc they had caused. In the span of one short week, they had managed to kneecap three research projects at Apple, steal a vital cog from 3DO, and hijack two programmers from Taligent. Mind you, all the aforementioned companies deserved it. Some were in fact the biggest disasters in the valley. This always made stealing people away that much easier. There was a certain Darwinian satisfaction to contributing to the general demise of these organizations. So they looked around the room and admired their handiwork.
Martin had decided to come with them. He had then turned around and led them to three other dissatisfied rock stars at Apple. Kevin Lonergan was an expert at building rendering engines, software designed to display graphics on your computer's screen. That actually wasn't the problem. The real problem was building a rendering engine that could display graphics at frame rates that resembled TV or movies, and not some demented piece of animation. Movies ran at 30 frames a second. That meant that for each second of movies, thirty individual frames would flash by. TV ran at 24 frames a second, and most computer games at ten to fifteen frames a second. This last number was not going to get it done. Snowcrash was not going to be believable at ten frames a second.
Robert Graylor was next. He was a true nuts and bolts engineer, but in charge of potentially the biggest trauma child of all: the modem connection. If Kevin succeeded in building a fast enough rendering engine, then someone was going to have to deliver enough information quickly enough to fill up those twenty frames of graphics per second. More interestingly, they were going to have to do it over a modem connection, which sent a ridiculously small amount of information per second. This again was not going to get it done.
James Chu and Paul Cromer were going to be in charge of the server, the back office of Snowcrash. As part of the Snowcrash vision, thousands of people were going to be connected together in "virtual worlds." They were going to be able to "see" each other in this world. Which meant all thousand people had to know about all the other thousand people. This presented a bit of a programming pickle on the server, which was the computer responsible for keeping track of who was were and who needed what information. The Phantom structure of Peter and Todd was going to be the secret sauce to overcome this hurdle, but James and Paul were still going to be pumping scads of information in and out of their servers out over the phone lines. And this obviously made them the natural enemies of Robert.
Darrin Conway and Martin were going to be responsible for the other end of the phone line from James and Paul, known as the client. This was the piece of software on the customer's machine which took the information from James and Paul's server which had been sent to Robert's modem and then digest it and send it out to Kevin's rendering engine, which hopefully would make pretty pictures appear on the user's machine. Running at least twenty frames a second. Over a modem. On a standard computer.
In other words, this was a nightmare.
The only people who didn't care about the nightmare were Pierce Barlow, Stacey McCormick and Charles Taylor. These were the people responsible for making the pretty pictures in the first place. The computer graphics, in other words. The resident artists. They had been rescued from a games company that was just about to implode. They had parachuted out of their burning plane and landed happily in the warm embrace of a new employer. The valley had a tendency to work that way. In fact, some people claimed that only a thousand people actually worked in the valley, and they just switched positions every year in a crazed version of musical chairs. No one had yet been able to actually prove this theory wrong.
This was the team that Peter and Todd had assembled in front of them. The last two pieces of course were the two of them. They were going to be responsible for the "datagrams," the actual packets of information that were going to be blasting back and forth between the server and the client. This was the glue that was going to hold everything together or rip everything into shreds. There was no middle ground. That was the problem with new technology: it either succeeded brilliantly or failed miserably. One of the oldest expressions was "The floor of Silicon Valley is littered with the remains of great ideas." If Todd's Phantom architecture didn't work, they were going to get swept out like yesterday's trash.
Todd and Peter had potentially the right team in front of them. Every one of them had hit the engineering equivalent of home runs. They had been pried out of their Fortune 500 towers and start-up hovels with the promise of instant riches and the chance to call their own shots. And they had to be molded into a cohesive engineering team in almost no time. This was not as easy as it sounds. By definition, engineers are a very smart bunch. They also are acrimonious, stubborn, moody, and famously temperamental. Engineers have the God-given ability to wander off at the slightest provocation and disappear into corners. A Chief Technology Officer of a large company once equated his job to "herding cats."
The latest litter now belonged to Todd and Peter. They had probably a month to cobble something together to show their investors. This was important because seed money lasted a heartbeat. Two million dollars may sound like a lot of money, but not when you're in the Valley, paying Valley real estate prices, and stealing expensive engineers from big companies. This meant that almost as soon as the company receives this seed money, it then turns around and starts trying to raise the next round. The real round.
As always though, there is a catch. Theoretically, each round gets raised at a higher valuation, or company value. Vincent and his gang had put two million into the company, and had taken twenty-five percent of the company. This was actually a good deal for Todd and Peter. Their new-born company was now valued at eight million dollars, and for this they had given up "only" a quarter of the shop. This was not a bad haircut by VC standards. This meant that Peter, Todd, the current employees, and options for future employees had the other seventy-five percent. So far so good. However, if Peter and Todd did the same deal again, then there would be remaining only half the company. Another round and only a quarter. Suddenly their take of the potential IPO was mediocre at best. This incremental decrease of ownership is known as dilution. No entrepreneur likes to be diluted because it reduces the number of Ferraris in their imaginary garage. The way out of this vicious circle is to increase the value of your company with each round. That way, if the company is worth, say, eighteen million dollars, another two million would bring it to twenty million, and the investor's two million would only be ten percent of the company instead of twenty-five. Much better for Todd and Peter and their Ferraris. Of course, for this rise in valuation, the company actually had to accomplish something between the two rounds.
Todd and Peter needed a demo fast. Eye candy. Sizzle to sell the steak. The basic engineering concepts they were trying to put together were solid enough, but in order to raise the next round, they needed to become so flashy that the idea of a company's value increasing three times in a matter of months would not seem ludicrous. This meant that some corners were going to have to be cut. Of course, they couldn't build the entire system in the short time frame in front of them. However, they could do a pretty good mock-up. That tied to a more in-depth and believable presentation would start them down the road to riches.
Peter looked at the group in front of him. If any group could pull it off, this was the pack to do it. He looked at the list of targets and milestones on the piece of paper in front of him. He cleared his throat. "OK, so we have a lot of work ahead of us. Todd and I are going to put together a presentation that will have stills to illustrate most of the concepts. But I think it is very important to come up with at least a small engineering testbed to show people. Even just showing a blob on one PC that another PC is controlling would be enough. I mean, the engineering is what we are going to be pressed on first. Data transfer is going to be a real issue for us down the road, but for this, I think we can get away with using a networked connection on the PCs here in the office instead of using modems. No one is really going to care about how the machines are connected at this point in the development."
A hand went up from the middle of the room. It was Kevin the Rendering God. "Are we going to have time to use our own rendering software, or are we going to go with an off-the-shelf one?"
Peter had to stop and think about this one. Of the multitude of big pieces they were biting off, the rendering engine was one of the most problematic. Peter felt comfortable with networks, and with datagrams, but this kind of software was new to him. Todd and he had gone back and forth the day before on whether Kevin should be optimizing someone else's piece of software, or building his own from scratch. They had gone for the latter for two reasons. One, there was no question that building a custom engine for their purpose would be ultimately faster than just using some generic engine. The second reason was Kevin had been building his own engine at his previous company, and he had brought a large chunk of the code with him. Although this wasn't entirely kosher, since the company had ultimately gone out of business, no one would ever be the wiser. Thus Peter and Todd were betting that Kevin could finish the engine quickly and with minimum revisions. One month, however, was completely out of the question.
"I think for this initial demo we’re going to have to go with someone else, Kevin," said Peter. "Who are the candidates?"
Kevin rolled his eyes dramatically. Like all software engineers, there was no doubt in his mind that he wrote the cleanest, fastest, and most efficient code in the universe. Going with some other piece of coding was slumming of the lowest order for him. "Well, there are three options we can go with, but they all suck, frankly. One is faster with polys, one is faster with sprites, but both are dramatically slower than the third. Unfortunately the SDK for the third is practically impossible to work with. It's not much of a pool. Do we know if we are sprites or polys yet?"
Another question, another problem. Engineering efforts tended to work this way. An inexorable descent into chaos, followed by a slow deliberate climb back into the light. But first the chaos. The poly vs. sprite question was one that Peter and Todd had hoped would be delayed until later, but here it was, raising its head in the first meeting. Rendering engines, software that created images on a screen, went about their business in one of two ways: polygons or sprites. Sprite-based engines created the image out of two-dimensional pixels, or points, like television. The most famous pixel-based engine was the one embedded in everyone's favorite bloodfest game, Doom. Pixel-based engines ran very quickly, due to the fact that they operated in two dimensions instead of three. But the lack of the third dimension meant that these engines weren't always the best for creating immersive 3D environments. So there were the polygon-based engines. These created their images out of 3D "blocks" like squares and triangles. Although the environments were thus more complex and believable, the mathematical gyrations needed to put together these blocks slowed down poly-based engines significantly.
Todd and Peter had no idea which way they were going. It was obvious to all that some serious optimization was going to have to happen to get the frame rates where they wanted them, but they couldn't start optimizing until they knew what kind of engine they were going to use. Decision time was upon them. Todd furrowed his brow and moaned quietly, trying to quickly do a pro and con analysis in his head. Peter was one step faster. It was time for unilateral decision-making. "We're going to go poly on this one. I don't think that sprites can accurately model a 3D world with the detail we are imagining."
Todd's eyebrows shot up on this. He didn't know they had come that far in their decision-making, and he wasn't even entirely sure the choice was the right one. However, it was not the time to start questioning Peter's decisions. After all, as always, Peter has taken the President and Chairman Role for himself. Todd was once again a loyal soldier to the throne.
Kevin, on the other hand, could barely contain his excitement. Sprites were yesterday's news. All the serious work in rendering engines was being done with polygons. Which meant that he was now on the cutting edge. Of course, he had never actually done serious optimization for this kind of software, but that didn't dissuade him in the slightest. Engineers as good as him always rose to the challenge. "Great," he said confidently. "That's the way I wanted to go anyway. I think I've got some really cool code that will make this the fastest engine out there."
Peter just nodded. One fire out, and many more right around the corner. He and Todd went through a dozen other questions, glitches and debates before they finally got to the end of the meeting. The basic architecture of the demo had started to come into focus, and everyone was given enough work to keep them awake for the next three days. They were officially in startup mode.