Re: [GD-General] DLLs for game objects
Brought to you by:
vexxed72
From: Ray <ra...@gu...> - 2003-03-25 06:51:08
|
I have thought about this for our game, and we already have factory functions for our classes so it would be trivial to move them into dlls. I've already done that for testing once, but as you said, the practicality outweighs the theoretically. But, I wouldn't have a different dll for each object type, instead a different dll for a set of objects or classstypes. Keeping the ability to move objects into their own dlls is good for general software engineering anyways and there's no reason not to design it that way, I think. Recompiling the game kernel if there's an object change shows poor relationship between the engine and the objects. Our game recompiles on my machine in under 5 minutes so there's no need to split the objects out anyways, and when an object behavior changes, there's only like 1-2 files that need recompiling too. All-in-all, it's good to have your engine and objects separate from a design standpoint, but there's not much of a reason to make them a separate dll unless you really want modularity for future mods. I'm tired, so I hope that's coherent enough for you. - Ray Brian Hook wrote: > 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 |