[GD-General] DLLs for game objects

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

Relating to a thread on the gamedevlists-windows list, I thought=
 I'd 
just toss this out for discussion.

One of the reasons often touted for using a scripting language is=
 
that you can easily modify the behaviour of game objects without=
 
recompiling your main source base.  This is definitely an=
 advantage.

The way you'd achieve the same effect using compiled code is via=
 
DLLs.  At a coarser level, the Quakes did this with QuakeC (Q1),=
 
server-side DLLs (Quake 2), and server + client side DLLs (Q3),=
 but 
each entity itself was not a separate DLL.

So let's take that to an extreme, where every object is generated=
 by 
a factory method within a specific DLL.  You get the advantage=
 that 
your "game kernel" does not have to be recompiled on the fly to 
change behaviour, along with the advantages of debugger=
 compatibility 
and compiled code.

The downside is primarily complexity, in that you have hundreds=
 or 
maybe even thousands of DLLs for every entity, e.g. sword.dll and=
 
orc.dll or what have you.  Not to mention that you could=
 conceivably 
run into a problem with DLL dependencies (what if=
 vorpal_sword.dll is 
dependent on sword.dll?).

None of these problems are benefits are particularly mind=
 blowing, 
but I haven't seen it done in practice so I was curious what=
 others 
might think of it.

I personally still prefer monolithic, statically linked stuff=
 because 
the practical advantages typically outweigh the theoretical=
 benefits.

Thoughts and comments?

-Hook