Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- 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.
Add Comment
Please, Sign In to add comment