Guest User


a guest
Sep 1st, 2019
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. George:
  3. I just got off the phone with Nick, who told me he had passed my previous
  4. message about Ken to you. I hope that you understand that I was really just
  5. venting at Nick, and I didn't intend that my message be passed on to you,
  6. Ken, or his father. There is still, however, a very significant problem we
  7. (Q Studios) have in dealing with Ken.
  9. Every update Ken makes to his engine turns out to be a major tribulation for
  10. us. He regularly makes changes that break our code without any advance
  11. warning. He consistently ignores our requests for fixes or suggestions for
  12. design strategy. Nick is constantly on me to «Call him. Just get on the
  13. phone and talk to him,» but to be honest, talking to Ken on the phone is
  14. pretty much near the bottom of the list of things I'd like to do with my
  15. life.
  17. The problem is, he's just so completely unresponsive. I'll ask him a
  18. question, and nine out of ten times I'll either get silence or «I don't know»
  19. as a response. I know he's highly intelligent, but so are a lot of people I
  20. know, and I can TALK to THEM. Okay, so perhaps his personality is a bit
  21. different, but he still needs to work WITH us, not AGAINST us.
  23. We've had a resource and memory manager in Blood since last year, and it's
  24. been working well and is very solid code at this point in time. To get it
  25. working back in December though, I had to completely replace parts of the
  26. engine, no thanks to Ken. A well designed system would have been built on
  27. the ground up from a good memory manager, or at the very least with hooks
  28. laid in so it could be developed later. To get our virtual memory system to
  29. work with Ken's engine, I had to spend weeks reverse engineering Ken's code,
  30. documenting variables, prototyping functions — all things that Ken himself
  31. should have done or provided.
  33. Now in June, he hacks in his «group file» system, and says we have to use it.
  34. In one sense he's right — he's hard coded the thing into his engine, and it's
  35. broken Blood unless I can figure out which parts of the engine I need to
  36. replace. By the time we're done with Blood, we probably won't have any of
  37. Ken's engine left… Perhaps you'll want to reconsider the royalties that
  38. you are paying him.
  40. A few months ago, Ken made a change to the engine that allowed each tile to
  41. have its own origin — a reference point by which it could be positioned.
  42. This change was a good one, but there were some problems with the
  43. implementation. When the bit was turned on to enable sprites to be centered
  44. on their origin, animations bounced, and sprites appeared at the wrong
  45. position.
  47. It turns out the solution was one of procedure — by setting the origin at
  48. the base for sprites that are supposed to be on the floor, everything appears
  49. correctly. Unfortunately, setting the origin for several thousand tiles
  50. using Ken's EDITART tool was just a bit too cumbersome for us, so I spent a
  51. few days developing a tool that would allow simple tweaking of the tile
  52. origins, among other things. This tool is integrated with our new sequence
  53. editor, which will be used to create and edit all the actor animations
  54. (walking, attack, death, etc.)
  56. Everything with this system was going fine until we discovered that Ken has
  57. some engine flaws in dealing with sprites that use origin based centering.
  58. The clipmove() function doesn't work, and neither does hitscan(). These two
  59. functions are pretty much essential to doing anything with the engine. I
  60. could rewrite them, of course, but that would be a few days to weeks out of
  61. our schedule, depending on how many more bugs and design problems crawl out
  62. of the woodwork.
  64. We had waited a few months before switching to the new origin based
  65. centering, so I was quite surprised to find such fundamental problems with
  66. it. We called up Ken and told him about it, and he said he didn't think
  67. anyone was using it, but he really didn't know. We asked him to fix it.
  69. Tonight I called up Ken because of the group file problems, and because we
  70. still don't have a fix for the clipmove() or hitscan() problems. Ken he
  71. wasn't going to fix it and we should go back to using the old centering mode.
  72. This is totally and completely unacceptable. We've already invested time and
  73. effort (need I say money?) into using something, and we're not about to waste
  74. more regressing.
  76. Ken understands algorithms, and he understands graphics. What he doesn't get
  77. is how to design SYSTEMS. Everything he does to the engine is a piecemeal
  78. enhancement to something that should have been designed right from the
  79. beginning. The memory system is a poignant example of this. It is a hack,
  80. like most of his code, and not very robust. From what I've disassembled of
  81. the group file code (trying to figure out a way to eliminate or replace it),
  82. it too demonstrates plentiful opportunities for crashing the system —
  83. pointers being freed without validation, files being closed without
  84. verifying the handle, etc.
  86. Our resource and memory manager are quite superior to Ken's (no bragging),
  87. so to abandon our body of code would be a step in the wrong direction. When
  88. I mentioned to him that our resource manager used an LRU list to handle
  89. purging of resources, he said that he didn't understand how they worked and
  90. he didn't want to undertake something that complicated. It isn't that
  91. complex; it's just outside the realm of Ken's experience.
  93. I usually end my phone conversations with Ken with something like the
  94. following: «Ken, is there anything I can do, anything I can provide to you,
  95. that would help you make these fixes or changes?» The answer is invariably
  96. «No.» After we hang up, I usually bang my head on the desk for about ten
  97. minutes. I've tried to explain to Nick that this is why I don't like to call
  98. Ken, but I think he already knows.
  100. Tonight I tried to explain to Ken what a library file is. I told him how
  101. linkers work, and how they resolve symbol name when producing an executable.
  102. I tried to impress on him the benefits of «code granularity» — breaking a
  103. system up into as many small discrete modules as possible so that the linker
  104. can efficiently pack only used code into the executable. I informed him
  105. about «dead code», and why there was so much of his in Blood. I don't think
  106. I made any impression at all.
  108. George, I want you to understand one thing. When I ask Ken to make a fix or
  109. enhancement, it is most surely something we absolutely need for Blood. I
  110. wouldn't force myself to make the phone otherwise. However, everything that
  111. I ask for would benefit not only Blood, but EVERY OTHER build project. I've
  112. spent enough time as a Project Manager for commercial programming tools that
  113. I know what makes a good API, and I know what makes a system extensible. The
  114. things I've been asking for are «hooks» so we can implement our own features,
  115. not have him do them for us.
  117. I sometimes wonder, though, if I'm going against the flow. Perhaps Ken added
  118. his cache system in response to other teams request for a memory manager?
  119. Maybe the group file code was asked for by the Duke Nukem team? These fears
  120. usually turn out to be unfounded, since other teams report similar problems
  121. as a result of Ken's «updates.»
  123. I realize that most of the problems I've been describing with Ken are highly
  124. historical in nature, and there's no way to change the past. What can and
  125. must be done though is to make Ken more responsive to our needs. He needs to
  126. work WITH us, not against us. I don't know why he is so combative, but I can
  127. guess — ego. He probably feels about his code the way a lot of programmers
  128. do: it's okay to criticize your own code, but for anyone else to do so is
  129. blasphemy. I used to be that way until I realized that a lot of the
  130. suggestions people were making to me were actually right.
RAW Paste Data