gamedevlists-general — List for discussing general game development issues

RE: [GD-General] Compile times

[Chris C. <cca...@io...>]

> Since we just spent 1/2 a day playing with VC6 PCH setups and testing 
> compile speeds I'll throw ours in. (P4 2.8 / 512mb )

[snip]

Out of curiousity, what's the general size of your codebase?

I downloaded the Quake2 source myself to take a look and do a test
build in .Net (~2 minutes on my 1Ghz laptop), and I noticed that
the codebase is substantally smaller than ours.

Quake2:
 .c - 188 files, 3.9MB
 .h - 78 files, 0.6MB

Our codebase (which includes the editor, and admittedly a ton of code 
that could use some re-engineering/stripping):
 .cpp - 1188 files, 14.6MB
 .h - 1450 files, 5.8MB

I'm currently in the middle of untangling a bunch of our header dependencies
that are really pretty nasty, and there's way way way too much code in 
headers right now.  Our builds are currently in the 20 minute range, which 
I'm trying to improve.  We use some STL, though tend to use our own, 
simpler containers, and don't use a whole lot of templates other than that.

Hearing all these sub-five-minute build times is making my mouth water, but
do we have a codebase that's just WAY bigger than those that are sporting
such fast builds?

-Chris

Re: [GD-General] JavaScript as a scripting language

[<phi...@pl...>]

Hmm, (ponders NDA for a moment), nope, AFAIK, Insomniac didn't use GOAL.

Personally, I think they (ND) were a little loopy to even try it. The PS2
already has a very steep learning curve without trying to make it lean back
on itself. I also have to wonder how things would have been different it
they'd put a similar amount of effort into improving and extending gcc.

Cheers,
Phil



                                                                                                                                  
                    BG <arc...@ma...>                                                                                        
                    Sent by:                                     To:     gam...@li...               
                    gam...@li...urc       cc:                                                              
                    eforge.net                                   Fax to:                                                          
                                                                 Subject:     Re: [GD-General] JavaScript as a scripting language 
                                                                                                                                  
                    12/09/2002 03:18 PM                                                                                           
                    Please respond to gamedevlists-general                                                                        
                                                                                                                                  
                                                                                                                                  




I imagine if Andy Gavin had written the article, it might have had a
slightly different color to it with regards to GOAL.  Kind've hard to
ignore the language when one of your co-founders is major Lisp fanatic,
and it's been used in all your previous games... : P

IIRC Mario 64 also made extensive use of Lisp (Allegro CL).
Considering how buddy-buddy Insomniac is with Naughty Dog, I'd imagine
that Ratchet & Clank might leverage it as well...


On Monday, December 9, 2002, at 01:31  PM,
phi...@pl... wrote:

>
> Yeah, they regretted it though...
>
> http://www.gamasutra.com/features/20020710/white_03.htm
>
------------------------------------------------------------------------
--------------------------
Copyright 2002 archie4oz email -- End User Licensing Agreement -- By
reading the above post you grant archie4oz (email author of said listed
party name) the right to take your money, eat your cat, and urinate on
your house. In addition you give archie4oz (above mentioned) the right
to use your sister in anyway he sees fit. If you do not agree to these
terms then DO NOT READ the above email.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
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: [GD-General] Compile times

[Douglas C. <zi...@ho...>]

>Okay, Quake 2 is open sourced, so I just tested it out.  On my very
>modest 2xP3/933 w/ 512MB RAM using MSVC 6, compiling ref_gl, game, and
>client, it took 37 seconds.
>
>Let me repeat: 37 seconds.

Since we just spent 1/2 a day playing with VC6 PCH setups and testing 
compile speeds I'll throw ours in. (P4 2.8 / 512mb )

Game: C++, no templates, Core/Math/Engine/Game dlls: 1:05 in release.

Editor: WTL (template heavy ATL like implementations of interface classes, 
no STL though).  Exe & 3 plugin DLLs: 1:25

MaxExporter: STL heavy (plus numerous Max headers): 15secs

So full release rebuild was 2:45.  From using C in the previous game, I can 
definitely tell a hit in compile times with C++ even without templates, but 
there is no way I'd trade 20s for C.. :)  I do think our WTL based editor 
compiles faster than the previous MFC one.

As far as some way to make STL/template builds faster, 512mb of ram and PCHs 
are about it -- which is one reason why the game code has none.  We never 
re-allocate memory after things are initially loaded, so I guess STL (at 
least containers) wouldn't have been much use anyway.

-doug



_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

RE: [GD-General] Compile times

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

>     You've traded static compile time error detection for 
> runtime exceptions.  I can't see that making your game more 
> robust or your test loop any quicker.  Tom

That's typically true, but in my experience static type checking is
overrated.  I almost never accidentally put the wrong type of object
into a container.  In addition, you can do type checking checking just
like any other assertion.

Static type checking isn't a magic bullet.  It can help, but there are
so many more real classes of run time errors that type mismatch is
incredibly low on my list.  It's one of those things that I think is
overemphasized in traditional software engineering discussion.  Note
that there's a difference between "static type checking with occasional
by-pass" and "no static type checking at all".  I'm generally against
the latter, and very for the former.

For example, going back to the prior thread on scripting, some scripting
languages have zero static type checking (which is one of my complaints
with them, ironically enough) and they're still very successful.  Same
wiith languages like Objective-C, which has enjoyed strong underground
success for over a decade and is considered one of the best languages
for rapid prototyping and deployment of mission critical apps (one of
the major areas that Obj-C/NextStep managed to acquire a foothold were
places like medical, financial, etc. industries where custom vertical
market apps that could be put together very quickly were important).

That said, I now just have custom coded containers for most things and
it hasn't impacted me negatively to the degree that I expected.  My
generic container classes will probably just go away.

Brian

Re: [GD-General] JavaScript as a scripting language

[BG <arc...@ma...>]

I imagine if Andy Gavin had written the article, it might have had a  
slightly different color to it with regards to GOAL.  Kind've hard to  
ignore the language when one of your co-founders is major Lisp fanatic,  
and it's been used in all your previous games... : P

IIRC Mario 64 also made extensive use of Lisp (Allegro CL).   
Considering how buddy-buddy Insomniac is with Naughty Dog, I'd imagine  
that Ratchet & Clank might leverage it as well...


On Monday, December 9, 2002, at 01:31  PM,  
phi...@pl... wrote:

>
> Yeah, they regretted it though...
>
> http://www.gamasutra.com/features/20020710/white_03.htm
>
------------------------------------------------------------------------ 
--------------------------
Copyright 2002 archie4oz email -- End User Licensing Agreement -- By  
reading the above post you grant archie4oz (email author of said listed  
party name) the right to take your money, eat your cat, and urinate on  
your house. In addition you give archie4oz (above mentioned) the right  
to use your sister in anyway he sees fit. If you do not agree to these  
terms then DO NOT READ the above email.

Re: [GD-General] Compile times

[Tom S. <to...@pi...>]

> For C++, unless you want a base root Object class, there's no
> alternative, since STL is templatized and gives you the static type
> checking that many feel is so vitally important.  But in more dynamic
> languages such as Java (*shudder*) and Objective-C, the core container
> classes operate on base Objects and everything still manages to work
> just fine.

    You've traded static compile time error detection for runtime
exceptions.  I can't see that making your game more robust or your test loop
any quicker.  Tom

----- Original Message -----
From: "Brian Hook" <bri...@py...>
To: <gam...@li...>
Sent: Monday, December 09, 2002 4:38 PM
Subject: RE: [GD-General] Compile times


> > [to build the full Quake 2 source code]
> > > Let me repeat: 37 seconds.
> >
> > Wow, that's really the way it should be. I'm going to have a
> > hard look at our build environment and try to significantly
> > reduce our build time.
>
> The amusing thing, of course, is that the times I've mentioned this,
> it's poo-pooed that the Quake2 and Quake3 stuff wasn't very
> technologically advanced.
>
> > What are the alternatives other than rolling your own?
>
> Rolling your own? =)
>
> For C++, unless you want a base root Object class, there's no
> alternative, since STL is templatized and gives you the static type
> checking that many feel is so vitally important.  But in more dynamic
> languages such as Java (*shudder*) and Objective-C, the core container
> classes operate on base Objects and everything still manages to work
> just fine.
>
> > Along with:
> > - Lots of debugged code already written
> > - Already quite optimized
> > - Type safety
> > - Familiarity of new programmers with that API
> > - Other APIs build on top of it (boost for example)
>
> I can agree that the above are valuable, but in my experience, those are
> close to non-factors when compared to the cost (again) of using STL.
> Now, I tend to work on small teams -- 3 programmers at id, one
> programmer at my current gig.  So I do have a procedural advantage right
> there.
>
> In most cases, if a container class is showing up as a performance hit,
> my guess is that I'm either doing something wrong or, more likely, I
> need to optimize it beyond what is already done in STL.  But I don't
> have anything to substantiate that, so it's neither here nor there.
>
> > The counter argument of "how long does it take to write a
> > linked list" is totally convicing either. How long does it
> > take to write an efficient balanced red-black tree? Can you
> > write them so it is possible to change the way memory is
> > allocated easily? Can you write them so they can be reused
> > for different types and not make extra memory allocations?
>
> Even if I never, ever re-use any of my list or hash code,
> re-implementing from scratch is almost never a problem.  It's not like I
> have containers littered about so much that I need the absolute best,
> most generalized implementation available at all times.  I know that's a
> philosophical shift from what many believe in these days, but I almost
> never, ever have to implement radically specialized data structures.
> Every day, easy-to-write stuff like lists, maps, sets, etc. are
> basically all I ever use.  And when I start getting into more exotic
> data structures -- BSP trees, quad-trees, oct-trees -- then STL isn't
> going to help.
>
> Maybe that's a good summary -- for the things that STL can help with,
> rolling my own consumes almost zero time.  It's probably 15 minutes to
> write a simple binary tree implementation from scratch.  I spent more
> time writing this e-mail =)
>
> For the things that really need an optimized implementation, odds are
> it's a data structure that STL just doesn't understand.  So STL -- for
> me -- falls exactly in that area of being a non-issue.
>
> As a library for the masses, it's great, because it does a little bit of
> everything well, in a documented fashion.  But when it gets down to
> brass tacks for _one project_ I think the value plummets.
>
> But I do recognize I'm singularly alone on this.  I also recognize that
> I have 5 second compile and go times as well. =)
>
> > Just out of curiosity, what are you developing in these days?
> > Light C++, or straight C?
>
> Both, although frankly I wish I had just stick with pure ANSI C, since
> it compiles and runs in a much cleaner fashion.
>
> My core frameworks are 144 header files and 187 source files that cover
> a wide variety of platforms, and while the hierarchy started out clean,
> it has since become a mess because code just has a habit of growing,
> changing and morphing over time.
>
> And C++ hierarchies, to coin a phrase from Scott Bilas, tend to "harden"
> over time.  The more interdependent your class trees get via
> inheritance, delegation, aggregation, etc. the more difficult it becomes
> to refactor your existing code because the chain of dependencies grows
> longer and longer with time.
>
> The code base becomes resistant to change.
>
> All my new libraries are written in ANSI C, because many of them I plan
> to release as open source.  But in the process of writing them in ANSI C
> and acutely examining the dependencies that existed, I found that I was
> writing MUCH cleaner code, and not just because I expected others to
> read the code.
>
> Application frameworks are great for writing applications, but I think
> they're also extremely cumbersome and dangerous when trying to write
> libraries or allowing the reuse of code in a piece-meal fashion, which
> is often extremely handy.  I've been frustrated at times because I'll
> write a simple command line app that I want to give to someone, but it
> uses one tiny little class out of my frameworks, and now suddenly I have
> to hand over megabytes of source code so someone can compile a 10 line
> program.
>
> I believe strongly in using C++ as an application language, but for
> libraries, I think ANSI C is probably superior for many reasons.
> Frameworks make sense for developing entire apps, but by their very
> nature they're incredibly difficult to partition and release in pieces.
>
> Code reuse introduces dependencies, and dependencies work directly
> against refactoring code cleanly.  I'm not against code reuse, but it's
> worth pointing out that the more code is reused, the harder it is to
> change or improve.
>
> Brian
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> 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: [GD-General] Compile times

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

> [to build the full Quake 2 source code]
> > Let me repeat: 37 seconds.
> 
> Wow, that's really the way it should be. I'm going to have a 
> hard look at our build environment and try to significantly 
> reduce our build time.

The amusing thing, of course, is that the times I've mentioned this,
it's poo-pooed that the Quake2 and Quake3 stuff wasn't very
technologically advanced.

> What are the alternatives other than rolling your own?

Rolling your own? =)

For C++, unless you want a base root Object class, there's no
alternative, since STL is templatized and gives you the static type
checking that many feel is so vitally important.  But in more dynamic
languages such as Java (*shudder*) and Objective-C, the core container
classes operate on base Objects and everything still manages to work
just fine.

> Along with:
> - Lots of debugged code already written
> - Already quite optimized
> - Type safety
> - Familiarity of new programmers with that API
> - Other APIs build on top of it (boost for example)

I can agree that the above are valuable, but in my experience, those are
close to non-factors when compared to the cost (again) of using STL.
Now, I tend to work on small teams -- 3 programmers at id, one
programmer at my current gig.  So I do have a procedural advantage right
there.

In most cases, if a container class is showing up as a performance hit,
my guess is that I'm either doing something wrong or, more likely, I
need to optimize it beyond what is already done in STL.  But I don't
have anything to substantiate that, so it's neither here nor there.
 
> The counter argument of "how long does it take to write a 
> linked list" is totally convicing either. How long does it 
> take to write an efficient balanced red-black tree? Can you 
> write them so it is possible to change the way memory is 
> allocated easily? Can you write them so they can be reused 
> for different types and not make extra memory allocations?

Even if I never, ever re-use any of my list or hash code,
re-implementing from scratch is almost never a problem.  It's not like I
have containers littered about so much that I need the absolute best,
most generalized implementation available at all times.  I know that's a
philosophical shift from what many believe in these days, but I almost
never, ever have to implement radically specialized data structures.
Every day, easy-to-write stuff like lists, maps, sets, etc. are
basically all I ever use.  And when I start getting into more exotic
data structures -- BSP trees, quad-trees, oct-trees -- then STL isn't
going to help.

Maybe that's a good summary -- for the things that STL can help with,
rolling my own consumes almost zero time.  It's probably 15 minutes to
write a simple binary tree implementation from scratch.  I spent more
time writing this e-mail =)  

For the things that really need an optimized implementation, odds are
it's a data structure that STL just doesn't understand.  So STL -- for
me -- falls exactly in that area of being a non-issue.

As a library for the masses, it's great, because it does a little bit of
everything well, in a documented fashion.  But when it gets down to
brass tacks for _one project_ I think the value plummets.

But I do recognize I'm singularly alone on this.  I also recognize that
I have 5 second compile and go times as well. =)

> Just out of curiosity, what are you developing in these days? 
> Light C++, or straight C?

Both, although frankly I wish I had just stick with pure ANSI C, since
it compiles and runs in a much cleaner fashion.

My core frameworks are 144 header files and 187 source files that cover
a wide variety of platforms, and while the hierarchy started out clean,
it has since become a mess because code just has a habit of growing,
changing and morphing over time.

And C++ hierarchies, to coin a phrase from Scott Bilas, tend to "harden"
over time.  The more interdependent your class trees get via
inheritance, delegation, aggregation, etc. the more difficult it becomes
to refactor your existing code because the chain of dependencies grows
longer and longer with time.  

The code base becomes resistant to change.

All my new libraries are written in ANSI C, because many of them I plan
to release as open source.  But in the process of writing them in ANSI C
and acutely examining the dependencies that existed, I found that I was
writing MUCH cleaner code, and not just because I expected others to
read the code.

Application frameworks are great for writing applications, but I think
they're also extremely cumbersome and dangerous when trying to write
libraries or allowing the reuse of code in a piece-meal fashion, which
is often extremely handy.  I've been frustrated at times because I'll
write a simple command line app that I want to give to someone, but it
uses one tiny little class out of my frameworks, and now suddenly I have
to hand over megabytes of source code so someone can compile a 10 line
program.

I believe strongly in using C++ as an application language, but for
libraries, I think ANSI C is probably superior for many reasons.
Frameworks make sense for developing entire apps, but by their very
nature they're incredibly difficult to partition and release in pieces.

Code reuse introduces dependencies, and dependencies work directly
against refactoring code cleanly.  I'm not against code reuse, but it's
worth pointing out that the more code is reused, the harder it is to
change or improve.

Brian

RE: [GD-General] Compile times

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

> On macosx, compile for the same code takes about 45 minutes.
> On linux, about 30 for a full rebuild.

That seems...weird.  Granted, these are different machines, but in my
experience VC hasn't been that much faster unless you're heavily
leveraging incremental linking and precompiled headers.  My own code
base seems to take a similar amount of time on OS X (G4/867) and my
P3/933, maybe a tad slower, but not by a factor of 9.

> It's just very convenient to use STL when making something go 
> as soon as possible.
 
If you're seeing 5 minute full rebuild times and incremental changes
only taking a few seconds, then I would agree that STL is a complete win
in that situation, but the cases I hear about are more extreme.

I can't help but wonder if your slow rebuilds on Linux and OS X are the
result of using gcc and STL?  Because that factor of 9 is just mind
bogglingly dramatically different, enough so that it would raise alarm
bells.  gcc has issues, but damn, not THAT many issues.

Brian

Re: [GD-General] Compile times

[Noel L. <ll...@co...>]

On Mon, 09 Dec 2002 13:34:24 -0800
Brian Hook <bri...@py...> wrote:

[to build the full Quake 2 source code]
> Let me repeat: 37 seconds.  

Wow, that's really the way it should be. I'm going to have a hard look
at our build environment and try to significantly reduce our build time.
 
> The trick was careful engineering.  Nothing mind boggling, just doing
> the obvious stuff.  <windows.h> was limited to only the files that
> needed it.  

Supposedly so are we, although some people put <windows.h> in their
precompiled headers sometimes, so maybe that's slowing things down just
because it adds so many new symbols to search through, even if the
precompiled file is not recreated.

> Dependencies between modules were well guarded -- changes to the
> renderer data structures had no effect on the game source code.  Changes
> to the network stuff had no effect on the renderer, etc.

Yeah, same here. Incremental builds are not a problem (other than the
30 second link time), it's full builds that are terrible. Fortunately
nobody has to do full builds (we have an automated build system that
does that), but still. 

For what is worth, we also don't have any scripting language, so there
were a lot of C++ classes doing things that should/could have been done
with scripts.

> I just don't buy this one second.  We survived and thrived just fine
> before STL.  STL is very, very convenient, but is it worth that cost?  I
> don't think so, not one bit.  

What are the alternatives other than rolling your own? Is there a set of
available containers and algorithms that compiles much more quickly and
provides some of the same functionality?
 
> Probably the #1 defense for STL is that it prevents you from doing
> something lame just to get things going.  The classic case is, say,
> hardcoding an array when you should have a proper container class.  Or
> using a linear search when a proper set/bag/map should be used.  

Along with:
- Lots of debugged code already written
- Already quite optimized
- Type safety
- Familiarity of new programmers with that API
- Other APIs build on top of it (boost for example)

The counter argument of "how long does it take to write a linked list"
is totally convicing either. How long does it take to write an efficient
balanced red-black tree? Can you write them so it is possible to change
the way memory is allocated easily? Can you write them so they can be
reused for different types and not make extra memory allocations?

Personally, I find STL a pleasure to work with. But if I find that
without STL compile times go from 15 minutes to 2 minutes, I'm throwing
it out the window without even thinking about it twice. It it's only
going to save a couple of minutes, then it's well worth it.

> I just remain 100% unconvinced that STL (or almost any library or
> language feature) is worth the loss of hours each day in build times.

Just out of curiosity, what are you developing in these days? Light C++,
or straight C?


--Noel
ll...@co...

Re: [GD-General] Compile times

[Ray <ra...@gu...>]

Our game compiles in about 5 minutes in VC++6 for a full rebuild.
A simple fix will just recompile that one file and link, mainly, unless I edit a root header file, which then it recompiles all 
the files that header file gets included in (it's very rare for us to edit a root header file).

On macosx, compile for the same code takes about 45 minutes.
On linux, about 30 for a full rebuild.

I love vc++'s ability to compile fast.

We use STL extensively. Well, we use map, list, vector a lot. I know we can rewrite teh stl stuff to use our own stuff, but our 
owk stuff won't be much faster in runtime and that's just more stuff that would need to be debugged.
I only use vector if I need to sort, because I can never seem to get list.sort() to work.

We use maps a lot for string lookups.

We even use deque, set, queue for some things.

It's just very convenient to use STL when making something go as soon as possible.

Noel Llopis wrote:
> I'm totally impressed. When you say complete build times, that means
> *all* the code involved in Quake 2 or Quake 3? All the DLLs, everything?
> Was there some trick you were using to get such incredible build times 
> (other than using straight C)?
> 
> We're using C++ and STL, and even though we have a good physical
> organization (like Lakos described), compiling all our libraries and
> game code for one platform could take up to 15-20 minutes. That's only
> for a full build; a quick change somewhere still requires building that
> file and then doing a link, which is about 30-40 seconds. 
> 
> I find 30-40 seconds for a trivial change close to unbearable.
> Especially when it takes another 10 seconds for the game to start and
> another 10 seconds for the level to load.

Linking should never take 30-40 seconds. VC++ linking for me is about the time it takes for the harddrive to save the file. 
(debug is about 3 megs, release is 1.6megs)
Linking for the mac is slower, but that's because the file is much larger. (20 megs for a debug version! 2.6 megs for release)

More RAM is the thing that would make linking faster. I remember back a couple years when a coworker was using an SGI O2 machine 
to build our of our products. That machine had like 128 megs and linking took forever! Doubling the ram sped up compiling and 
linking immensly.

> What are other people doing to reduce their compile times? Getting rid
> of STL is not really an option. It's way too useful to replace it with a
> crippled, custom container/algorithm set that is probably not even type
> safe. But any tricks that reduce how many times the same templates get
> evaluated to save time would be welcome.

For windows, I think making sure you have automatic use of precompiled headers on and incremental linking on.
I wish gcc had those.

There's this one file we have that takes literally 5 minutes to compile on the mac, and about 5 seconds on vc++.
It uses stl::list a lot.

- Ray

RE: [GD-General] Compile times

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

> I'm totally impressed. When you say complete build times, that means
> *all* the code involved in Quake 2 or Quake 3? All the DLLs, 
> everything? Was there some trick you were using to get such 
> incredible build times (other than using straight C)?

If I remember correctly, yes.

Okay, Quake 2 is open sourced, so I just tested it out.  On my very
modest 2xP3/933 w/ 512MB RAM using MSVC 6, compiling ref_gl, game, and
client, it took 37 seconds.

Let me repeat: 37 seconds.  

Compiling each component averages 10-15 seconds for a full rebuild.  If
editing a single source file, compile-edit-run is probably 3 seconds.

The trick was careful engineering.  Nothing mind boggling, just doing
the obvious stuff.  <windows.h> was limited to only the files that
needed it.  We used ANSI C, not straight C++.  But even so, if you don't
use templates heavily or STL, straight C++ can compile very quickly as
well.  Dependencies between modules were well guarded -- changes to the
renderer data structures had no effect on the game source code.  Changes
to the network stuff had no effect on the renderer, etc.

There was absolutely nothing magical about it, and that's why I'm
honestly confused and addled by the seeming necessity today to spend 10+
minutes to rebuild games on top notch hardware.  And most new games
today use scripting languages, so the build times should be close to
non-existent (Q2 had no scripting language).

Quake 3 was not significantly more complex, unless the Q3VM stuff that
John did ended up taking a lot of time, but I highly doubt that as well.

> We're using C++ and STL, and even though we have a good 
> physical organization (like Lakos described), compiling all 
> our libraries and game code for one platform could take up to 
> 15-20 minutes. That's only for a full build; a quick change 
> somewhere still requires building that file and then doing a 
> link, which is about 30-40 seconds. 
> 
> I find 30-40 seconds for a trivial change close to 
> unbearable. Especially when it takes another 10 seconds for 
> the game to start and another 10 seconds for the level to load.

The above is exactly what I mean.  STL is the devil's tool, I stand very
firmly on that.  I completely dislike the way C++ has made templates,
which are effectively glorified search and replace macros.  It leads to
code bloat, and changing any of your template code causes massive
cascades of rebuilds.

> What are other people doing to reduce their compile times? 
> Getting rid of STL is not really an option. It's way too 
> useful to replace it with a crippled, custom 
> container/algorithm set that is probably not even type safe. 

I just don't buy this one second.  We survived and thrived just fine
before STL.  STL is very, very convenient, but is it worth that cost?  I
don't think so, not one bit.  

Writing basic data structures like sets, lists, hashes, etc. is stuff we
all did as undergrads in college.  In the massive, grand scheme of
engineering, it's a non-issue.  It's tedious, sure, but even then, that
tedium is measured in minutes or hours, not days and weeks.  The
overhead from using STL or any other features that incur extensive build
times affects you through the life of the project.  Every compile.

This, to me, is one of the biggest indicators that software engineering
has gotten completely out of hand.  And I'm not coming down on you
specifically, because pretty much 90% of all game companies that I'm
aware of are using STL or something similar in such a capacity, and
incurring the costs.  Yet I rarely see any potential benefits measured
concretely by this.

Probably the #1 defense for STL is that it prevents you from doing
something lame just to get things going.  The classic case is, say,
hardcoding an array when you should have a proper container class.  Or
using a linear search when a proper set/bag/map should be used.  But 20
minutes per rebuild (and in many cases, much much more from what I've
heard) to make up for lack of programmer discipline seems ridiculous.

I use linear searches.  And when I know they're going to be a problem, I
substitute something better.  I usually put in a comment like:

//fixme: don't do a linear search here!

But it lets me get something implemented, and then I can substitute it
later on demand.

This isn't a case of NIH, which is the common counterargument when I
rant about STL.  I'm 100% for code reuse, and in fact use a ton of open
source libraries in my own code -- Lua, libpng, ijg, ogg vorbis, SDL,
etc.  But when code reuse has a measureable cost on productivity without
an associated benefit, I have to raise an eyebrow.

I just remain 100% unconvinced that STL (or almost any library or
language feature) is worth the loss of hours each day in build times.

Anyway, enough lecturing on that =)

The only other things you can do is go through with heavily analyze
every single dependency you have and try to minimize them.  A common
enough thing is to revert to pure dynamic allocation so that changing
the physical structure of a class won't force rebuilds by clients of
that class, i.e. the classic:

//publicly export this
class FooInterface
{
   public:
      virtual void interfaceFunc( void ) = 0;
};

//only seen by the Foo module
class FooImplementation : public FooInterface
{
  ...
};

This can hurt though, since I personally abhor excessive dynamic memory
allocation.  I much prefer to have my data structures pre-allocated as
much as possible, even though this does cause a much greater dependency.

-Hook

RE: [GD-General] JavaScript as a scripting language

[<phi...@pl...>]

Yeah, they regretted it though...

http://www.gamasutra.com/features/20020710/white_03.htm




                                                                                                                                  
                    "Jacob Turner (Core Design Ltd)"                                                                              
                    <Ja...@Co...>                     To:     "'gam...@li...'"           
                    Sent by:                                      <gam...@li...>                    
                    gam...@li...urc       cc:                                                              
                    eforge.net                                   Fax to:                                                          
                                                                 Subject:     RE: [GD-General] JavaScript as a scripting language 
                                                                                                                                  
                    12/09/2002 12:51 AM                                                                                           
                    Please respond to gamedevlists-general                                                                        
                                                                                                                                  
                                                                                                                                  




Just to throw it into the mix didn't Naughty Dog use LISP as the basis for
the entire programming language.

i.e. http://www.gamasutra.com/features/20020710/white_02.htm

Jake

-----Original Message-----
From: brian hook [mailto:bri...@py...]
Sent: 06 December 2002 02:24
To: gam...@li...
Subject: [GD-General] JavaScript as a scripting language


Has anyone looked into using JavaScript as a game scripting language?
It looks fairly flexible and intuitive, and it has a lot of aspects I
find appealing, but I find it alarming that it's not mentioned nearly
as much as, say, Python and Lua.

-Hook



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557

(See attached file: InterScan_Disclaimer.txt)

[GD-General] Compile times

[Noel L. <ll...@co...>]

We were talking about turnaround time of script languages vs. compiled
C++, and Brian Hook wrote:

> For what it's worth, when I worked on Quake 2 and Quake 3, complete 
> build times were on the order of a minute IIRC, and compile-edit-run 
> was measured in seconds.  I don't think anything magical was done for 
> that either -- it was straight ANSI C with the subsystems broken apart 
> into DLLs to avoid interdependencies.

I'm totally impressed. When you say complete build times, that means
*all* the code involved in Quake 2 or Quake 3? All the DLLs, everything?
Was there some trick you were using to get such incredible build times 
(other than using straight C)?

We're using C++ and STL, and even though we have a good physical
organization (like Lakos described), compiling all our libraries and
game code for one platform could take up to 15-20 minutes. That's only
for a full build; a quick change somewhere still requires building that
file and then doing a link, which is about 30-40 seconds. 

I find 30-40 seconds for a trivial change close to unbearable.
Especially when it takes another 10 seconds for the game to start and
another 10 seconds for the level to load.

What are other people doing to reduce their compile times? Getting rid
of STL is not really an option. It's way too useful to replace it with a
crippled, custom container/algorithm set that is probably not even type
safe. But any tricks that reduce how many times the same templates get
evaluated to save time would be welcome.


--Noel
ll...@co...

RE: [GD-General] Re: Scripting

[Awen L. <ali...@ed...>]

The real horror is this:
Colin, you're just right about that crap: you know it, i know it, and maybe
the 2 or 3 of us at the studio, probing mailing lists, are now scratching
their heads after reading you ('damn, if he was right...').
But it happens: i were just writing about side-effects of such a decision
along time (no way ! no script ! programmers are the best !): it's only
another illustration of some 'chaos theory'... (busted you, butterfly !).
Living in a perfect world with perfect people is a quite different
discussion, i would like to have... sigh... just 59 other people to convince
:-P

Awen

PS: Colin is right telling that this way of (not) scripting is dumb. So are
bad implementations (the human part of it) of scripting engine...
Hold on Brian, don't despair, maybe try again !?

Re: [GD-General] Re: Scripting

[Colin F. <cp...@ea...>]

2002 December 9th
Monday

>>> You can't just 'modify an actor'; you'll need a meeting with:
>>> - a game designer (*)
>>> - a project lead  (*)
>>> - a lead code (*)
>>> - the programmer
>>> (*) think salary.
>>> Meetings equal meeting reports, equal report availabilities by mail mail
to
>>> the team, WHICH IS LONGER TO WRITE THAN THE REQUIRED BEHAVIOR SCRIPT.

Maybe the horror scenario you are describing is mostly
a problem with how your project is managed, and not so
much about how scripting is better than compiled code
for some aspects of the game.

As far as consulting the game designer when you modify
an actor's actions, how could this be avoided?
If your organization designated a person to design the
game, then any effort to avoid consulting the game
designer when making changes to the game experience
is sabotage.  In fact, unless there is an explicit
agreement within the team that people have freedom
to "enhance" or elaborate on game elements specified
by the game designer, then changes should only come
about by initiative of the game designer.  I think
your team might need to explicitly discuss and decide
the degree to which each individual developer can
make creative decisions about the game without
consulting the game designer.

The project lead is not the game designer.
If the project lead needs to be consulted about
game design decisions, this is a serious problem.
Sure, the game designer may require legal advice
or general content advice from the project lead,
but if the project lead, or publisher, or
marketing, or the president of your game company
is telling an artist or game designer to
change dialog or the plot of the game, then
you damage the fidelity of the game design
and you have the big meetings so that everyone
can do the game designer's job.

Is it draconian to have a game designer
designing the game?  No!  That's his or her job!
If a programmer on the team happens to also have
game design talent, then he or she can propose
changes to the designated game designer.
Presumably, one hires a game designer based on
a record or promise of good final game designs,
and even if the game designer refuses to listen
to outside input (which I doubt would ever happen),
this is irrelevant;  the past performance of a
game designer validates his or her methods.
If a programmer feels like his or her game
design ideas are falling on deaf ears too often,
then maybe the programmer should consider seeking
a game design position.  If one feels very
passionate about design aspects of the game,
and the game designer refuses to listen or change
the design, then either the designer really does
know better about what will make the best final product,
or the company made a mistake when it hired the
game designer.  Requiring the game designer to
give team members some freedom to improvise is
not the solution.

I really don't see why the lead programmer is
involved at all in the scenario you describe.
The lead programmer breaks up the coding
requirements in to small coding tasks,
schedules the tasks in a timeline, and assigns
tasks to programmers according to their
skills and expertise.  The lead programmer
should explicitly define programming standards
for the team -- and make announcements about
general programming issues as the project
evolves (like "patch your compiler to 4.0",
or "avoid using the function foobar()").
So, the lead programmer gives the task
"implement cut-scene scripting" to a programmer,
perhaps referring to specific items in the
game design document.  There should be no
need to consult the lead programmer for
any aspect of this programming task.
If consultations are necessary, then either
the lead programmer failed to define general
programming standards at the outset of the
project, or the junior programmer doesn't
have sufficient qualifications.

Arguments about scripting allowing cheaper labor
to perform tasks are not convincing.  The task
will be completed in a shorter time, and with
fewer errors, when it is performed by a person
with greater skill at the task.  When you give
a task to a junior programmer or to an artist with
no programming skill, the only possible benefit
is that you might free up a person who has unique
skills or expertise necessary to complete other
tasks.  If you have too much C++ "script" programming
for your programming team, hire a new programmer
to do C++ "script" programming -- and there's
no reason why this programmer shouldn't have
tons of experience and demand a high salary.
The idea of somehow turning programming in to
a kind of non-programming is pure illusion!
Scripting is programming!  If you dumb it down,
you're just dumbing it down and limiting
the potential, which is fine, but should be
recognized for what it is.

To summarize, I think your woes are caused by a
lack of clear division of responsibilities in your
company, and a lack of policies to make communication
efficient.  Team members need roles and authority,
and meetings should be easy to initiate, only involve
relevant people, and should stay focused and end
when the matter has been decided.  With defined
authority, a person will automatically know when
there is a matter that requires a meeting -- or
a quick e-mail, phone call, or shouting across
the room!

I'm not bashing scripting (no pun intended), but
if a "dumb worker drone" working with blissful,
cheap efficiency on a script runs in to a problem,
like needing a feature that cannot be expressed
in the scripting language, then this will lead
to MORE trouble than the programmer working in
native C++ who runs in to the same problem.

I'll end this by agreeing with you at some level:
scripting has its benefits.  If you have a subsystem
in a game that is fun to modify, and has relatively
simple operations with simple execution control,
then scripting is cool.  I like the idea of scripting
menu stuff, character ("actor") actions, and some
high-level actions taken by game objects.  I think
frequent need for simple modifications, or your
desire to open up the game to end-users, are strong
justifications for supporting some kind of scripting
(e.g., Javascript, small C) or parsing (e.g., XML).

Hee, hee!  I was going to say that I was an opinionated
jerk for writing all of this nonsense, but then I worried
that somehow this would be a form of passive-aggression
or projection -- like saying that everyone out there
with an opinion was a jerk...Or was it that the
Apollo moon landings never occurred?  I don't know.  I took
Psychology 101 about 10 years ago, and the only thing
I remember about that class was all of the sexy,
mysterious, complicated, analytical young ladies
who were the teaching assistants.  Okay, that and
something about bells ringing and dogs drooling.
Oh, and left-handed mothers flashing images of ink
splotches resembling food pellets through electrodes
attached only to the right hemisphere of a cat's
brain in a jar filled with hallucinogenic drugs...
Wait, did that really happen?

-- Colin
cp...@ea...
www.colinfahey.com

Re: [GD-General] Scripting

[Mickael P. <mpo...@ed...>]

Concerning console game using scripting languags, I can at least say that
"Time Commando" (PlayStation, 1996), and "Little Big Adventure"
(PlayStation, 1997) are both based on scripts.

Actually the game engine by itself is only a bunch of functionalities:
detect collision, move and animate actors, play sound and movies, display
stuff, and so on. 100% of game logic is scripted.

The reason is the variety of actors we had. Time Commando contains 10
history periods, each with around 30 custom items/actors (opponents,
weapons, traps, bonuses, ...), so it was a lot faster to code these custom
things in scripting language than directly in the engine, because even the
more complex actors never had more than 4 page of script text (not including
resource definition, but you need it in C++ anyway).

In Little Big Adventure, it allows the designers to add a lot of small stuff
here and there that makes the game world really interesting. You want some
random sound here and there, a squirel that climbs to the nearest tree when
you approach, that's simple to do. In most standard engine, you would have
to derive a SquirelClimbingTree class derivated from some other weird
hiearchy that maked perfect sense at the beggining of the development but
that ressemble to some weird artistic sculpture at the end of the project...

Another reason, is that Time Commando was coded by a grand total of 4
programers on two simultaenous versions (PC and PlayStation), so we were
happy to let the level designers "make the game" and try things.

One of the things I notice each time a "scripting vs complete engine" thread
begins, is that most people talk about lua, python, c, perl or whatever
other off the shelf language they can think about, and the eventual problems
of interfacing with the game engine, memory management, debugging, ... but
almost no one is talking about the cool thing there is in a well design
scripting language: the fact that you can easily code separate actors like
if you were in a perfectly multitasking system.

When you code some actor in a C/C++, you have explicit entry and exit points
that are used at every refresh frame.

In a nicely designed custom scripting system you do not have these. For what
it worth, your actor is living _alone_ in a forever loop (or until he dies,
get reseted, change behavior, or whatever).

Consider the following script fragment (it's the kind of things we had in
TimeCommando, except that the C++ like syntax was not here, so we had
"TestAlive(CowBoy)"):

==============
BeginActor Indian
    UseWeapon bow
    While CowBoy.isalive
        Shoot CowBoy
        Next
    EndWhile
    PlayAnim Victory
EndActor

BeginActor CowBoy
    UseWeapon gattling
    While Endian.isalive
        Shoot Indian
        Next
    EndWhile
    PlayAnim Victory
EndActor
==============

The "Next" command simply tell the interpreter to memorise the current
program counter for the current actor, and move on on the next actor.

Using this system you gain the fact that you know in which order the actors
are executing their code so you can perform complex choregraphies because
you know that this particular actor is performing this or this exactly at
this particular moment, so you can perform particularly nasty things. Never
tried to synchronise complex objects ?

In Time Commando we had to dynamicaly split/merge characters in a way it
could not be noticed by the player. I'm not talking here of kiddy things
like some actor on a moving platform, I'm talking here of a cowboy riding on
his horse (one single animated mesh containing the horse and the rider) and
then having it climbing down from the horse and going to the saloon (two
separate objects), or a tank on a battlefield where you have the turret that
turn independantly of the tank base, and the gunner on the turret that look
around independantly of the direction the turret is looking at...

In summary: it worked fine.

    Mickael Pointier

Re: [GD-General] Re: Scripting

[Javier A. <ja...@py...>]

brian hook <bri...@py...> wrote:

>> SetPlatformDestination( 'BigFloatingRock', GetMarkerPos
>> ( 'CenterMarker01' ), 1.0 );

For what is worth, in Praetorians we rolled our own scripting language, and
it has been a great productivity tool for our designers. The language is
designed around the use we wanted for it, doesn't contain loops, functions
or high-level types (arrays, structs). Scripts are pretty much a series of
calls to engine-published functions, with condition checking and variable
assignments here and there.

It Just Works.

One of our designers was hired about a year ago. He had never touched a
computer. He has had no trouble writing scripts, and has been able to tailor
the flow of his missions without much problems. Whenever he needed some kind
of higher-level functionality he would request the programmers to add it,
but the task of the script was to sequence and parameterize the mission
flow.

  Javier Arevalo
  Pyro Studios

RE: [GD-General] Re: Scripting

[Awen L. <ali...@ed...>]

On our current grame, we are NOT using scripts (and when i read Evan Bell
post, i believe we're doing the same kind of... anyway :)).
I am really upset with that decision, (i suspect some
nonsense-but-historical reasons) but it's not a thing you shake at this
point of the project. Ok.
Let's assume we're an average team, with average design and technical
skills:
An average scripting engine introduces generally some high concepts like:
MoveTo(X,Y) PlayAnimation('A'), actorW.IsHearing(actorZ). And remember we
are not using such. So:
1) Our non scripted engine requires a programmer to code an actor. Yes.
2) The simplest functionnality-calls of an actor, requires 3 code lines (a
programmer is NOT disturbed by that: 3 or 10 code line is *EASY* to handle).
3) The actor process is supervised by the programmer (logical), so
aggregating resources, ensuring that all will work, is really really
PAINFUL. But our programmers ignores the pain. Programmers have brain
connections to slalom between difficulties (it's somewhat faster than
resolving them)
4) Bad, obscure, trickery is so ALLOWED in an actor behavior code (C++) 'Ok,
easy boy, C++ is my wisdom'

Results:
	Modifying an actor behavior is a LONG process because of reasons 1 to 4
(theorem: many little resolvable-on-the-fly troubles equal long processes).
You can't just 'modify an actor'; you'll need a meeting with:
	- a game designer (*)
	- a project lead  (*)
	- a lead code (*)
	- the programmer
(*) think salary.
Meetings equal meeting reports, equal report availabilities by mail mail to
the team, WHICH IS LONGER TO WRITE THAN THE REQUIRED BEHAVIOR SCRIPT.

Programming is usually a slow process (see HalfLife's PostMortem), and
nobody will scratch its head regarding the time it takes to code a behavior.
It'll become the standard.
But from a planning point of view, it's a real 'wanna-be' overkill.
But from a game point of view, i suspect that the lack of fun in creating an
actor is causing heavy damages to the final product.

So you must really really think about it before throwing one of the other
solution. Please (yes i beg !).

Awen






-----Message d'origine-----
De : gam...@li...
[mailto:gam...@li...]De la part de
brian hook
Envoyé : dimanche 8 décembre 2002 08:56
À : gam...@li...
Objet : Re: [GD-General] Re: Scripting


> It is more like "glue"....The designers use the scripting language
> functions just like public interfaces to game objects.

Does this mean then that you're only using it to provide coding-like
functionality to the designers without requiring them to actually write
code or harass programmers?

> SetPlatformDestination( 'BigFloatingRock', GetMarkerPos
>( 'CenterMarker01' ), 1.0 );

Right, this kind of gets back to the example me and Thatcher were
using -- instead of a "function call" interface, a data description
interface could probably do the same thing without actually requiring
there to be language constructs:

PlatformXYZ =
{
   type = 'platform',
   destination = 'BigFloatingRock',
   pos = 'CenterMarker01',
   value = 1.0
}

> The main problem we have is the designers request the ability to do
> more and more complicated tasks with the scripting language, but do
> not enjoy the requisite increase in script complexity.

Two issues here.  The first is exactly one of the concerns I have with
generalized scripting -- there is a tendency for the entire engine to
become part of the scripting language as designers ask for more and
more stuff.  The second is that you often get a lot of exposed
facilities that are never taken advantage of and, conversely, a lot of
simple features end up getting (ab)used in interesting ways to get
specific types of output.  For example, in Quake3 there were "regen"
fields that were created when one of the designers realized you could
assign a negative value to a pain field.

> To avoid creating Yet Another Crappy Parser I used flex & bison to do
> the hard work of creating the script compiler.

Eewww.  I'm leaning towards just using Lua as my syntax for, er,
everything, and letting it handle the heavy lifting.

-Hook


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
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: [GD-General] Scripting

[Kerim B. <wa...@ho...>]

Hello Brian,

Saturday, December 7, 2002, 1:33:26 AM, you wrote:

...
BH> The "ease of extensability" I think is overblown.  There's a common
BH> misconception that script languages are somehow more approachable to
BH> non-programmers than regular compiled languages, which I find to be
BH> hogwash.  Sure, C can be pretty arcane syntactically, but I dare someone
BH> to tell me with a straight face that Scheme or Python or Perl are
BH> intrinsically easier to use than traditional compiled languages.
...

I'll cite David Abrahams(not on C but on another "traditional compiled
language";-):

>>> * C++ is hard. Python is easy
>>
>>    If you are talking to a C++ audience, it doesn't seem like a way to
>> make friends :-)
DA>
DA> No, and I don't like the way the tone was coming out here.
DA> However, even as a C++ jock, I have to admit it's true.

Source: http://mail.python.org/pipermail/c++-sig/2002-December/002883.html


Best regards,
 Kerim                            mailto:wa...@ho...

RE: [GD-General] JavaScript as a scripting language

[Jacob T. (C. D. Ltd) <Ja...@Co...>]

Just to throw it into the mix didn't Naughty Dog use LISP as the basis for
the entire programming language.

i.e. http://www.gamasutra.com/features/20020710/white_02.htm

Jake

-----Original Message-----
From: brian hook [mailto:bri...@py...]
Sent: 06 December 2002 02:24
To: gam...@li...
Subject: [GD-General] JavaScript as a scripting language


Has anyone looked into using JavaScript as a game scripting language?  
It looks fairly flexible and intuitive, and it has a lot of aspects I 
find appealing, but I find it alarming that it's not mentioned nearly 
as much as, say, Python and Lua.

-Hook



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
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: [GD-General] Re: Scripting

[brian h. <bri...@py...>]

> It is more like "glue"....The designers use the scripting language 
> functions just like public interfaces to game objects.

Does this mean then that you're only using it to provide coding-like 
functionality to the designers without requiring them to actually write 
code or harass programmers?

> SetPlatformDestination( 'BigFloatingRock', GetMarkerPos
>( 'CenterMarker01' ), 1.0 );

Right, this kind of gets back to the example me and Thatcher were 
using -- instead of a "function call" interface, a data description 
interface could probably do the same thing without actually requiring 
there to be language constructs:

PlatformXYZ =
{
   type = 'platform',
   destination = 'BigFloatingRock',
   pos = 'CenterMarker01',
   value = 1.0
}

> The main problem we have is the designers request the ability to do 
> more and more complicated tasks with the scripting language, but do 
> not enjoy the requisite increase in script complexity. 

Two issues here.  The first is exactly one of the concerns I have with 
generalized scripting -- there is a tendency for the entire engine to 
become part of the scripting language as designers ask for more and 
more stuff.  The second is that you often get a lot of exposed 
facilities that are never taken advantage of and, conversely, a lot of 
simple features end up getting (ab)used in interesting ways to get 
specific types of output.  For example, in Quake3 there were "regen" 
fields that were created when one of the designers realized you could 
assign a negative value to a pain field.

> To avoid creating Yet Another Crappy Parser I used flex & bison to do 
> the hard work of creating the script compiler.

Eewww.  I'm leaning towards just using Lua as my syntax for, er, 
everything, and letting it handle the heavy lifting.

-Hook

[GD-General] Re: Scripting

[Evan B. <eb...@au...>]

I have some thoughts...

> For example, console games -- obviously the mod community isn't going=20
> to be targeting console games, so I'm curious to hear why/when/how=20
> someone would fully script AI, combat, quests, levels, etc. for a=20
> console game.  I'm sure there are good reasons, but I'm real curious =
if=20
> the actual benefits derived were worth the hassle (and if they =
couldn't=20
> have been reached some other way).

We are using a scripting language for our console games which uses a =
C-style syntax.
In hindsight this was a mistake. The first request I received was to =
remove case sensitivity:)
We currently do not use the scripting language to fully orchestrate AI, =
Combat, quests, etc.=20
It is more like "glue". Our designers are the primary users of the =
scripting language, with the artists=20
only using it to spawn particle emitters. The designers use the =
scripting language functions just like=20
public interfaces to game objects.

// ....
SetPlatformDestination( 'BigFloatingRock', GetMarkerPos( =
'CenterMarker01' ), 1.0 );

So we mainly use it to give simple instructions to existing game objects =
that are populated by the designers=20
in the level editing tool. The scripting language works in concert with =
our data driven event system.=20

> The thing with scripting languages though is that finding the right =
area to bifurcate is extremely hard.=20

The main problem we have is the designers request the ability to do more =
and more complicated tasks with the scripting
language, but do not enjoy the requisite increase in script complexity. =
I actually had one ask "What I really want is a very simple way
to create really complicated behaviour". I am still working on that =
request:)=20

To avoid creating Yet Another Crappy Parser I used flex & bison to do =
the hard work of creating the script compiler.
I would like the next postmortem I read to include the number of =
different text parsers used in the tool chain.

Evan Bell
ev...@ed...

Re: [GD-General] Scripting

[<cas...@ya...>]

Brian Hook wrote:
> A paper by Scott Bilas of GPG on Skrit (their pseudo-scripting
> language) particularly resonates with me:
>
> http://www.drizzle.com/~scottb/ds/skrit.htm
>
> a pretty good overview, and there's some links in there I think to his
> GDC talks where I think he even says all scripting languages suck (or
> something to that effect).

There are also a few chapters on AI Programing Wisdom on scripting languages
that I think are worth a read. Specially interesting are:

"How not to implement a basic scripting language", that describes the wrong
decisions made during the development of NWScript.

"Scripting for undefined circumstances", that describes the language used in
Black&White to describe challenges and cinematic scenes.

The later remembers me to the scripting language used in Ritual's FAKK2.
Scripts were almost a sequence of commands (like quake console commands).
The script interpreter is just a tokenizer, that interprets commands one by
one. Such a simple system is easy to implement, and mixed with an event
system becomes quite powerfull. It allowed you to describe things that
happen concurrently with ease. I expect that a very similar system will be
used in doom3, now that Jim Dose is working at id.


Ignacio Castaño
cas...@ya...


___________________________________________________
Yahoo! Sorteos
Consulta si tu número ha sido premiado en
Yahoo! Sorteos http://loteria.yahoo.es

Re: [GD-General] Scripting

[brian h. <bri...@py...>]

> I didn't get that impression. I assume you refer to his GDC 2002 talk
> (http://www.drizzle.com/~scottb/gdc/). I was at the talk and I walked
> away with the impression that it worked really well for them. 

I swore I read something by him to the effect that the way we 
(developers) traditionally view scripting is fundamentally broken, and 
what they did with Go/Skrit was to re-examine the problem and think of 
it in terms as a database.

In other words, Go/Skrit isn't broken, but traditional scripting is.  
But now I can't find where he said that, so I may have just 
misinterpeted something else he said.

I might add that from what I see of Skrit, it's more what I consider a 
data definition language than a scripting language.  That's a semantics 
issue, but it's an important one to me.  When I complain about 
scripting languages, I'm specifically referring to the logic that's 
placed in there, not the actual use of a separate language to define 
external data.

I mean, I don't expect everyone to do:

const Vector kVerticesForGun[] = { ... };

=)

Brian

Re: [GD-General] Scripting

[Noel L. <ll...@co...>]

On Sat, 07 Dec 2002 16:58:25 -0600
brian hook <bri...@py...> wrote:

> A paper by Scott Bilas of GPG on Skrit (their pseudo-scripting 
> language) particularly resonates with me:
> 
> http://www.drizzle.com/~scottb/ds/skrit.htm
> 
> a pretty good overview, 

I definitely like how it was tailored to their needs. No (or minimal)
support for loops, etc. I like the part of "not duplicating engine
functionality". Very true.

> and there's some links in there I think to his 
> GDC talks where I think he even says all scripting languages suck (or 
> something to that effect).

I didn't get that impression. I assume you refer to his GDC 2002 talk
(http://www.drizzle.com/~scottb/gdc/). I was at the talk and I walked
away with the impression that it worked really well for them. Yes, he
admitted they used their scripts for more things that they had
anticipated and maybe a few more of the really common ones should have
been translated to C++, but all in all it worked really well for their
situation.

For me, it was his talk and paper that rekindled my interest (and faith)
in scripts after almost giving them up as useless in game development.


--Noel
ll...@co...