Saturday, October 25, 2014

The Real reason Trilobyte Inc. shut down.

It has been several years since Trilobyte Inc., the makers of "The 7th Guest", shut their doors.
There have been several articles written about it, few of which I have been asked to contribute to. Those that I have been asked to contribute to seem to cherry pick what they want, and so I have been left with this overwhelming feeling that there is an untold story here. I, however, have never mentioned this piece of history to any writer before.

This story has a name. It's name is "Point Eight".

Before I start, let me be more specific. The downfall of Trilobyte was caused by many factors normal to the game industry, and these factors are well and, for the most part, accurately documented in other articles. Point Eight is the reason Trilobyte couldn't pick itself up by the boot straps once Graeme decided to change the direction of the company from FMV to Real Time.

For those of you that have worked at game start ups, you will recognize that fresh excitement that comes with the start of a new project, and the challenge of entering a realm in which you where unfamiliar. Trilobyte had that in spades when we started making an FMV title, "The 7th Guest" in '91, and a good portion of that excitement returned when we moved to a smaller building and started two real time titles, X-War and Baja 2000, in '97.

At first, there was the usual joking around and challenges to do something better. As when Dave Luehmann told me that my animated Sway Warrior ( a running animation of the enemy in X-War) looked like it had a board up it's ass. So I rendered a pine 2x4 to show Dave proof that I took it out.

It wasn't long though, before a monster reared it's ugly head.

First, let us remember the fact that at this time there were no graphics tools, I repeat, No Tools, for creating real-time content (Id hadn't even released their texture map tool yet).  We were using 3DStudio and the "Throw It Over The Wall" method of data transfer. That is to say, we had no data transfer protocol, or asset check-in tools, or anything.

So a few months into production, when we started having trouble scaling imported objects correctly, it seems like just another one of the usual problems one would encounter, and it would be solved soon.

This problem wasn't gonna go away.

There was reasonable suspicion that it was just our lack of data transfer protocol that was the problem.
But we artists kept getting pressure from dev that it was our data and the way we were working that was generating incorrect results at their end. After all, there are so many things an artist Could do wrong in this undocumented space, and the first place you need to look is Operator Error.

After hammering at this problem for a seemingly endless amount of time, we artists started arguing back that either 1) we were doing it right, or 2) there was some other unknown factor, and that it probably required some code to fix.

It got to the point where we decided not to fix it. Not because we (art or dev) thought we couldn't, but because nobody was gonna accept responsibility for fixing it.
We didn't fix it (in the art department) by scaling all objects to 1.25%.
What did that do? Well, it fixed least from our point of view.

We fixed it by not fixing it.
Yes, for those of you that are paying attention ……. we solved it by not solving it.
Dont ya just love gaming! Where else can you have this kinda fun.

You see, I, in my sphere of influence as Art Director, had settled on 1.25 as My solution to the Scale problem. That was after I smashed my keyboard across my desk and punched a hole in the stairwell wall. (I still have that desk)

The fact that the problem was solved (or herded) by consistently incorrectly scaling objects should have told somebody something, because after all, it was a message delivered in a form dev should have been able to understand......Math. But at this point we were in survival mode, and having this as a solution allowed use to attempt to get something done that we could demo.

When I say survival mode, I mean not even getting paid. By this point, Trilobyte was out of money.
We were all layed-off, in two rounds of layoffs, and on unemployment. Graeme had a meeting with the last round of employees to be layed-off and he told us that he wanted us to work for him while receiving Unemployment so we could save the company (and Graeme's ass). Some of us did. After all, what else were we gonna do, there wasn't any other work in a small town like Medford for folks with our skill set. Several had moved away because of that reason, so we were a skeleton crew at best.

You know the rest of this part of the story. We never got funded or bought, and we shut down.

The good news it that the Monster was found, just too late to do any good.

For those of you who are math oriented, you might notice that 1.25 is the reciprocal of .8

Yes, the monster is .8. To be more specific, the monster was a single line of code that scaled all incoming objects to .8, and most importantly, this wasn't the only line of code that scaled objects.

Graeme had found this Monster while scanning the lines of code looking for such monsters.
When Graeme told me this, he also said that he wasn't sure when, by whom or why this was there. It could easily have been intended as a temporary fix by a team member for a model that was incorrectly scaled.
(This is a model that is incorrectly scaled, not a model that is intentionally incorrectly scaled,….I know this is hard but stay focused)

Don't you just love the irony of this moment. Without any asset management tools to track art and code assets, there is no way to know which came first. Its Chicken or Egg time. You pick.

I know that I chose 1.25 because that got my models in the game at the correct size, so based on that, I assume that the .8 came first. But we will never know for sure. There is even a modicum of suspicion on my part that it was sabotage. That is not based on any specific act, but based on my past experiences at other companies with industrial espionage and my entire life in games as always left me with the strong feeling that gaming, as an industry,  didn't take it seriously.

Now this scaling problem is not the only reason that Trilobyte shut down. And you may wonder why I claim it to be a big enough issue to shut down a company.

It's hard to describe how this effected everything. The loss of moral, the wasted time that could have been spent more wisely. I fully believe that if this was not a problem, we would have been better focused and would have produced demos that could have gotten us funding. We had done it before on more than one occasion and I believe we could have done it again.

The humiliating part came later, when, after having worked for no pay to help save a company that somebody else owned and had more vested interested in than I did, I found that Trilobyte (that means  Graeme) had taken the liberty of spending my 401K company match. When I asked if he had been  greedy enough to rape the other employees 401K's, his reply was that nobody else had one. You can guess as well as I can what that means.

For those of you familiar with 401K law, there are times when a company can legally take back its Company Match to your 401K, but when you are Layed-off, that is not one of them.

On the last day Graeme stood in front of all that remained, cried, and said he would pay everybody back for the time they have put in (6 months). Needless to say, nobody has seen a penny, but I'm sure we are all happy for Graeme, as he just bought himself a Tesla S.