gamedevlists-general

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

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

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

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

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

I think you're making some blanket assumptions here.  

1.) Scripting languages are not necessarily more comprehensible=
 than 
compiled languages.  They CAN be, but not always.  

2.) Scripting languages still need to be processed.  They can=
 either 
be byte compiled -- which is a compilation phase -- or they might=
 
break during interpretation, which is harder to find than a=
 compile 
time error.

3.) the entity DLLs don't have to contain all the relevant=
 aspects of 
the entity.  As mentioned elsewhere, the DLLs can contain the=
 more 
low level functionality and you can data drive the other aspects=
 
using something a lot friendlier than a scripting language (cf.=
 the 
prior discussions on property based systems).

Brian