[MUD-Dev] Jeff's Rant: A World Full of Wheel-Makers

Brian Hook bwh at wksoftware.com
Sat May 19 23:30:07 CEST 2001


Jeff's rant comes across as, well, naive and lacking understanding of
the fundamental problems that software engineers and, specifically,
game developers face.  While it's easy to blame programmer ego for
NIH, there are simply too many real-life cases where you really do
have to roll it yourself, and this has very little to do with just
programmer egos.

I don't have time to go into a complete list, but off the top of my
head here are some thoughts:

  - people do, in fact, use a lot of components when it makes sense.
  STL and the C RTL come to mind.  And, of course, all of Java's
  framework pieces (Swing, AWT, JavaMail, JDBC, etc.).

  - specialized problem set.  These do, in fact, exist.  And with any
  game where technology is a gating or differentiating factor, the
  likelihood of finding a third party library that meets your needs
  exactly is very low.

  - robustness: If you wrote the code, you own the code, and if there
  is a problem with the code, then you can fix it.  If it is a third
  party library, there is no guarantee that fixes will be on time or
  even available (e.g. toolkit vendor goes out of business).

  - portability: If you want to be able to port to any arbitrary
  platform, you need to own and control the code.

  - shifting standards: Even component libraries from the same vendor
  change frequently.  Cf. DirectX, probably the single most popular
  API in computer games history.  It is now in the preliminary stage
  of specing DX9.  It is averaging one revision a year, and the
  revisions are not backward compatible except in the most simplistic
  sense.

  - evolving technology: Especially with games, the technology evolves
  so quickly that standardized models just never catch on.  With the
  possible exception of the Miles Audio Library, I can't think of many
  other standards that have survived the ages unscathed.  VBE, DPMI,
  VCPI, EMS/XMS, WinG, etc.  All popular at one time, but all
  eventually replaced by newer and more relevant technology.  And
  fairly soon we're going to be looking at 64-bit implementations of a
  lot of things.

Brian Hook

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list