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

[Jamie F. <ja...@qu...>]

There's nothing to stop the entity behaviour being controlled from
scripting, but obviously some things need to be done in C++ for performance
reasons, etc. The scripting also integrates seamlessly, so there's no
problem. Any change in parameters would not result in a DLL rebuild. But new
complex behaviours likely would, and i don't see a problem with that.

Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
mi...@ub...
Sent: 25 March 2003 11:34
To: gam...@li...
Subject: Re: RE: [GD-General] DLLs for game objects


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


-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557