RE: [GD-General] DLLs for game objects

[Tom H. <to...@3d...>]

At 05:40 PM 3/25/2003, you wrote:
>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.

I think that pretty much the same could be said for C#, and I happen to 
like the syntax better ;) Objective-C, Java, and C# are all good dynamic 
languages that have their own individual problems.

(Skipping ahead, I think it could be tricky in all of these languages to 
unload a loaded type to load in an updated version from disk .. but I 
haven't looked that heavily into it).

>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).

C++ is definitely a problem with DLLs ... but even straight C has problems 
when you're passing around dynamically allocated memory between DLL and 
EXE, or multiple DLLs. There are solutions, as have been mentioned ... it's 
just something you always have to worry about, and it's easy for new 
programmers to your team to screw this up in painful, and possibly 
non-obvious to find, ways.

I don't think your Quake example applicable to this discussion given the 
very limited interactions you describe between components that kept these 
kind of issues at bay. I think if you start putting individual monsters 
into their own DLLs, you're going to find your passing structures and 
strings around all the time, and it will be far more easy to make a mistake 
or paint yourself into the "Oh hell, how do I free this thing cleanly" corner.

>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.

This works as long as each monster is entirely self-contained. You run into 
issues when monsters inherit from other monster files, or if you have "sub 
monsters" ... ie ... a dog monster with a bunch of flee monsters attached 
to it.

These things are workable to varying degrees.

>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).

If a monster is 100% self-contained, without dependances on other 
dynamically loaded entities (and nothing depends on it) ... then something 
like this could be possible without too much headache.

>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.

You're trying to replicate the dynamic language features of Obj-C, Java, 
and C# in C. While you can do much of this, it's a heck of a lot of work 
and I doubt you'll be able to get is as clean and fast as what you can do 
with one of the other languages.

>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.

If you're stuck with C only, then I think something like this sounds like 
something to really look into for dealing with dynamic objects, especially 
if your goal is to be able to change things around at run time.

Tom