Re: RE: [GD-General] DLLs for game objects

[<mi...@ub...>]

this still sounds extremely clunky compared to a scripting language that requires zero compilation time and can be comprehended by most level designers - not just c++ programmers...

the idea of recompiling to change entity variables, NPC behaviors, etc sounds like a nightmare for the design team.

we do have certain aspects of the engine split into seperate dll libraries, but the main gameplay behavior is rapidly moving towards almost entirelyi scripting - including things like the terrain engine, curved surface definition and more...

cheers

Mike W
Reality Factory Open Source Project
http://rfactory.uber-geek.ca 

>We're heading toward a DLL for entities at some
>point, mostly so we can talk
>to our editor nicely, but i'm not envisaging doing
>a DLL per entity :) But
>it hasn't happened yet.
>
>Jamie
>
>
>-----Original Message-----
>From:
>gam...@li...
>[mailto:gam...@li...]On
>Behalf Of
>Brian Hook
>Sent: 25 March 2003 05:16
>To: gam...@li...;
>gam...@li...
>Subject: [GD-General] DLLs for game objects
>
>
>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