RE: [GD-General] DLLs for game objects

[Brian H. <ho...@py...>]

>Basically, anything is better than DLLs in my book ... There's=
 a
>reason it's called DLL hell.

Actually, I think the best language for this is easily Obj-C,=
 since 
it was pretty much designed with this in mind.  I would LOVE to=
 use 
Obj-C for something like this.

"DLL hell" is a blanket statement that isn't really valid. =
 Quake2 
used DLLs for game APIs, and without that it wouldn't have been=
 as 
easy to mod (well, there's always QuakeC as a counterpoint, but=
 it 
had its own set of problems).

If you're aware of the problems that DLLs present, then I don't=
 think 
you'll encounter many problems at all.  Just using the Quake 2=
 source 
code as an example:

- well defined import (from engine) and export (from DLL)
- API versioning to prevent problems

In the case of Quake 2, each DLL (ref and game) has exactly ONE 
function that is exported.  It can export anything it wants as=
 long 
as it adheres to the specified API in the import/export=
 structures.

Going to C++ is when you start introducing a lot of the confusion=
 and 
problems that have arisen, since C++ really isn't what I consider=
 a 
proper OOP language.  Types that are not first class objects=
 pretty 
much blows chunks for anything really dynamic (note: that's just=
 my 
opinion, no need to flame).

The reason I bring this up is that looking at each of the various=
 
"monster" files in Quake 2, it's apparent that there was a heavy=
 
Obj-C influence at work.  Each monster file had the required=
 "think" 
functions in it, then local functions accessible only by that 
monster, and "class variables" were statics.  With this in mind,=
 I 
realized that it would be trivial to convert each monster into a=
 
separate DLL.  

The rough gist is that at game startup, you could search all DLLs=
 and 
search for valid "monster files".  If GetProcAddress( "Spawn" ) 
succeeds, it's a valid monster file.  Then you call the Spawn 
function, it fills in a standardized struct, you pass it an=
 exported 
interface from the engine, and you're good to go.

Then you can dynamically load and unload monsters while a server=
 is 
running 24/7, assuming there are no interface changes (note: and=
 if 
there are, you're going to have bring down the server no matter=
 how 
you implement this).

So I thought that would be interesting, but not necessarily good,=
 so 
I decided to post to see what other people have done.  Quake is 
obviously much coarser (game DLL only), but I think it could have=
 
benefited from a slightly finer grain dynamic game mechanism=
 since a 
lot of what's in the game code can easily be shared across a=
 large 
number of mods but right now code has to be duplicated as a=
 result.

I'm not sold on the idea, mind you, so I'm not saying I advocate=
 
this, I'm just throwing it out there as food for discussion.

Brian