gamedevlists-general — List for discussing general game development issues

Re: [GD-General] Scripting

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

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

Brian

Re: [GD-General] Scripting

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

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

Brian

Re: [GD-General] Scripting

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

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

Brian

Re: [GD-General] Scripting

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

I've been using Lua for a long time, I always embed it in my applications,
just because it's easy and I may need in the future. However, I've never
used it as a 'real' game scripting language. Most of the times it just
serves as a powerfull configuration language, or for data description.

Appart from this reasons:

> -  End user modifications that are safe (sandboxed VM), portable and
> free to develop
> -  Ease of extensibility for artists/designers
> -  Faster prototyping/development because the language is more dynamic
> and doesn't require rebuild
> - Rich data definition language

I would add another one:
- Language features that make your life easier.

That's the case, for example, of the state machines in UnrealScript and
quakec. Actor based languages (or with coroutines) can also be useful to
describe behaviours without blocking the execution. Rule based systems are
also usefull to determine tasks completion, or state changes.


> Sandboxing end user mods is a VERY good reason to script.  Using scripts
> for NPC interaction or possibly for more elaborate scripted sequences
> and triggers might be good things as well (but even so, many games have
> done just fine using data to describe triggers, NPC actions, levels,
> missions, quests, end game conditions, etc.).  Scripts as a way to make
> portable, inexpensive mods (a la UnrealScript and QuakeC) is also a
> valid reason.

Yes, I wouldn't use a scripting language to write all the game code as in
Unreal or quake3. In my opinion a general programming languages like c++
fits better for that purpouse. However, I would use a scripting language for
specific tasks, like describing cinematics, controlling cameras, dialogs...
All that without having to rebuild the application. Builds are fast, but
level loads usually aren't. In my opinion, being able to replay a cinematic
by just tipying "load('intro.lua')" is really usefull.

For a good example of how to use lua for those tasks I'd recommend to have a
look at 'hyperspace delibery boy'.

As you say, you can use data for all that, but I think that data isn't as
expresive as a scripting language. A scripting language can simplify some
tasks, but in the end it just depends on your own needs.


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 think data description (let alone "rich" data description) is reason
> enough to use something like Lua (which started its life as a data
> description language).

I agree, and in fact that's what I use Lua for right now.  It stores my 
configuration variables, and I also use it to execute extremely 
crude "level scripts" for some of our 2D games.  But I've struggled a 
bit to figure out how to go past that basic functionality, which is 
part of the reason that I'm so down on scripting recently =)

> I think you're taking on a couple separate issues here, 1) the
> language itself, and 2) the development environment (i.e. the
> mechanics of how you get your code into the running game).

Sure, I kinda tossed them in together, but at the same time, they're 
both valid reasons why scripting is a pain in the ass for non-
developers to use.  Lack of a debugger alone can be an absolute killer, 
especially if you have a huge numbers of scripts and you have some 
small corner case that only manifests itself under certain conditions.

> I can say that about Python (and Lua) with a straight face.  Although
> "intrinsically easier" is pretty subjective, in the absence of user
> studies.

I hate to be so curmudgeonly, but I think you're too experienced to 
make that call =)  Even a simple one line bit of Python looks like 
gibberish to a non-programmer.  I mean, this is something pretty simple:

data = filter(lambda x: x>=' ' and x<='z', data)

Yet you show that to an artist, and they're not going to have any idea 
what it does.  Something as basic as parens for a function call -- or a 
function call, period -- can be daunting, and this is something most 
languages will have.

Same with this chunk of Lua:

function List:reverse()
  local t,n={},getn(self)
  for i=1,n do t[i]=self[n-i+1] end -- reverse
  for i=1,n do self[i]=t[i] end -- copy back
end

Now, I know that these aren't that obtuse, but they're obtuse enough to 
a non-programmer that I just think the difference between good C code 
and the above isn't going to be that huge either way.

> I generally agree with your point that the "language" part
> of "scripting language" is *not* the killer feature that makes it
> worth doing.

Right, that's a good summary of the way I feel.
 
> IMO, in order to get designer friendliness and faster prototyping, the
> key thing to focus on is the "development environment".  (And I don't
> mean "IDE" per se; I mean whatever it is specifically that a designer
> has to do to see her changes in the game, and all the little
> mechanical details of how feedback comes out, and how you debug, etc.)

Agreed.  For example, a level designer/mapper should access scripting 
facilities from inside their level editor.  Assuming they even need to 
see the scripting code.
 
> I've never worked on a commerical game whose average edit-compile-run
> turnaround was less than a minute (and usually it has been at least 2x
> worse than that).

One minute, okay.  Five minutes, even that's fine.

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.

But these days, I'm hearing stories about build times measured in the 
tens of minutes or, in some cases, hours.  HOURS.  I just find this 
unimaginably bad, and in many cases it's because of heavy use of C++ 
templates or STL or other things like that.  The rationale is that 
stuff is bigger, huger, and more complex these days, but at what cost?

> The script-whatever-run cycle has the *potential*
> to be very quick, although it also tends to get bogged down by
> suboptimal process, in my experience. 

I would argue that it gets bogged down more often than not.  When you 
talk to people that have written scripting languages or used them, 
inevitably it's trading off one set of evils for another set that are 
often just as bad and sometimes even worse.

> Like, scripting engines where
> it's theoretically trivial to inject updated scripts into the running
> game, but nobody exposed the functionality in a way that the designers
> could use.  A simple "load(script)" command that you can trigger from
> the console in the running game goes a long way.  In general, I think
> using a scripting language for a console language is a handy thing.

I think this is what Bioware did with Baldur's Gate et. al.

> Well, you can do either of the above, or both at the same time, with a
> scripting language.  (And, as I said, I think there are advantages to
> using a scripting language's parser to digest your data.)

The main reason I started using Lua for my cvars is that I found I was 
writing Yet Another Crappy Parser, and figured I'd just Lua handle it.

The thing with scripting languages though is that finding the right 
area to bifurcate is extremely hard.  I really think this is glossed 
over too much.  Using our door example, you have a situation where you 
have to neatly define "What parts of being a door does the script 
decide; and what parts of being a door does the engine decide; and how 
do they reconcile these aspects?"

And no matter where you draw that line, you incur some kind of cost in 
development time, run-time cost, robustness, features, etc.  At one 
extreme, the "script door" is nothing but data defs read by the engine, 
at which point you have very little flexibility since any new 
capabilities implemented by the engine have to be exported repeatedly 
to the script designers.  "Oh, I can now make doors out of different 
materials, must support this capability".

At the other end of the spectrum, you have ALL properties of the game 
done in the script, and the engine is solely responsible for low level 
system tasks like rendering, marshalling input, low level audio, etc.  
At that point you're also in a special form of hell, because you've 
effectively exported huge chunks of your engine to the script so that 
the script can do meaningful work, AND you've put yourself in a 
position where your primary development pipeline is being gated by 
scripting tools which have a high likelihood of sucking.

And, honestly, if you make any major changes to your engine, you're 
probably breaking the scripts anyway.

> finalDoor = {
>   type = door,
>   key = function(opener)
>     if opener == evil_wizard then
>       nil
>     else
>       redKey
>     end
>   end
> }

That's a slippery slope you walk upon =)

> Anyway, I also struggle with the issues you raise.  I do think it's
> very helpful to know about all the things that are wrong with
> scripting languages before deciding to use one, and especially after
> you're committed to using one.

In this particular case, I went from using Lua to looking at everything 
else to deciding to roll my own to back to using Lua, all in the span 
of about a week.

It was extremely helpful to me trying to write my own, because it made 
me acutely aware of all the different implementation and design trade 
offs that a language has to make, and by extension I learned why 
different languages are good at different things and bad at others.

And that's why I've reached this philosophy now, because once I gave 
myself the "freedom" to write my own language, I realized that the 
_language_ wasn't the problem.  The language and its implementations 
can eventually become a problem, e.g. Lua's garbage collector or 
Python's footprint, but long before you reach that point, the 
integration and development process issues will become a much bigger 
concern.

I'm quite amazed at the number of developers I run into that use 
scripting languages but deep down inside still aren't comfortable with 
how and where they've integrated them into their games, which is why 
I'm so leery of scripting at this point.  You hear a lot about backdoor 
hacks to get pieces of the engine and scripts to communicate something 
that isn't cleanly defined by the pre-determined APIs.

For many developers, it makes a lot of sense, I just fear for the 
developers (and games) that feel a certain obligation to be script 
driven because everyone else.

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

This is a separate subject, but I really do feel that in many ways, 
games are being overengineered.  Tempting technologies like C++, STL, 
scripts, garbage collection/ref-counting/smart pointers, keep rearing 
their heads, and they make such promises of how everything will be 
better, but when you get right down to brass tacks, rarely have things 
improved.

I have a C++ application framework code base, and I have some open 
source stuff I'm developing on the side that is ANSI C.  The latter 
stuff, without exception, is better architected than the former, 
because C++ hierarchies have a tendency of "hardening".  Code acquires 
a sense of mass and inertia that makes it difficult to modify, and when 
you have huge amounts of interdependent code, like a C++ class 
hierarchy, then trivial changes become non-trivial.

STL is the same thing -- it's so great to have something like std::set 
or std::list available all the time, but holy crap, is writing a linked 
list REALLY that stressful?  Because the last couple times I used STL, 
the 15 second list vs. the 5 minute self-rolled list time advantage 
evaporated the first time I had to try to read STL code in the debugger 
and look at opaque pointers with no idea what died and where.  But I 
was convinced that STL was a "better" way of doing things.

Then you start hearing horror stories about build times with STL; rapid 
rise in binary data size; inability to debug code deep inside STL; etc. 
and suddenly you find that your project is suffering in many different 
areas because you wanted to take the easy way out and reuse a very 
popular and successful library.

This isn't about NIH vs. non-NIH, it's about theoretical vs. actual 
benefits of things that are just touted as "better" without any real 
objective data to back it up.  It's about purity of design vs. 
pragmatism in development.  It's 80s software engineering dogma vs. old 
fashioned "just getting it done".

Are STL and C++ worthwhile if you can no longer have an incremental 
build cycle?  Are scripts worthwhile if you can no longer debug them, 
or if you spend just as much time dealing with script<->engine 
communication as you would have just writing the scripted stuff 
directly into the engine?  Is SourceSafe's GUI better than using cvs at 
the command line if you can no longer check out stuff remotely from 
home?  Is garbage collection really that much better if you now have to 
start searching for cycles and be real careful about how you allocate 
objects during run-time, and when you gc, and when/how you delete root 
objects that can cause cascading gc?

Okay, I'll be quiet now, I feel better =)

-Brian

Re: [GD-General] Scripting

[Thatcher U. <tu...@tu...>]

On Fri, 6 Dec 2002, Brian Hook wrote:

> If you enumerate the legitimate reasons that scripting is implemented, I
> would bet it's something like this:
>
> -  End user modifications that are safe (sandboxed VM), portable and
> free to develop
> -  Ease of extensibility for artists/designers
> -  Faster prototyping/development because the language is more dynamic
> and doesn't require rebuild
> - Rich data definition language

Good list.

I think data description (let alone "rich" data description) is reason
enough to use something like Lua (which started its life as a data
description language).  The costs are pretty low -- you need to get
your data into the engine somehow anyway, and the API is no worse than
any other data-importing API I've encountered (and better than most,
or at least more consistent and complete).  In the engine at work we
have four or five independent little ad-hoc parsers (and one nice big
fancy one) in different places.  It's just hard to prevent those
little parsers from getting written, because they're all doing crucial
work.  But if you standardize on a flexible data description language
from the get-go, coders are more likely to use the facilities at hand.

XML is probably the classic example here, although I've been exposed
to some god-awful parsers.

> The "ease of extensability" I think is overblown.  There's a common
> misconception that script languages are somehow more approachable to
> non-programmers than regular compiled languages, which I find to be
> hogwash.

I think you're taking on a couple separate issues here, 1) the
language itself, and 2) the development environment (i.e. the
mechanics of how you get your code into the running game).

> Sure, C can be pretty arcane syntactically, but I dare someone
> to tell me with a straight face that Scheme or Python or Perl are
> intrinsically easier to use than traditional compiled languages.

I can say that about Python (and Lua) with a straight face.  Although
"intrinsically easier" is pretty subjective, in the absence of user
studies.  I generally agree with your point that the "language" part
of "scripting language" is *not* the killer feature that makes it
worth doing.

IMO, in order to get designer friendliness and faster prototyping, the
key thing to focus on is the "development environment".  (And I don't
mean "IDE" per se; I mean whatever it is specifically that a designer
has to do to see her changes in the game, and all the little
mechanical details of how feedback comes out, and how you debug, etc.)

[snip]

> Of course, if your current project has 16 programmers and requires
> 1+ hour to do a full rebuild, then maybe scripting simply is
> required, period, to make development even feasible.  But then it's
> a case of scripting not being inherently useful, only that scripting
> is a band aid to another broken part of the development process.

I've never worked on a commerical game whose average edit-compile-run
turnaround was less than a minute (and usually it has been at least 2x
worse than that).  The script-whatever-run cycle has the *potential*
to be very quick, although it also tends to get bogged down by
suboptimal process, in my experience.  Like, scripting engines where
it's theoretically trivial to inject updated scripts into the running
game, but nobody exposed the functionality in a way that the designers
could use.  A simple "load(script)" command that you can trigger from
the console in the running game goes a long way.  In general, I think
using a scripting language for a console language is a handy thing.

So I think cycle-time is probably the number one thing to address in
terms of a scripting development environment, and after that, a
debugger.  Although I'm speaking in theoreticals here; I've never yet
worked on a commercial game where the scripting language had a working
graphical debugger.  But, the potential is just sitting there: all the
off-the-shelf languages that have been mentioned so far have graphical
debuggers.

> The rich data description I think is a good use of scripting, since
> you can have conditional data.  But that's typically using just a
> small subset of a script language, and I tend to think of it more as
> data definition than as scripting.  And in many cases, you can avoid
> this by simply making it more data driven (which, granted, incurs
> its own set of headaches, but is eminently doable).
>
> For example, if a certain door can only be unlocked by a red key,
> then you can either drive this with pure data:
>
> finalDoor = {
>    type = door,
>    key = redKey
> };
>
> or you can do some scripting thing, which feels "niftier", but I'm
> not sure if it's actually that much more powerful.  It has the
> potential to be far more expressive, but whether that's actually
> leveraged is often up in the air.  The ability to do something
> doesn't always translate to doing something:
>
> finalDoor inherits door
> {
>    bool canUnlock( key k )
>    {
>       if ( key == redKey )
>          return true;
>       return door::canUnlock( k );
>    }
> }

Well, you can do either of the above, or both at the same time, with a
scripting language.  (And, as I said, I think there are advantages to
using a scripting language's parser to digest your data.)

I think the "pure data" approach has a lot going for it.  One nice
(but also scary) thing about many scripting languages is that you can
jam little functions in with the data.  IME that can make some things
much clearer and simpler to set up.  For example:

finalDoor = {
  type = door,
  key = function(opener)
    if opener == evil_wizard then
      nil
    else
      redKey
    end
  end
}

So I've just made a door the Evil Wizard can't open, even if he has
the red key.  Bad example, I know... but I have used this kind of
pattern before, and it can make certain things much clearer than
putting the little functions somewhere else and referring to them by
name.

Anyway, I also struggle with the issues you raise.  I do think it's
very helpful to know about all the things that are wrong with
scripting languages before deciding to use one, and especially after
you're committed to using one.

-Thatcher

[GD-General] Scripting

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

> I've been wrestling with the idea of scripting for years.

I think that's one of my problems with scripting, in general.  It comes
off as a solution looking for a problem.  I'm not saying that scripting
is intrinsically crappy or bad or wrong, but in many cases I've found
that it's implemented because the developers feel an obligation to have
some kind of scripting, even if they don't know why.

If you enumerate the legitimate reasons that scripting is implemented, I
would bet it's something like this:

-  End user modifications that are safe (sandboxed VM), portable and
free to develop
-  Ease of extensibility for artists/designers
-  Faster prototyping/development because the language is more dynamic
and doesn't require rebuild
- Rich data definition language

So looking at the above list, if you don't need end user mods, then the
first group is just out.  Note that you can also implement sandboxed,
portable and safe mods using a regular off the shelf language --
Quake3's VM system with the retargeted lcc works just like that.

The "ease of extensability" I think is overblown.  There's a common
misconception that script languages are somehow more approachable to
non-programmers than regular compiled languages, which I find to be
hogwash.  Sure, C can be pretty arcane syntactically, but I dare someone
to tell me with a straight face that Scheme or Python or Perl are
intrinsically easier to use than traditional compiled languages.  Not
only that, but C can be made fairly readable by using appropriate
typedefs, macros and presenting a small, constrained API for the
designer/artist -- if they have to do pointer arithmetic, sure, there
are problems, but if they do everything like this:

MAKEMODEL( myGunModel, "gun.mdl" );
MAKEENTITY( myGunEntity, myGunModel );

placeEntity( myGunEntity, 10, 100, 20 );

instead of like this:

model_t *gun = malloc( sizeof( model_t ) );
entity_t *ent = malloc( sizeof( entity_t ) );

if ( !loadModel( gun, "gun.mdl"  ) )
{
   free( gun ); free( ent );
   return 0;
}
if ( !createEntity( ent, gun ) )
{
   free( gun ); free( ent );
   return 0;
}

placeEntity( ent, 10, 100, 20 );

They're both "C", but one is obviously going to be a little easier to
grasp than the other for a non-programmer.

The faster prototyping comes at a cost, which is usually a lack of type
checking and significant run-time penalties.  The faster you can develop
new code by just creating new types and messages on the fly, the less
robust your run-time environment will be.  Discipline fixes this
somewhat, but if you're not going to require type checking of arguments
to functions (for examples), you're asking for trouble.  Languages that
have traditionally done this are definitely less stable.  If you expect
'x' to respond to the 'doSomething' message and it has no clue what that
is, ka-boom.

Now, is this really what you want in a shipped game?  Is this what you
want in a persistent universe?  I don't think so, personally.

Of course, if your current project has 16 programmers and requires 1+
hour to do a full rebuild, then maybe scripting simply is required,
period, to make development even feasible.  But then it's a case of
scripting not being inherently useful, only that scripting is a band aid
to another broken part of the development process.

The rich data description I think is a good use of scripting, since you
can have conditional data.  But that's typically using just a small
subset of a script language, and I tend to think of it more as data
definition than as scripting.  And in many cases, you can avoid this by
simply making it more data driven (which, granted, incurs its own set of
headaches, but is eminently doable).

For example, if a certain door can only be unlocked by a red key, then
you can either drive this with pure data:

finalDoor = {
   type = door,
   key = redKey
};

or you can do some scripting thing, which feels "niftier", but I'm not
sure if it's actually that much more powerful.  It has the potential to
be far more expressive, but whether that's actually leveraged is often
up in the air.  The ability to do something doesn't always translate to
doing something:

finalDoor inherits door
{
   bool canUnlock( key k )
   {
      if ( key == redKey )
         return true;
      return door::canUnlock( k );
   }
}

> - First I really, trully, think it's the best way to put the 
> power in the artist's and designers hands without involving 
> the programmers. 

If the scripting language is robust and powerful, then the programmers
will be involved.  With power comes complexity, I don't think there's
much you can do to avoid that.  If the scripting language isn't that
robust and powerful, then the programmers are still going to be involved
to patch the binaries to add new features.

> - Then I start thinking that a programmer should be involved 
> anyway, but it's still a great way to decouple game behavior 
> that changes all the time from engine code.

Why is decoupling good?  I'm quite serious -- this is a common
assumption that somehow the "engine code" is expected to be recompiled,
but that "game code" should be isolated from that.  Engine, game,
whatever, it's still code.

Not only that, but in order to decouple, you have to "recouple".  When
you integrate a scripting language, you now have to go back to your
engine and your scripts and figure out how the two components are going
to communicate.  This sometimes means making wrappers for all your data
and entry points so they can be communicated back and forth.  Don't
underestimate the amount of work that's required if you want the
scripting language to do non-trivial work.

In most situations with scripting, you have an engine that calls out to
script; a script that calls into the engine; or a mix of the two.  No
matter what direction it goes, you still have to spend a lot of time
glueing the components together.  If you change a data structure or
interface, the scripts are going to be broken again, so the decoupling
never really lasts.

If the engine is frozen solid, then you may not be spending a lot of
time repatching the scripts, but if that's the case, often you can just
separate the game code into a DLL and reap most of the benefits right
there.
 
> - Then I realize that if we're going to have a programmer 
> involved, the pain and suffering we go through for a 
> scripting language might be totally moot. Debugging goes from 
> non-existent to sucky (compared to the
> C++ debugger), performance needs a lot of tweaking and has to be done
> carefully... so we might as well write all that code in C++.

Exactly.

So you get this keen scripting language, and now you have to deal with
the following:

- memory management or lack thereof
- compatibility with threading
- adhering to the language's model for objects, threads/coroutines,
memory
- learning a new language and set of programming idioms
- creating glue layers to go back and forth
- lack of a debugger
- dealing with bugs in the scripting environment
- performance problems due to GC, interpretation, lack of native types,
etc.

> All in all, when it comes down to it, I still haven't made up 
> my mind. It's a potentially very complex and time-consuming 
> system that could make things worse for everybody if done wrong.

The big realization I had is that I was looking at scripting as a
solution to a problem that I hadn't encountered yet.  There's a lot of
conventional wisdom that scripting is required, necessary and just a
part of life, but I haven't actually witnessed a situation where the
actual scripting was beneficial WITHOUT being just a crutch to make up
for massive weaknesses somewhere else.

Scripting is all too often used as a patch for problems that, IMO,
should be addressed at the core.  If your build times take hours, then
fix that.  If your artists/designers are spending lots of time trying to
make new behaviours, then figure out a set of tools that enhance this
process -- do you really want artists/designers hand editing text files
with scripts and then running the game hoping it works?

Once again, to be very clear, I'm not saying that scripting is pointless
or a waste of time, but before someone sits down and takes the
considerable time to make an engine scriptable, they really need to make
sure that there's an actual problem being solved.

Sandboxing end user mods is a VERY good reason to script.  Using scripts
for NPC interaction or possibly for more elaborate scripted sequences
and triggers might be good things as well (but even so, many games have
done just fine using data to describe triggers, NPC actions, levels,
missions, quests, end game conditions, etc.).  Scripts as a way to make
portable, inexpensive mods (a la UnrealScript and QuakeC) is also a
valid reason.

Brian

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

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

On Fri, 06 Dec 2002 12:23:09 -0800
Brian Hook <bri...@py...> wrote:

> All that said, I'm pretty down on game scripting in general, but I'll
> leave that for another post.

Oh, please, don't leave us hanging. Tell us what is in your mind.

I've been wrestling with the idea of scripting for years. My reasoning
goes something along these lines. I'll be in one of these states
depending on the current month:

- First I really, trully, think it's the best way to put the power in
the artist's and designers hands without involving the programmers. 

- Then I start thinking that a programmer should be involved anyway, but
it's still a great way to decouple game behavior that changes all the
time from engine code.

- Then I realize that if we're going to have a programmer involved, the
pain and suffering we go through for a scripting language might be
totally moot. Debugging goes from non-existent to sucky (compared to the
C++ debugger), performance needs a lot of tweaking and has to be done
carefully... so we might as well write all that code in C++.

- Then I realize that the programmers are in the way and I go back to
step one.


Some side thoughts are using C++ as DLLs, which helps with some of the
flexibility for the game code. Other thoughts is to use a scripting
language as a middle layer. Designers and artists don't have to ever
touch it unless they want to. All the tools generate that intermediate
language (for behaviors, triggers, GUI, etc), which can also be examined
and edited directly.

All in all, when it comes down to it, I still haven't made up my mind.
It's a potentially very complex and time-consuming system that could
make things worse for everybody if done wrong.


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

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

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

Ignacio,

These are, in fact, the reasons I was looking at JavaScript.  From a
pragmatic standpoint, it has a syntax and methodology that's a lot more
approachable than Lua's for a lot of programmers (and even
non-programmers who may have experience from Web site development).  It
has GC (although, like you, I'm unclear on what kind of garbage
collection is prevalent -- it's up to each browser and/or engine to
select the form GC, but early versions were mark-and-sweep and I think
very early versions of Netscape were ref-counted).  It's trivial to
embed.    It's interpreted and quite fast (the njs benchmarks at the
GCLS are generally as fast, if not faster, than Lua's).  It also has a
reasonably clean interface to and from an application, although looking
at some of the docs for garbage collection, the active participation an
app must undergo in order to "root" an object seems kind of ugly.

I also like that it's dynamically typed and prototype based instead of
being class based.  I think this provides a lot of clean generality
since there's no artificial bifurcation between types and objects --
they're one and the same, and 'types' are now first class objects (which
I believe SmallTalk and Obj-C also supported).

So given all this, I'm confused as to why JavaScript isn't mentioned in
the same breath as Python and Lua and Ruby when it comes to game
scripting.  There are free implementations (SpiderMonkey), it's
portable, and it's already heavily used and well understood with a TON
of documentation available for it.

My only guess is that there's a stigma attached to it since some people
consider it (erroneously) a glorified form of HTML.  Of course, there's
also the obvious "it sucks because of [these reasons]", but I've never
actually seen someone do a post-mortem or at least a rationalization on
why njs/SpiderMonkey/JS are bad for game scripting.

All that said, I'm pretty down on game scripting in general, but I'll
leave that for another post.

Brian

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

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

> Given Python and Lua (and especially given that you've 
> already used Lua, IIRC) why would you want to use anything else --
especially 
> JavaScript?

Python is extremely large, relatively speaking, and I dislike its
syntax.  Lua has a significant problem with its garbage collector being
fairly old fashioned and unpredictable in execution duration.

JavaScript has a lot of things about it that I like, and given that it
satisfies all the check list items when it comes to scripting, I'm
mostly curious why it's not more prevalent.

I don't see anything particularly wrong with its syntax or design, and
in fact I kind of like prototype based languages.

Brian

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

[Kent Q. <ken...@co...>]

I'd be interested in hearing why you find JavaScript at all appealing. 
Appalling would be more like it, IMO. I think it's a nasty little 
language...but I've got an open mind. :-)

Given Python and Lua (and especially given that you've already used Lua, 
IIRC) why would you want to use anything else -- especially JavaScript?

         Kent

At 08:23 PM 12/5/2002 -0600, you wrote:
>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.

Kent Quirk, CTO, CogniToy
ken...@co...
http://www.cognitoy.com 

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

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

brian hook wrote:
> 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.

Lua has always been my favourite scripting language, but the other day I
thought just the same thing. njs seems to be quite small and fast enough for
use in a game. I don't know what kind of gc it uses, though.

Many people are more confortable with javascript C-like sintax and scoping
rules, so if your end users are going to touch the scripts, that may be a
benefit. It also seems to be easy to embed.

Anyway, if you try it, I'd love to hear about your conclusions.


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


_______________________________________________________________
Copa del Mundo de la FIFA 2002
El único lugar de Internet con vídeos de los 64 partidos. 
¡Apúntante ya! en http://fifaworldcup.yahoo.com/fc/es/

[GD-General] JavaScript as a scripting language

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

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

[GD-General] An alternative to gettext

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

Hi,
I'm looking for an alternative to gettext. Why do not use it? Because it's
under GPL, so you know...

I can still use the text extraction tools and the catalog editors, though,
but not the libintl library that reads the catalogs and does the runtime
translation. I know at least of one non-GPL gettext replacement, the one
that wxWindows uses, but it has many dependancies with the wx library, so
I'm looking for a self-contained alternative. Do any other implementations
exist? Are there any other alternatives to gettext?

Thanks in advance,


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

_______________________________________________________________
Copa del Mundo de la FIFA 2002
El único lugar de Internet con vídeos de los 64 partidos. 
¡Apúntante ya! en http://fifaworldcup.yahoo.com/fc/es/

Re: [GD-General] software for artwork

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

> <plug>
> http://www.gamasutra.com/features/20010416/ivanov_pfv.htm
> </plug>
> 
> ;-)

Hey, that is an interesting, well-written article, Assen!

--- Colin

Re: [GD-General] software for artwork

[Ivan-Assen I. <as...@ha...>]

> you should definitely be able to find source code for kohonen nets and VQ
> stuff, i know we did at the time (but can't remember where now, all lost in
> the deep past :)

<plug>
http://www.gamasutra.com/features/20010416/ivanov_pfv.htm
</plug>

;-)

RE: [GD-General] software for artwork

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

we couldn't find anything good and free that handled alpha when we were
doing stuntman

we found a very expensive japanese package that did a good job (name escapes
me)

in the end, we went with a vector quantisation approach (or had done up
until i left the company :)

you should definitely be able to find source code for kohonen nets and VQ
stuff, i know we did at the time (but can't remember where now, all lost in
the deep past :)

jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Lionel Fumery
Sent: 13 November 2002 22:13
To: gam...@li...
Subject: Re: [GD-General] software for artwork


Hello,

I have currently exactly this kind of stuff to write : something to convert
32bits pictures into 8bits with palette ARGB for the PlayStation 2. I never
really though to this question, so I though it would be easy to do (simple
octree in 4D space, or something like that).

Could you give me more details about the alpha channel multiplication ?
A quick search with Google shows me a lot of answers about the Kohonon nets.
But is there somewhere a not-too-bad free lib with source that could help me
? (in fact, I didn't give a lot of time in my schedule to do that task :))

Thank you for any advice,

Lionel.

----- Original Message -----
From: "Tom Forsyth" <to...@mu...>
To: <gam...@li...>
Sent: Wednesday, November 13, 2002 3:30 PM
Subject: RE: [GD-General] software for artwork


> Yep - we premultiply, palettise, and then un-premultiply again. Works
well.
> We've also spent quite a lot of effort finding good palettisers.
> Kohonon-network based ones are good, and weused that for the last project.
> The new one is a mad mix of various perceptual techniques and stuff (we
have
> a chap fascinated by this stuff), works in an arbitrary number of
> dimensions, but is very very slow. We plan to use the old kohonen one for
> quick previews, and then overnight crunch away at the textures with the
> slow-but-superb one.
>
> But we never found any decent out-of-the-box ones.
>
>
> Tom Forsyth - Muckyfoot bloke and Microsoft MVP.
>
> This email is the product of your deranged imagination,
> and does not in any way imply existence of the author.
>
> > -----Original Message-----
> > From: Javier Arevalo [mailto:ja...@py...]
> > Sent: 13 November 2002 09:11
> > To: gam...@li...
> > Subject: Re: [GD-General] software for artwork
> >
> >
> > Mickael Pointier <mpo...@ed...> wrote:
> >
> > > Standard quantization algorithms create artefacts, but thats not
> > > visually to disturbing when applied to color components,
> > surprisingly
> > > if you extend these algorithm to 4d, the final result is really,
> > > really crappy...
> > >
> > > I think the reasons are multiples, the first beeing that when A tend
> > > toward 0, you do not really care about the true values of RGB
> > > components (they are almost invisible at this point), so a lot of
> > > colors are used in semi translucent tints, that could have been used
> > > in nearly opaque areas.
> >
> > Yeah that's one of the places where premultiplied alpha
> > textures help...
> >
> >   Javier Arevalo
> >   Pyro Studios
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Are you worried about
> your web server security? Click here for a FREE Thawte
> Apache SSL Guide and answer your Apache SSL security
> needs: http://www.gothawte.com/rd523.html
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>



-------------------------------------------------------
This sf.net email is sponsored by: Are you worried about
your web server security? Click here for a FREE Thawte
Apache SSL Guide and answer your Apache SSL security
needs: http://www.gothawte.com/rd523.html
_______________________________________________
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] software for artwork

[Tom F. <to...@mu...>]

The premultiply is pretty simple.

The standard blend equation is this:

result = texture.C * texture.A + fb.C * (1-texture.A)

...which means that when texture.A is close to zero, the values of texture.C
really aren't very exciting - they produce only small changes. Perceptually,
the only thing that matters is (texture.C*texture.A). So do the multiply:

texture2.C = texture.C * texture.A
texture2.A = texture.A

Then palettise.

Many (myself included) then say you should keep it in this form right to the
actual blend, so you do a ONE:INVSRCALPHA blend instead of the more normal
SRCALPHA:INVSRCALPHA blend. But the PS2 can't actually do this blend (doh!),
so you need to convert back to the original form once you've palettised and
do:

texture3.C = texture2.C / texture2.A
texture3.A = texture2.A

(cope with the singularities at texture2.A==0 by making texture3.C anything
you like, usually black).

...and there you go. The pallising was done in a much more
perceptually-significant colourspace, so it should be much higher quality.


(note that the PS2 can do ONE:SRCALPHA blending, so you could just invert
the alpha channel, but then the rest of the blend pipeline is a pain if you
want to fade stuff in and out and so on).


Tom Forsyth - Muckyfoot bloke and Microsoft MVP.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Lionel Fumery [mailto:li...@mi...]
> Sent: 13 November 2002 22:13
> To: gam...@li...
> Subject: Re: [GD-General] software for artwork
> 
> 
> Hello,
> 
> I have currently exactly this kind of stuff to write : 
> something to convert
> 32bits pictures into 8bits with palette ARGB for the 
> PlayStation 2. I never
> really though to this question, so I though it would be easy 
> to do (simple
> octree in 4D space, or something like that).
> 
> Could you give me more details about the alpha channel 
> multiplication ?
> A quick search with Google shows me a lot of answers about 
> the Kohonon nets.
> But is there somewhere a not-too-bad free lib with source 
> that could help me
> ? (in fact, I didn't give a lot of time in my schedule to do 
> that task :))
> 
> Thank you for any advice,
> 
> Lionel.
> 
> ----- Original Message -----
> From: "Tom Forsyth" <to...@mu...>
> To: <gam...@li...>
> Sent: Wednesday, November 13, 2002 3:30 PM
> Subject: RE: [GD-General] software for artwork
> 
> 
> > Yep - we premultiply, palettise, and then un-premultiply 
> again. Works
> well.
> > We've also spent quite a lot of effort finding good palettisers.
> > Kohonon-network based ones are good, and weused that for 
> the last project.
> > The new one is a mad mix of various perceptual techniques 
> and stuff (we
> have
> > a chap fascinated by this stuff), works in an arbitrary number of
> > dimensions, but is very very slow. We plan to use the old 
> kohonen one for
> > quick previews, and then overnight crunch away at the 
> textures with the
> > slow-but-superb one.
> >
> > But we never found any decent out-of-the-box ones.
> >
> >
> > Tom Forsyth - Muckyfoot bloke and Microsoft MVP.
> >
> > This email is the product of your deranged imagination,
> > and does not in any way imply existence of the author.
> >
> > > -----Original Message-----
> > > From: Javier Arevalo [mailto:ja...@py...]
> > > Sent: 13 November 2002 09:11
> > > To: gam...@li...
> > > Subject: Re: [GD-General] software for artwork
> > >
> > >
> > > Mickael Pointier <mpo...@ed...> wrote:
> > >
> > > > Standard quantization algorithms create artefacts, but thats not
> > > > visually to disturbing when applied to color components,
> > > surprisingly
> > > > if you extend these algorithm to 4d, the final result is really,
> > > > really crappy...
> > > >
> > > > I think the reasons are multiples, the first beeing 
> that when A tend
> > > > toward 0, you do not really care about the true values of RGB
> > > > components (they are almost invisible at this point), 
> so a lot of
> > > > colors are used in semi translucent tints, that could 
> have been used
> > > > in nearly opaque areas.
> > >
> > > Yeah that's one of the places where premultiplied alpha
> > > textures help...
> > >
> > >   Javier Arevalo
> > >   Pyro Studios
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: Are you worried about
> > your web server security? Click here for a FREE Thawte
> > Apache SSL Guide and answer your Apache SSL security
> > needs: http://www.gothawte.com/rd523.html
> > _______________________________________________
> > Gamedevlists-general mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=557
> >
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Are you worried about 
> your web server security? Click here for a FREE Thawte 
> Apache SSL Guide and answer your Apache SSL security 
> needs: http://www.gothawte.com/rd523.html
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

[GD-General] RE: software for artwork

[Iain R. <i.n...@re...>]

>     I'm looking for some cheap software for producing artwork for a game
> (3D models and scenes, 2D textures, backgrounds, etc.) for using on
> Windows platform.

Yes, Blender is not bad for 3D, although you really need to download or
buy documentation for it, as the user interface not self-explanatory.
For 2D, there's always Corel (Photopaint in particular). You can usually
buy a slightly old version cheap (I got version 8 for £20).

Iain

Re: [GD-General] software for artwork

[Lionel F. <li...@mi...>]

Hello,

I have currently exactly this kind of stuff to write : something to convert
32bits pictures into 8bits with palette ARGB for the PlayStation 2. I never
really though to this question, so I though it would be easy to do (simple
octree in 4D space, or something like that).

Could you give me more details about the alpha channel multiplication ?
A quick search with Google shows me a lot of answers about the Kohonon nets.
But is there somewhere a not-too-bad free lib with source that could help me
? (in fact, I didn't give a lot of time in my schedule to do that task :))

Thank you for any advice,

Lionel.

----- Original Message -----
From: "Tom Forsyth" <to...@mu...>
To: <gam...@li...>
Sent: Wednesday, November 13, 2002 3:30 PM
Subject: RE: [GD-General] software for artwork


> Yep - we premultiply, palettise, and then un-premultiply again. Works
well.
> We've also spent quite a lot of effort finding good palettisers.
> Kohonon-network based ones are good, and weused that for the last project.
> The new one is a mad mix of various perceptual techniques and stuff (we
have
> a chap fascinated by this stuff), works in an arbitrary number of
> dimensions, but is very very slow. We plan to use the old kohonen one for
> quick previews, and then overnight crunch away at the textures with the
> slow-but-superb one.
>
> But we never found any decent out-of-the-box ones.
>
>
> Tom Forsyth - Muckyfoot bloke and Microsoft MVP.
>
> This email is the product of your deranged imagination,
> and does not in any way imply existence of the author.
>
> > -----Original Message-----
> > From: Javier Arevalo [mailto:ja...@py...]
> > Sent: 13 November 2002 09:11
> > To: gam...@li...
> > Subject: Re: [GD-General] software for artwork
> >
> >
> > Mickael Pointier <mpo...@ed...> wrote:
> >
> > > Standard quantization algorithms create artefacts, but thats not
> > > visually to disturbing when applied to color components,
> > surprisingly
> > > if you extend these algorithm to 4d, the final result is really,
> > > really crappy...
> > >
> > > I think the reasons are multiples, the first beeing that when A tend
> > > toward 0, you do not really care about the true values of RGB
> > > components (they are almost invisible at this point), so a lot of
> > > colors are used in semi translucent tints, that could have been used
> > > in nearly opaque areas.
> >
> > Yeah that's one of the places where premultiplied alpha
> > textures help...
> >
> >   Javier Arevalo
> >   Pyro Studios
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Are you worried about
> your web server security? Click here for a FREE Thawte
> Apache SSL Guide and answer your Apache SSL security
> needs: http://www.gothawte.com/rd523.html
> _______________________________________________
> 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] software for artwork

[Sebastian U. <su...@it...>]

 Thanks for the lengthy answer (and all the others). I'm not trying to do
art myself, but to plan a project on a country which has devalued it's
currency by a factor of 3.6 since less than a year. For a small project,
with little staff, paying 3500 USD por 3DStudio is just impossible right
now, and I'm sure we can handle most of the art with something less complex
than the most expensive programs (hoping the artists will learn the programs
fast enough).


Bob wrote:

> Ultimately, I look at the initial question, posted on a game development
> list, and wonder: am I just sending out yet another programmer to try
> solving the need for an artist with a piece of software? Maybe the link
> that is most needed is something like this: <http://www.ice.org>.

--
Sebastián Uribe
ITOCHU Argentina S.A.
su...@it...

RE: [GD-General] software for artwork

[Tom F. <to...@mu...>]

Yep - we premultiply, palettise, and then un-premultiply again. Works well.
We've also spent quite a lot of effort finding good palettisers.
Kohonon-network based ones are good, and weused that for the last project.
The new one is a mad mix of various perceptual techniques and stuff (we have
a chap fascinated by this stuff), works in an arbitrary number of
dimensions, but is very very slow. We plan to use the old kohonen one for
quick previews, and then overnight crunch away at the textures with the
slow-but-superb one.

But we never found any decent out-of-the-box ones.


Tom Forsyth - Muckyfoot bloke and Microsoft MVP.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Javier Arevalo [mailto:ja...@py...]
> Sent: 13 November 2002 09:11
> To: gam...@li...
> Subject: Re: [GD-General] software for artwork
> 
> 
> Mickael Pointier <mpo...@ed...> wrote:
> 
> > Standard quantization algorithms create artefacts, but thats not
> > visually to disturbing when applied to color components, 
> surprisingly
> > if you extend these algorithm to 4d, the final result is really,
> > really crappy... 
> > 
> > I think the reasons are multiples, the first beeing that when A tend
> > toward 0, you do not really care about the true values of RGB
> > components (they are almost invisible at this point), so a lot of
> > colors are used in semi translucent tints, that could have been used
> > in nearly opaque areas. 
> 
> Yeah that's one of the places where premultiplied alpha 
> textures help...
> 
>   Javier Arevalo
>   Pyro Studios

Re: [GD-General] software for artwork

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

Mickael Pointier <mpo...@ed...> wrote:

> Standard quantization algorithms create artefacts, but thats not
> visually to disturbing when applied to color components, surprisingly
> if you extend these algorithm to 4d, the final result is really,
> really crappy... 
> 
> I think the reasons are multiples, the first beeing that when A tend
> toward 0, you do not really care about the true values of RGB
> components (they are almost invisible at this point), so a lot of
> colors are used in semi translucent tints, that could have been used
> in nearly opaque areas. 

Yeah that's one of the places where premultiplied alpha textures help...

  Javier Arevalo
  Pyro Studios

Re: [GD-General] software for artwork

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

Javier Arevalo wrote:
> Mickael Pointier <mpo...@ed...> wrote:
>
>> Aura is more in the paint box category, while Pro Motion is the
>> spiritual successor of Deluxe Paint, and is particularly good for
>> clut based picturing (GBA and PS2)
>
> Kind of changing topic here, but I'm curious... are manual
> palettization and pixel-drawing common in PS2 developement? You had
> to do it sometimes on the PS1, but I'm surprised it is still the case
> on the PS2, I expected most palettes to be generated from rgb
> images/textures.

For most pictures, you are right, but we had trouble finding a good
algorithm to generate picture in 256 colors, using a 32 bit ARGB clut,
specially when the alpha channel is used.

Standard quantization algorithms create artefacts, but thats not visually to
disturbing when applied to color components, surprisingly if you extend
these algorithm to 4d, the final result is really, really crappy...

I think the reasons are multiples, the first beeing that when A tend toward
0, you do not really care about the true values of RGB components (they are
almost invisible at this point), so a lot of colors are used in semi
translucent tints, that could have been used in nearly opaque areas.

So, we had some graphist that some time to time on critical bitmaps create
cluts by hand, and remap the 32bits bitmap using that particular clut...


    Mike

Re: [GD-General] software for artwork

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

Mickael Pointier <mpo...@ed...> wrote:

> Aura is more in the paint box category, while Pro Motion is the
> spiritual successor of Deluxe Paint, and is particularly good for
> clut based picturing (GBA and PS2)

Kind of changing topic here, but I'm curious... are manual palettization and
pixel-drawing common in PS2 developement? You had to do it sometimes on the
PS1, but I'm surprised it is still the case on the PS2, I expected most
palettes to be generated from rgb images/textures.

  Javier Arevalo
  Pyro Studios