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

yes i'll agree that i'm making some assumptions based on the particular scripting language that i happen to be using - simkin.

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

i guess this depends on what kind of debug info you provide with the integration - we have a 'debuginfo' output that we can send to the screen, console or logfile, so even if your script barfs on interpretation, the log files will report as such - the goal i guess is to provide enough debug info so that the designers/scriptors can debug properly - the right tools for the job so to speak.

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

again, i'm biased from my particular experiences with our engine, but we actually combine both scripting languages AND property-based systems (editable properties for entities in the editor) - certain features use only scripting, others only properties, some both.

we actually USED to have two project files for the engine, one dll-based, one static, but the dll-version has basically been dropped - not for any specific technical reason, but all new development moved to the static version, and the dll project and workspace has fallen into 'disrepair' as it were.

getting down to a 'dll for every entity' seems a bit extremely however.  for projects that can do a complete rebuild in less than a few minutes, the argument for 'ease of recompile' doesn't seem to hold up...

anyways

mike w
www.uber-geek.ca
mike