Thread: [GD-General] JavaScript as a scripting language
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: brian h. <bri...@py...> - 2002-12-06 02:23:59
|
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 |
|
From: <cas...@ya...> - 2002-12-06 16:27:57
|
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/ |
|
From: Brian H. <bri...@py...> - 2002-12-06 20:25:30
|
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 |
|
From: Noel L. <ll...@co...> - 2002-12-06 21:45:23
|
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... |
|
From: Brian H. <bri...@py...> - 2002-12-06 22:33:47
|
> 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
|
|
From: Thatcher U. <tu...@tu...> - 2002-12-07 01:49:30
|
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
|
|
From: <cas...@ya...> - 2002-12-07 03:38:23
|
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
|
|
From: Kerim B. <wa...@ho...> - 2002-12-09 09:32:58
|
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... |
|
From: Mickael P. <mpo...@ed...> - 2002-12-09 13:09:14
|
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
|
|
From: mike w. <mi...@ub...> - 2002-12-10 02:18:28
|
they weren't console games, but didn't thief and system shock 2 use the same engine, with the exception of scripts etc? i recall reading that they used almost exactly the same executable up until the very last minute...and created two very unique games at the same time. this is how we're implementing things - we are using the scripting language in the very way that brian and others have been trying to avoid - as a complete language with the requisite 'language constructs', switch statements, etc... but we didn't create the language or parser - they are a free library that we've plugged in (www.simkin.co.uk). This has worked out extremely well in our case, not only does the scripting language give the 'non-programmers' powerful tools for modifying the internals of the game, but it also lets us avoid recompiling the main engine as much as possible. the designers use worldcraft-style editors, placing entities that are tied to scripts for a wide range of features. everything from the skybox to cinematics, to Pawn/NPC behaviors is accessible without recompiling. sure the programmers might have to create the base script 'templates' for more complex scripts, but once the framework is there even complete newbies can customize these scripts to create their own behaviors. i couldn't see doing it any other way... mike w www.uber-geek.ca ----- Original Message ----- From: "Mickael Pointier" <mpo...@ed...> To: <gam...@li...> Sent: Monday, December 09, 2002 5:09 AM Subject: Re: [GD-General] Scripting > 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 > > > > > > > ------------------------------------------------------- > 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 > |
|
From: Brian H. <bri...@py...> - 2002-12-10 02:27:54
|
> this is how we're implementing things - we are using the > scripting language in the very way that brian and others have > been trying to avoid - as a complete language with the > requisite 'language constructs', switch statements, etc... Okay, to avoid muddling semantics, there's "the language" and there's "how it's used". It's entirely possible to use Python as an extension language call by an app, as an application language that calls an engine, or somewhere in between. I use Lua, ostensibly a scripting language, for data definitions. I wouldn't call it a scripting language in my case though. My instinct is that a scripting language as an "extension" (vs. "as data") seems ill advised at times, because you kind of have responsibilities that are mixed and often poorly defined. Using it as your primary application language means it's no longer "scripting", it's just the language you happen to be developing in and you're now calling into a separate native engine for system specific tasks. That seems completely reasonable if you feel the language itself is much more productive than C or C++ or whatever. Brian |
|
From: mike w. <mi...@ub...> - 2002-12-10 03:52:49
|
> My instinct is that a scripting language as an "extension" (vs. "as > data") seems ill advised at times, because you kind of have > responsibilities that are mixed and often poorly defined. Using it as > your primary application language means it's no longer "scripting", it's > just the language you happen to be developing in and you're now calling > into a separate native engine for system specific tasks. That seems > completely reasonable if you feel the language itself is much more > productive than C or C++ or whatever. good point, didn't see the difference initially. the way things have worked generally is that they start out as simple 'entities' (which are simple structs that have custom pragmas that the editor recognizes, providing public and private data for this particular entity (private data is used by the game engine on runtime, public is exposed to the level designer as the entities properties) that the designer can drop into their levels (lights, etc) and if the complexity of the feature becomes too unwieldy to edit via entities (as adding many of a similar entity can become), then that functionality is moved into scripting. for example, the players in-game actions are currently read in via an ini file - there are basic 'set' actions that the player can do, essentially a reference to an animation & that's about it. this is being updated to provide links to scripts (or functions within one) that will allow for more complicated actions (all custom-created by the designer without needing to recompile the engine) such as special moves, animated camera motions during specific in-game actions (pull off a special finishing move & trigger a flyby camera sequence), etc... of course, certain features are scriptable by default as well, and anything simpler is left as entities. the combinations seems to work well & provides an extremely good range of possiblities for the designer. cheers, mike w www.uber-geek.ca |
|
From: Jamie F. <ja...@qu...> - 2002-12-10 13:30:12
|
i think one key point that hasn't been touched on (enough? :) yet is that the scripting language (whether data definition, a full language, or whatever) should be appropriate to the people who will use it. some designers can think like a coder. some can't. similarly with artists. if you pitch the scripting at the appropriate level, it will work great. this is my main complaint with generic scripting systems: they've been designed at a particular level of complexity, and that simply can't be appropriate for every user. jamie -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of mike wuetherick Sent: 10 December 2002 03:55 To: gam...@li... Subject: Re: [GD-General] Scripting > My instinct is that a scripting language as an "extension" (vs. "as > data") seems ill advised at times, because you kind of have > responsibilities that are mixed and often poorly defined. Using it as > your primary application language means it's no longer "scripting", it's > just the language you happen to be developing in and you're now calling > into a separate native engine for system specific tasks. That seems > completely reasonable if you feel the language itself is much more > productive than C or C++ or whatever. good point, didn't see the difference initially. the way things have worked generally is that they start out as simple 'entities' (which are simple structs that have custom pragmas that the editor recognizes, providing public and private data for this particular entity (private data is used by the game engine on runtime, public is exposed to the level designer as the entities properties) that the designer can drop into their levels (lights, etc) and if the complexity of the feature becomes too unwieldy to edit via entities (as adding many of a similar entity can become), then that functionality is moved into scripting. for example, the players in-game actions are currently read in via an ini file - there are basic 'set' actions that the player can do, essentially a reference to an animation & that's about it. this is being updated to provide links to scripts (or functions within one) that will allow for more complicated actions (all custom-created by the designer without needing to recompile the engine) such as special moves, animated camera motions during specific in-game actions (pull off a special finishing move & trigger a flyby camera sequence), etc... of course, certain features are scriptable by default as well, and anything simpler is left as entities. the combinations seems to work well & provides an extremely good range of possiblities for the designer. cheers, mike w www.uber-geek.ca ------------------------------------------------------- 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 |
|
From: Awen L. <ali...@ed...> - 2002-12-10 14:56:50
|
One Point for Jamie. Further thought: the (scripting) language complexity may have some ugly impacts on the overall (potential) game scripting complexity. Subtle, but that's probably the reason why all the script engine i knew were dedicated to one project and forgotten for the next: appropriate for its purpose (serving The Game) and its users. 2 good reasons for dedicating code. Awen -----Message d'origine----- De : gam...@li... [mailto:gam...@li...]De la part de Jamie Fowlston Envoyé : mardi 10 décembre 2002 14:31 À : gam...@li... Objet : RE: [GD-General] Scripting i think one key point that hasn't been touched on (enough? :) yet is that the scripting language (whether data definition, a full language, or whatever) should be appropriate to the people who will use it. some designers can think like a coder. some can't. similarly with artists. if you pitch the scripting at the appropriate level, it will work great. this is my main complaint with generic scripting systems: they've been designed at a particular level of complexity, and that simply can't be appropriate for every user. jamie -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of mike wuetherick Sent: 10 December 2002 03:55 To: gam...@li... Subject: Re: [GD-General] Scripting > My instinct is that a scripting language as an "extension" (vs. "as > data") seems ill advised at times, because you kind of have > responsibilities that are mixed and often poorly defined. Using it as > your primary application language means it's no longer "scripting", it's > just the language you happen to be developing in and you're now calling > into a separate native engine for system specific tasks. That seems > completely reasonable if you feel the language itself is much more > productive than C or C++ or whatever. good point, didn't see the difference initially. the way things have worked generally is that they start out as simple 'entities' (which are simple structs that have custom pragmas that the editor recognizes, providing public and private data for this particular entity (private data is used by the game engine on runtime, public is exposed to the level designer as the entities properties) that the designer can drop into their levels (lights, etc) and if the complexity of the feature becomes too unwieldy to edit via entities (as adding many of a similar entity can become), then that functionality is moved into scripting. for example, the players in-game actions are currently read in via an ini file - there are basic 'set' actions that the player can do, essentially a reference to an animation & that's about it. this is being updated to provide links to scripts (or functions within one) that will allow for more complicated actions (all custom-created by the designer without needing to recompile the engine) such as special moves, animated camera motions during specific in-game actions (pull off a special finishing move & trigger a flyby camera sequence), etc... of course, certain features are scriptable by default as well, and anything simpler is left as entities. the combinations seems to work well & provides an extremely good range of possiblities for the designer. cheers, mike w www.uber-geek.ca ------------------------------------------------------- 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 ------------------------------------------------------- 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 |
|
From: mike w. <mi...@ub...> - 2002-12-11 06:00:41
|
absolutely. we've (somewhat/maybe/hopefully) managed to isolate the scripting side of things with the workflow in our engine by providing the 'entities' as i described below for the 'artists' on the team - even artists can hopefully understand placing lights, effects, etc as entities in the world, most 3d programs have similar concepts for placing lights & behaviors... this way the scripts are something that the artist simply needs to 'attach' to the entity as opposed to code from scratch. the 'non-programming designer-type' might never even need to see the scripts, they just know that adding a pawn to their level & attaching the 'badguy1.s' script, they get the desired result after recompiling their level (which if the designer is only compiling the entities only takes seconds usually). many of the core scripts start out being written by the 'programmer-types' on the team - they are usually testing new features/functions that have been implemented, as well as providing 'examples' for the rest of the designers to modify or use as a starting point for their own custom implementations. the beauty of it is that creating or modifying scripts doesn't actually need the attention of a 'C++' programmer, anyone that has done basic programming can modify or extend the 'base' scripts that the programmers have provided. this saves us from having programmers create the cinematics scripts or in-game NPC scripts - in other words doing jobs that should be left to the designers & artists. someone asked if anyone has created a main engine core that doesn't need to be modified or recompiled and is fully scripted for all gameplay code - this is basically what we have done. i think this is a decision that should be made for several reasons, one of which is details in the 'Big Orange Book' (game architecture & design) about how each department of your project team should be responsible to the other almost as they would external clients. meaning that the programmers provide documentation for their releases, provide reasonable examples & samples of how to implement the various features. in turn the designers provide detailed 'use cases' that help the programmers implement the various features. cycle ad nauseum. instead of being teams that 'work against each other' as programmers & artists seem to naturally, you create defined boundaries & expectations for your work. the programmers work should not be affected by the designers, and vice versa, yet allowing for concrete lines of communication... (who said that everything ends up being about management? ;) cheers, mike w www.uber-geek.ca ----- Original Message ----- From: "Jamie Fowlston" <ja...@qu...> To: <gam...@li...> Sent: Tuesday, December 10, 2002 5:30 AM Subject: RE: [GD-General] Scripting > i think one key point that hasn't been touched on (enough? :) yet is that > the scripting language (whether data definition, a full language, or > whatever) should be appropriate to the people who will use it. > > some designers can think like a coder. some can't. similarly with artists. > if you pitch the scripting at the appropriate level, it will work great. > this is my main complaint with generic scripting systems: they've been > designed at a particular level of complexity, and that simply can't be > appropriate for every user. > > jamie > > > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...]On Behalf Of > mike wuetherick > Sent: 10 December 2002 03:55 > To: gam...@li... > Subject: Re: [GD-General] Scripting > > > > My instinct is that a scripting language as an "extension" (vs. "as > > data") seems ill advised at times, because you kind of have > > responsibilities that are mixed and often poorly defined. Using it as > > your primary application language means it's no longer "scripting", it's > > just the language you happen to be developing in and you're now calling > > into a separate native engine for system specific tasks. That seems > > completely reasonable if you feel the language itself is much more > > productive than C or C++ or whatever. > > good point, didn't see the difference initially. > > the way things have worked generally is that they start out as simple > 'entities' (which are simple structs that have custom pragmas that the > editor recognizes, providing public and private data for this particular > entity (private data is used by the game engine on runtime, public is > exposed to the level designer as the entities properties) that the designer > can drop into their levels (lights, etc) and if the complexity of the > feature becomes too unwieldy to edit via entities (as adding many of a > similar entity can become), then that functionality is moved into scripting. > > for example, the players in-game actions are currently read in via an ini > file - there are basic 'set' actions that the player can do, essentially a > reference to an animation & that's about it. this is being updated to > provide links to scripts (or functions within one) that will allow for more > complicated actions (all custom-created by the designer without needing to > recompile the engine) such as special moves, animated camera motions during > specific in-game actions (pull off a special finishing move & trigger a > flyby camera sequence), etc... > > of course, certain features are scriptable by default as well, and anything > simpler is left as entities. the combinations seems to work well & provides > an extremely good range of possiblities for the designer. > > cheers, > > mike w > www.uber-geek.ca > > > > ------------------------------------------------------- > 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 > > > > ------------------------------------------------------- > 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 > |
|
From: Kent Q. <ken...@co...> - 2002-12-06 16:33:43
|
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
|
|
From: Brian H. <bri...@py...> - 2002-12-06 20:23:27
|
> 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 |
Thanks for helping keep SourceForge clean.
X