George:

I just got off the phone with Nick, who told me he had passed my previous
message about Ken to you.  I hope that you understand that I was really just
venting at Nick, and I didn't intend that my message be passed on to you,
Ken, or his father.  There is still, however, a very significant problem we
(Q Studios) have in dealing with Ken.

Every update Ken makes to his engine turns out to be a major tribulation for
us.  He regularly makes changes that break our code without any advance
warning.  He consistently ignores our requests for fixes or suggestions for
design strategy.  Nick is constantly on me to «Call him.  Just get on the
phone and talk to him,» but to be honest, talking to Ken on the phone is
pretty much near the bottom of the list of things I'd like to do with my
life.

The problem is, he's just so completely unresponsive.  I'll ask him a
question, and nine out of ten times I'll either get silence or «I don't know»
as a response.  I know he's highly intelligent, but so are a lot of people I
know, and I can TALK to THEM.  Okay, so perhaps his personality is a bit
different, but he still needs to work WITH us, not AGAINST us.

We've had a resource and memory manager in Blood since last year, and it's
been working well and is very solid code at this point in time.  To get it
working back in December though, I had to completely replace parts of the
engine, no thanks to Ken.  A well designed system would have been built on
the ground up from a good memory manager, or at the very least with hooks
laid in so it could be developed later.  To get our virtual memory system to
work with Ken's engine, I had to spend weeks reverse engineering Ken's code,
documenting variables, prototyping functions — all things that Ken himself
should have done or provided.

Now in June, he hacks in his «group file» system, and says we have to use it.
In one sense he's right — he's hard coded the thing into his engine, and it's
broken Blood unless I can figure out which parts of the engine I need to
replace.  By the time we're done with Blood, we probably won't have any of
Ken's engine left…  Perhaps you'll want to reconsider the royalties that
you are paying him.

A few months ago, Ken made a change to the engine that allowed each tile to
have its own origin — a reference point by which it could be positioned.
This change was a good one, but there were some problems with the
implementation.  When the bit was turned on to enable sprites to be centered
on their origin, animations bounced, and sprites appeared at the wrong
position.

It turns out the solution was one of procedure — by setting the origin at
the base for sprites that are supposed to be on the floor, everything appears
correctly.  Unfortunately, setting the origin for several thousand tiles
using Ken's EDITART tool was just a bit too cumbersome for us, so I spent a
few days developing a tool that would allow simple tweaking of the tile
origins, among other things.  This tool is integrated with our new sequence
editor, which will be used to create and edit all the actor animations
(walking, attack, death, etc.)

Everything with this system was going fine until we discovered that Ken has
some engine flaws in dealing with sprites that use origin based centering.
The clipmove() function doesn't work, and neither does hitscan().  These two
functions are pretty much essential to doing anything with the engine.  I
could rewrite them, of course, but that would be a few days to weeks out of
our schedule, depending on how many more bugs and design problems crawl out
of the woodwork.

We had waited a few months before switching to the new origin based
centering, so I was quite surprised to find such fundamental problems with
it.  We called up Ken and told him about it, and he said he didn't think
anyone was using it, but he really didn't know.  We asked him to fix it.

Tonight I called up Ken because of the group file problems, and because we
still don't have a fix for the clipmove() or hitscan() problems.  Ken he
wasn't going to fix it and we should go back to using the old centering mode.
This is totally and completely unacceptable.  We've already invested time and
effort (need I say money?) into using something, and we're not about to waste
more regressing.

Ken understands algorithms, and he understands graphics.  What he doesn't get
is how to design SYSTEMS.  Everything he does to the engine is a piecemeal
enhancement to something that should have been designed right from the
beginning.  The memory system is a poignant example of this.  It is a hack,
like most of his code, and not very robust.  From what I've disassembled of
the group file code (trying to figure out a way to eliminate or replace it),
it too demonstrates plentiful opportunities for crashing the system —
pointers being freed without validation, files being closed without
verifying the handle, etc.

Our resource and memory manager are quite superior to Ken's (no bragging),
so to abandon our body of code would be a step in the wrong direction.  When
I mentioned to him that our resource manager used an LRU list to handle
purging of resources, he said that he didn't understand how they worked and
he didn't want to undertake something that complicated.  It isn't that
complex; it's just outside the realm of Ken's experience.

I usually end my phone conversations with Ken with something like the
following: «Ken, is there anything I can do, anything I can provide to you,
that would help you make these fixes or changes?»  The answer is invariably
«No.»  After we hang up, I usually bang my head on the desk for about ten
minutes.  I've tried to explain to Nick that this is why I don't like to call
Ken, but I think he already knows.

Tonight I tried to explain to Ken what a library file is.  I told him how
linkers work, and how they resolve symbol name when producing an executable.
I tried to impress on him the benefits of «code granularity» — breaking a
system up into as many small discrete modules as possible so that the linker
can efficiently pack only used code into the executable.  I informed him
about «dead code», and why there was so much of his in Blood.  I don't think
I made any impression at all.

George, I want you to understand one thing.  When I ask Ken to make a fix or
enhancement, it is most surely something we absolutely need for Blood.  I
wouldn't force myself to make the phone otherwise.  However, everything that
I ask for would benefit not only Blood, but EVERY OTHER build project.  I've
spent enough time as a Project Manager for commercial programming tools that
I know what makes a good API, and I know what makes a system extensible.  The
things I've been asking for are «hooks» so we can implement our own features,
not have him do them for us.

I sometimes wonder, though, if I'm going against the flow.  Perhaps Ken added
his cache system in response to other teams request for a memory manager?
Maybe the group file code was asked for by the Duke Nukem team?  These fears
usually turn out to be unfounded, since other teams report similar problems
as a result of Ken's «updates.»

I realize that most of the problems I've been describing with Ken are highly
historical in nature, and there's no way to change the past.  What can and
must be done though is to make Ken more responsive to our needs.  He needs to
work WITH us, not against us.  I don't know why he is so combative, but I can
guess — ego.  He probably feels about his code the way a lot of programmers
do: it's okay to criticize your own code, but for anyone else to do so is
blasphemy.  I used to be that way until I realized that a lot of the
suggestions people were making to me were actually right.