gamedevlists-general — List for discussing general game development issues

Re: [GD-General] Scripting Systems

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

On Jan 29, 2004 at 12:18 -0500, Brian Hook wrote:
> > in gamedev. It is cool to use a very flexible language for small
> > stuff like scripting parts of level.
> 
> But you'll have the same problems.  Language syntax errors, e.g.
> forgetting a "do" or "end", can be caught using the luac compiler, but
> semantic syntax bugs, e.g. "nname" instead of "name", won't be caught.
> 
> So if you script just triggers or just scripted sequences, you can
> still have a problem with errors.  Sure, the problem is minimized, but
> it still exists.

Yes indeed.  The JavaScript 2.0 spec apparently adds optional static
type checking.  I think JavaScript has somewhat more practical syntax
and class semantics, compared to Lua, as well.  I've never tried to
embed a JavaScript interpreter though.

-- 
Thatcher Ulrich
http://tulrich.com

Re: [GD-General] Scripting Systems

[gekido <mi...@ge...>]

alot of our beginning designers also have problems with case sensitivity 
with our script language, again something that could be called a 'bug'.

similar situation, we've had to just browbeat the windows users into 
acknowledging that there are differences between 'Name' and 'name' in 
the rest of the computing world ;}

cheers
mike w
www.gekidodesigns.com

Brian Hook wrote:

>>in gamedev. It is cool to use a very flexible language for small
>>stuff like scripting parts of level.
> 
> 
> But you'll have the same problems.  Language syntax errors, e.g. 
> forgetting a "do" or "end", can be caught using the luac compiler, but 
> semantic syntax bugs, e.g. "nname" instead of "name", won't be caught.
> 
> So if you script just triggers or just scripted sequences, you can 
> still have a problem with errors.  Sure, the problem is minimized, but 
> it still exists.
> 
> Brian
> 
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7
> 
> 

Re: [GD-General] Scripting Systems

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

> in gamedev. It is cool to use a very flexible language for small
> stuff like scripting parts of level.

But you'll have the same problems.  Language syntax errors, e.g. 
forgetting a "do" or "end", can be caught using the luac compiler, but 
semantic syntax bugs, e.g. "nname" instead of "name", won't be caught.

So if you script just triggers or just scripted sequences, you can 
still have a problem with errors.  Sure, the problem is minimized, but 
it still exists.

Brian

Re: [GD-General] NAT Negotiation

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

Don't mean to resurrect an old thread, but here's a pretty good 
article on the subject.  Jon Watte may have posted the same link in 
the original thread on gd-algorithms, but I don't have that post handy 
to check:

http://www.pdos.lcs.mit.edu/~baford/nat/

Re: [GD-General] Scripting Systems

[gekido <mi...@ge...>]

the developers of simkin (the language that we have embedded) have 
created a command-line debugger for this type of thing, but i haven't 
been able to afford the license he wants yet for us to integrate this 
into our development environment.

with that said, i definitely agree that these types of issues with our 
game engine, although implementing a custom script editor has helped 
simplify things.

i've recently created a custom build of SCITE (www.scintilla.org), which 
if you haven't checked it out is probably the slickest editor i've ever 
used (and open source).

it took me all of an hour to create an entire api for our engine (with 
all the game functions, parameters etc) and we now have autocomplete for 
functions (among many other things), which helps eliminate some of the 
semantic issues that arise from custom scripting...

i believe it has lua support straight out of the box as well.

regarding debugging, i've never really considered implementing an http 
server for debugging, but now that you say it, it sounds like an 
interesting idea...

the half-life engine has their 'console' and 'rconsole' access tools for 
this kind of thing, implementing a 'remote console' would help for some 
debugging, but for the most part, we simply output information to the 
on-screen console and use that for debugging...

regarding the 'getting into the game', i agree that this is a pain as 
well, having to play 5 minutes through a level to test one feature is a 
major pain...i haven't figured out a solution for that one yet ;}

cheers
mike w
www.realityfactory.ca



Brett Bibby wrote:

> You know Brian, you got me all excited when I read your note because it started off like you POSH note so I thought you had a nifty solution to all of this :)
> 
> I sympathize as I am also currently implementing Lua. I similar problems as you and we are trying to figure out how to fix them or find another scripting language as well.
> 
> 1. We need some sort of Lint for Lua. This is hard to implement because you can dynamically create table members. It's advertised as a feature but when I type "nname" instead of "name" it's an error not a new member. How do other languages get around this? I'm guessing they don't either, but isn't there a better way to handle this? (I know I can trap the __index method but I'm talking about finding errors before runtime)
> 
> 2. Debugging is a pain, although we have designed a solution. We are implementing a small, simple http protocol and hooking a script debugger to it. The game communicates to the debugger via http so we can debug PS2, GCN and PC scripts. You can even point a web browser at the IP and get a list of vars and their values and change them via a form (slow but just in case host debugging not available).  But building the debugger under Lua isn't nearly as nice as it could be. What are other scripting language debuggers like?
> 
> 3. Incremental builds. We have converted our scripts to game objects (not to be confused with OO object programming). Each function is therefore unique and can be compiled and re-uploaded to the VM on-the-fly and so you can effectively pause the game in the debugger and replace a value, table or funciton anytime. This can make for some interesting bugs in it's own right, but without it you end up having to play the game for minutes just to get back to a place where you want to test something. Sometimes you can't even recreate the exact situation easily. This is only a partial solution, but I have heard others say Lua is especially difficult to save the game state. How do other languages used in games save thier game states?
> 
> Brett
> 
> ----- Original Message ----- 
> From: "Brian Hook" <ho...@py...>
> To: <gam...@li...>
> Sent: Thursday, January 29, 2004 6:07 AM
> Subject: Re: [GD-General] Scripting Systems
> 
> 
> 
>>So I finally am getting around to using Lua "in anger" (i.e. in real 
>>honest to God code), with Nick Trout as my personal coach to see me 
>>through the (one step better than horrible) documentation.
>>
>>And what I've learned so far is that scripting, while cool in theory, 
>>is really a pain in the ass in a lot of practical ways, most of it 
>>having to do with type checking and basic things of that ilk.
>>
>>My most common programming errors are simply mechanical:
>>
>>1.  Accidentally typing object:method() instead of object.method() or 
>>vice versa
>>
>>2.  Forgetting that table.foo() isn't called ON the table but WITH the 
>>table, i.e. it's table.insert( t, ... ) not t:insert( t )/t.insert()
>>
>>3.  Typographical/memorization errors:
>>
>>function object.foo( x, y, z )
>>....
>>end
>>
>>o.foo( y, x, z ) -- oops!
>>
>>or:
>>
>>function client.create()
>>local c = { client_name = "Default" }
>>return c
>>end
>>
>>c = client.create()
>>c.name = "Brian Hook" -- oops!
>>
>>or
>>
>>-- oops, forgot the 'then'!
>>if c.client_name == "Brian Hook"
>>   c:doSomething()
>>end
>>
>>Finding these (often trivial) problems requires me to load and run my 
>>scripts, and in some cases I have to get into pretty entrenched areas 
>>of my code (e.g. AI that responds to being attacked, etc.).  It really 
>>sucks to load up a game, spend 5 minutes getting a particular 
>>condition to occur, then having things barf/not work because you typed 
>>"nname" instead of "name"...
>>
>>This is all embedded as well, so using a development environment 
>>doesn't seem feasible (but I haven't looked into them enough to say).  
>>Also, because of the reliance on calls back into my main kernel, I 
>>can't exactly make independent unit tests that run with the command 
>>line interpreter.
>>
>>Do other languages handle this any better?  JavaScript suffers from 
>>the same problems since it is also prototype-based (a la SELF et. 
>>al.).  
>>
>>Brian
>>
>>
>>
>>
>>-------------------------------------------------------
>>The SF.Net email is sponsored by EclipseCon 2004
>>Premiere Conference on Open Tools Development and Integration
>>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>>http://www.eclipsecon.org/osdn
>>_______________________________________________
>>Gamedevlists-general mailing list
>>Gam...@li...
>>https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>>Archives:
>>http://sourceforge.net/mailarchive/forum.php?forum_idU7
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7
> 
> 

Re: [GD-General] Scripting Systems

[Alen L. <ale...@cr...>]

>It really
>sucks to load up a game, spend 5 minutes getting a particular
>condition to occur, then having things barf/not work because you typed
>"nname" instead of "name"...

IMHO, I'd say that dynamic typing is a bug, not a feature, at least in
gamedev. It is cool to use a very flexible language for small stuff like
scripting parts of level. But if you need to write menus or real entity AI,
I'd stick with something that can be statically checked. I believe someone
mentioned Ch already somewhere here. Though it might not be portable enough
for your needs. Perhaps even using lcc with your own interpreted bytecodes
would help. Hey, it's a proven method ;).

Just my 1kB,

Alen

Re: [GD-General] Scripting Systems

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

> 1. We need some sort of Lint for Lua. This is hard to implement
> because you can dynamically create table members. It's advertised
> as a feature but when I type "nname" instead of "name" it's an
> error not a new member. 

Right, but it doesn't know that.

> guessing they don't either, but isn't there a better way to handle
> this? (I know I can trap the __index method but I'm talking about
> finding errors before runtime)

Run-time is the only way to do it.  Lua is a dynamically typed 
language, and since it doesn't even comprehend the idea of user 
defined types, "type checking" is kind of a no-op.  

What we'd need is a preprocessor that uses a convention where any 
uninitialized element accessed out of a table constructor or 
declaration is definitely bad.

v =3D { x =3D 0, y =3D 0, z =3D 0 }
v.zz =3D 3 --<< BZZZT!

> 2. Debugging is a pain, although we have designed a solution. We
> are implementing a small, simple http protocol and hooking a script
> debugger to it. The game communicates to the debugger via http so
> we can debug PS2, GCN and PC scripts. 

That's either crafty or gross, I'm not sure yet. =3D)

> 3. Incremental builds. We have converted our scripts to game
> objects (not to be confused with OO object programming). Each
> function is therefore unique and can be compiled and re-uploaded to
> the VM on-the-fly and so you can effectively pause the game in the
> debugger and replace a value, table or funciton anytime.

That's exactly what we're doing as well.

> make for some interesting bugs in it's own right, but without it
> you end up having to play the game for minutes just to get back to
> a place where you want to test something. 

Yep.

Sounds like we're in the same boat but without a solution =3D|

Brian

Re: [GD-General] Scripting Systems

[Brett B. <res...@ga...>]

You know Brian, you got me all excited when I read your note because it =
started off like you POSH note so I thought you had a nifty solution to =
all of this :)

I sympathize as I am also currently implementing Lua. I similar problems =
as you and we are trying to figure out how to fix them or find another =
scripting language as well.

1. We need some sort of Lint for Lua. This is hard to implement because =
you can dynamically create table members. It's advertised as a feature =
but when I type "nname" instead of "name" it's an error not a new =
member. How do other languages get around this? I'm guessing they don't =
either, but isn't there a better way to handle this? (I know I can trap =
the __index method but I'm talking about finding errors before runtime)

2. Debugging is a pain, although we have designed a solution. We are =
implementing a small, simple http protocol and hooking a script debugger =
to it. The game communicates to the debugger via http so we can debug =
PS2, GCN and PC scripts. You can even point a web browser at the IP and =
get a list of vars and their values and change them via a form (slow but =
just in case host debugging not available).  But building the debugger =
under Lua isn't nearly as nice as it could be. What are other scripting =
language debuggers like?

3. Incremental builds. We have converted our scripts to game objects =
(not to be confused with OO object programming). Each function is =
therefore unique and can be compiled and re-uploaded to the VM =
on-the-fly and so you can effectively pause the game in the debugger and =
replace a value, table or funciton anytime. This can make for some =
interesting bugs in it's own right, but without it you end up having to =
play the game for minutes just to get back to a place where you want to =
test something. Sometimes you can't even recreate the exact situation =
easily. This is only a partial solution, but I have heard others say Lua =
is especially difficult to save the game state. How do other languages =
used in games save thier game states?

Brett

----- Original Message -----=20
From: "Brian Hook" <ho...@py...>
To: <gam...@li...>
Sent: Thursday, January 29, 2004 6:07 AM
Subject: Re: [GD-General] Scripting Systems


> So I finally am getting around to using Lua "in anger" (i.e. in real=20
> honest to God code), with Nick Trout as my personal coach to see me=20
> through the (one step better than horrible) documentation.
>=20
> And what I've learned so far is that scripting, while cool in theory,=20
> is really a pain in the ass in a lot of practical ways, most of it=20
> having to do with type checking and basic things of that ilk.
>=20
> My most common programming errors are simply mechanical:
>=20
> 1.  Accidentally typing object:method() instead of object.method() or=20
> vice versa
>=20
> 2.  Forgetting that table.foo() isn't called ON the table but WITH the =

> table, i.e. it's table.insert( t, ... ) not t:insert( t )/t.insert()
>=20
> 3.  Typographical/memorization errors:
>=20
> function object.foo( x, y, z )
> ....
> end
>=20
> o.foo( y, x, z ) -- oops!
>=20
> or:
>=20
> function client.create()
> local c =3D { client_name =3D "Default" }
> return c
> end
>=20
> c =3D client.create()
> c.name =3D "Brian Hook" -- oops!
>=20
> or
>=20
> -- oops, forgot the 'then'!
> if c.client_name =3D=3D "Brian Hook"
>    c:doSomething()
> end
>=20
> Finding these (often trivial) problems requires me to load and run my=20
> scripts, and in some cases I have to get into pretty entrenched areas=20
> of my code (e.g. AI that responds to being attacked, etc.).  It really =

> sucks to load up a game, spend 5 minutes getting a particular=20
> condition to occur, then having things barf/not work because you typed =

> "nname" instead of "name"...
>=20
> This is all embedded as well, so using a development environment=20
> doesn't seem feasible (but I haven't looked into them enough to say).  =

> Also, because of the reliance on calls back into my main kernel, I=20
> can't exactly make independent unit tests that run with the command=20
> line interpreter.
>=20
> Do other languages handle this any better?  JavaScript suffers from=20
> the same problems since it is also prototype-based (a la SELF et.=20
> al.). =20
>=20
> Brian
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7

Re: [GD-General] Scripting Systems

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

So I finally am getting around to using Lua "in anger" (i.e. in real 
honest to God code), with Nick Trout as my personal coach to see me 
through the (one step better than horrible) documentation.

And what I've learned so far is that scripting, while cool in theory, 
is really a pain in the ass in a lot of practical ways, most of it 
having to do with type checking and basic things of that ilk.

My most common programming errors are simply mechanical:

1.  Accidentally typing object:method() instead of object.method() or 
vice versa

2.  Forgetting that table.foo() isn't called ON the table but WITH the 
table, i.e. it's table.insert( t, ... ) not t:insert( t )/t.insert()

3.  Typographical/memorization errors:

function object.foo( x, y, z )
....
end

o.foo( y, x, z ) -- oops!

or:

function client.create()
=09local c =3D { client_name =3D "Default" }
=09return c
end

c =3D client.create()
c.name =3D "Brian Hook" -- oops!

or

-- oops, forgot the 'then'!
if c.client_name =3D=3D "Brian Hook"
   c:doSomething()
end

Finding these (often trivial) problems requires me to load and run my 
scripts, and in some cases I have to get into pretty entrenched areas 
of my code (e.g. AI that responds to being attacked, etc.).  It really 
sucks to load up a game, spend 5 minutes getting a particular 
condition to occur, then having things barf/not work because you typed 
"nname" instead of "name"...

This is all embedded as well, so using a development environment 
doesn't seem feasible (but I haven't looked into them enough to say).  
Also, because of the reliance on calls back into my main kernel, I 
can't exactly make independent unit tests that run with the command 
line interpreter.

Do other languages handle this any better?  JavaScript suffers from 
the same problems since it is also prototype-based (a la SELF et. 
al.).  

Brian

[GD-General] RE: scripting GUI apps for better workflow

[David H. <Da...@su...>]

-] Flash MX doesn't seem to have any programmability built into it.  I
-] know there are macro recorders, and I've heard some people talk about
-] scripting with COM, but that is all pretty new to me, so I'd
-] appreciate any clues about whether/how to try this.

I seem to remember that Flash MX has the ability to embed actual flash
movies as GUI elements.  There's an API available to you in actionscript
that can call functions exported by MX.  You might be able to use
actionscript to automate some of your workflow.  You could even possibly
interact with perforce using the sockets interface or the web interface from
a flash movie.

Dave Huseby
da...@su...

[GD-General] scripting GUI apps for better workflow

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

I'm looking for some clues on ways to automate some simple tasks in a
GUI app.  Specifially, when working on a .fla file in Flash MX, I want
to be able to do one click/keystroke, and automatically:

* do "p4 edit xxx.fla" on the .fla file (i.e. the source document file)

* do "p4 edit xxx.swf" on the target .swf file (i.e. the exported file)

* have Flash MX do the export to a certain directory (which normally
  involves a half-dozen clicks/keystrokes)

Flash MX doesn't seem to have any programmability built into it.  I
know there are macro recorders, and I've heard some people talk about
scripting with COM, but that is all pretty new to me, so I'd
appreciate any clues about whether/how to try this.

-- 
Thatcher Ulrich
http://tulrich.com

Re: [GD-General] Scripting Systems

[Eero P. <epa...@ko...>]

Alen Ladavac wrote:

> From: "Eero Pajarre" <epa...@ko...>
> 
>>For me GC has not been the main problem speed wise, and I do trigger
>>GC each frame, so that I can minimize "real time" problems with it.
> 
> 
> Interesting idea. It really must smooth the performance. Though I would
> expect it to be slooow. It certainly does trash the cache big time, doesn't
> it?
> 

It might be just me not noticing it, but as I said it has not
been a problem yet. I certainly have been "garbage aware" in my
code, so I don't produce that much of it. Also my data structures
at lua side are not that huge. The main objects are on C++ side
and just referred from the Lua side, although I typically
still have also a Lua table for each main object.

> 
>>Profilers show the Lua name lookup as a spike in the curves, this might
> 
> That's same thing that I heard before, and one of main reasons why we didn't
> choose Lua for in-game scripting. I just couldn't find anyone who could
> reaffirm that.
> 
> 
>>Local variables them self AFAIK do not need the name
>>lookup.
> 
> That is good. However, any member variable/function access would do a name
> lookup, right?
> 

Yes, although the access is based on hashed arrays etc, and is
quick.

> 
> Out of curiosity, does the interpreter have a function table for
> instructions? If yes, then I don't see how so much misprediction could
> happen. :/
> 

The main loop is actually switch based, but I think that even
with function table the main switching point would predict
rather badly. Also there is some unpacking of parameters in
the virtual machine, which also doesn't branch predict too well.


		Eero

Re: [GD-General] Scripting Systems

[Alen L. <ale...@cr...>]

From: "Eero Pajarre" <epa...@ko...>
> For me GC has not been the main problem speed wise, and I do trigger
> GC each frame, so that I can minimize "real time" problems with it.

Interesting idea. It really must smooth the performance. Though I would
expect it to be slooow. It certainly does trash the cache big time, doesn't
it?

> Profilers show the Lua name lookup as a spike in the curves, this might
That's same thing that I heard before, and one of main reasons why we didn't
choose Lua for in-game scripting. I just couldn't find anyone who could
reaffirm that.

> Local variables them self AFAIK do not need the name
> lookup.
That is good. However, any member variable/function access would do a name
lookup, right?

> The main CPU consumption spike still exists in the Lua virtual machine,
> executing the "byte code" interpreter seems to be quite unlucky exercise
> for the branch prediction logic in the CPU, and mispredicted branches
> hurt a lot on P4/Athlon.
Out of curiosity, does the interpreter have a function table for
instructions? If yes, then I don't see how so much misprediction could
happen. :/

Alen

Re: [GD-General] Scripting Systems

[Eero P. <epa...@ko...>]

Alen Ladavac wrote:

> 
> 
>>Lua is fast.  It's small.  It's trivial to embed.
> 
> 
> 
> Do you think that GC is main speed problem? How about name lookups? Does
> that show on your profile?
> 


For me GC has not been the main problem speed wise, and I do trigger
GC each frame, so that I can minimize "real time" problems with it.

Profilers show the Lua name lookup as a spike in the curves, this might
be partially because the VC++ generated code seems to just hit some kind
of cache line/branch prediction limitation at least on Athlon, when
compiling the Lua hashing function. I suspect that I see the name lookup,
not so much as plain variable lookup, but because it is used when fetching
array elements by name. Local variables them self AFAIK do not need the name
lookup.

The main CPU consumption spike still exists in the Lua virtual machine,
executing the "byte code" interpreter seems to be quite unlucky exercise
for the branch prediction logic in the CPU, and mispredicted branches
hurt a lot on P4/Athlon.


		Eero

Re: [email] Re: [GD-General] Scripting Systems

[Alen L. <ale...@cr...>]

Well, running it on one stack worked ok for us during last several years,
and lot of other people use that. However, I cannot claim which technique is
most often. I believe that most people do cooperative instead of preemptive
for scripts, and general multithreading is avoided like a plague, unless
really necessary (loading in the background, etc.).

Just my 0.02$.

Alen


----- Original Message -----
From: "Dan Thompson" <da...@ar...>
To: <gam...@li...>
Sent: Wednesday, January 21, 2004 20:01
Subject: Re: [email] Re: [GD-General] Scripting Systems


> All engine calls are atomic, so after each call we try to guarantee the
> validity of an object.
>
> Of course, there could be situations where this is not possible, so
perhaps
> the premtive isn't good. However, I couldn't think of any other way to
> prevent scripts from being able to eat all the processor.
>
> The only break we get is since its user level threading, we control
exeactly
> when the preemption occurs.
>
> Do people often just make one script stack, and have multiple files
running
> in it? Or one stack per script?
>
> -Dan
>
> ----- Original Message -----
> From: "Alen Ladavac" <ale...@cr...>
> To: <gam...@li...>
> Sent: Wednesday, January 21, 2004 4:21 AM
> Subject: [email] Re: [GD-General] Scripting Systems
>
>
> >
> > ----- Original Message -----
> > From: "Dan Thompson" <da...@ar...>
> > > This method is vs. just running a script and creating the stack when
the
> > > message comes in. This seemed far too expensive, as you could be
> creating
> > > script stacks all over the place, and it also runs into the problem
> where
> > > the game locks because the scripts are being run in the same thread.
> >
> > AFAIK, one usual method is to make sure that all "yields" are always on
> the
> > bottom of the stack so you don't need to keep and store stack for each
> > script. This of course rules out real preemptiveness. But... how do you
> > handle that anyway? Don't you ever get problems with one script being
> > interrupted in the middle of modifying some object and another one
> accessing
> > that same object in a half-valid state? And having scripts running on a
> > different thread? Do you use some synchronizations when accessing other
> > subsystems from scripts?
> >
> > Alen
> >
> >
> >
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004
> > Premiere Conference on Open Tools Development and Integration
> > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> > http://www.eclipsecon.org/osdn
> > _______________________________________________
> > Gamedevlists-general mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=557
> >
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>

Re: [GD-General] Scripting Systems

[Alen L. <ale...@cr...>]

>I hate people that bitch about syntax, but hey, I'm not particularly
>fond of Lua's syntax.  It's just not very readable IMO because there's
>been so much syntactic sugar.  That's a subjective thing.

Seconded. Though it's not syntactic sugar that bothers me most. I'd prefer
to have // comments and {} blocks. I mean, we all use C on daily basis, why
make things complicated? Lua syntax makes C syntax hiliting editors look
stupid.

> Lua is fast.  It's small.  It's trivial to embed.

Yup, it is very slick and nice. Though I didn't find ability to store state
(for save games), what can be quite a brick.

> The GC issue is going to be addressed in 5.1 hopefully, which should
>ship before I'm done with my current project.

Do you think that GC is main speed problem? How about name lookups? Does
that show on your profile?

Alen

Re: [email] Re: [GD-General] Scripting Systems

[Dan T. <da...@ar...>]

All engine calls are atomic, so after each call we try to guarantee the
validity of an object.

Of course, there could be situations where this is not possible, so perhaps
the premtive isn't good. However, I couldn't think of any other way to
prevent scripts from being able to eat all the processor.

The only break we get is since its user level threading, we control exeactly
when the preemption occurs.

Do people often just make one script stack, and have multiple files running
in it? Or one stack per script?

-Dan

----- Original Message ----- 
From: "Alen Ladavac" <ale...@cr...>
To: <gam...@li...>
Sent: Wednesday, January 21, 2004 4:21 AM
Subject: [email] Re: [GD-General] Scripting Systems


>
> ----- Original Message -----
> From: "Dan Thompson" <da...@ar...>
> > This method is vs. just running a script and creating the stack when the
> > message comes in. This seemed far too expensive, as you could be
creating
> > script stacks all over the place, and it also runs into the problem
where
> > the game locks because the scripts are being run in the same thread.
>
> AFAIK, one usual method is to make sure that all "yields" are always on
the
> bottom of the stack so you don't need to keep and store stack for each
> script. This of course rules out real preemptiveness. But... how do you
> handle that anyway? Don't you ever get problems with one script being
> interrupted in the middle of modifying some object and another one
accessing
> that same object in a half-valid state? And having scripts running on a
> different thread? Do you use some synchronizations when accessing other
> subsystems from scripts?
>
> Alen
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> 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] OS split for UT2003

[George W. <ge...@ap...>]

On Tue, 20 Jan 2004 16:00:10 -0500, "Daniel Vogel" <vo...@ep...>
wrote:
> Sorry, won't post absolute numbers.

I just wanted to pipe in here and thank Daniel for sharing his info. Now
back to splitting hairs. ;-)

-- 
Enjoy,
George Warner,
Schizophrenic Optimization Scientists
Apple Developer Technical Support (DTS)

Re: [GD-General] Scripting Systems

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

On Wed, 21 Jan 2004 12:24:31 -0000, Alen Ladavac wrote:
> Don't know much about Ruby

Ruby is cool.  Ruby is intensely slow.  Ruby is not very easy to embed 
(at least, the documentation is very sparse, and the stuff I've seen 
isn't particularly encouraging).  Ruby -> C/C++ is much easier than 
C/C++ -> Ruby.

> but I'd like to hear what you have to say against Lua.

I hate people that bitch about syntax, but hey, I'm not particularly 
fond of Lua's syntax.  It's just not very readable IMO because there's 
been so much syntactic sugar.  That's a subjective thing.

Lack of integers really irks me, but I'm getting over that complaint 
since the main place I wanted integers were bit masks, and I'm finally 
accepting that a property-per-bit isn't as devastating a problem as 
I'd like to think.

Lua is fast.  It's small.  It's trivial to embed.  But it doesn't have 
near the amount of features of Ruby with respect to high level 
expressiveness, but this may be why it's 10x faster on some of the 
GLCS benchmarks =3D)

The GC issue is going to be addressed in 5.1 hopefully, which should 
ship before I'm done with my current project.

Brian

RE: [GD-General] OS split for UT2003

[Gareth L. <gl...@cl...>]

Can you give me a ballpark figure on 'tiny' please ? :) Do you mean 1% or
much lower than that ? 

> -----Original Message-----
> From: Daniel Vogel [mailto:vo...@ep...]
> Sent: 21 January 2004 14:46
> To: gam...@li...
> Subject: RE: [GD-General] OS split for UT2003
> 
> 
> > [2] Daniel could you give us the stats on that. I understand 
> > you don't want to give out numbers, but could you please 
> > give us a 'number of servers vs number of clients' ratio ? 
> 
> It's a tiny fraction.
> 
> -- Daniel, Epic Games Inc.
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> 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] OS split for UT2003

[Daniel V. <vo...@ep...>]

> [2] Daniel could you give us the stats on that. I understand 
> you don't want to give out numbers, but could you please 
> give us a 'number of servers vs number of clients' ratio ? 

It's a tiny fraction.

-- Daniel, Epic Games Inc.

Re: [GD-General] Scripting Systems

[Alen L. <ale...@cr...>]

----- Original Message -----
From: "Dan Thompson" <da...@ar...>
> This method is vs. just running a script and creating the stack when the
> message comes in. This seemed far too expensive, as you could be creating
> script stacks all over the place, and it also runs into the problem where
> the game locks because the scripts are being run in the same thread.

AFAIK, one usual method is to make sure that all "yields" are always on the
bottom of the stack so you don't need to keep and store stack for each
script. This of course rules out real preemptiveness. But... how do you
handle that anyway? Don't you ever get problems with one script being
interrupted in the middle of modifying some object and another one accessing
that same object in a half-valid state? And having scripts running on a
different thread? Do you use some synchronizations when accessing other
subsystems from scripts?

Alen

Re: [GD-General] Scripting Systems

[Alen L. <ale...@cr...>]

Don't know much about Ruby, but I'd like to hear what you have to say
against Lua. :) Just to make my standpoint clear - I like using Lua for
build scripts and some stuff like that, but not for game scripting. I
believe that it is not well suited for in-game use, due to "by-name" lookups
in interpreter and due to use of garbage collector. Now I'd like to know if
you have some more arguments in this direction.

Alen

----- Original Message -----
From: "Brian Hook" <ho...@py...>
To: <gam...@li...>
Sent: Wednesday, January 21, 2004 03:13
Subject: Re: [GD-General] Scripting Systems


> a game. Note that I'm *not* talking about what language to use

Ah, but I will -- anyone using Ruby successfully?  It doesn't seem to
be particularly well documented for embedding, but it has a host of
language features that I dig, and Lua and I have a love/hate
relationship at times.

Brian




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7

Re: [GD-General] OS split for UT2003

[toni <to...@4d...>]

Daniel Vogel wrote:

>Take the data for what it's worth though there are two wrong statements in
>your post.
>
Yeah, sorry i was a bit asleep when i read/replied your mail :)

>>I mean if you don't have the number of players/connections 
>>    
>>
>
>Sorry, won't post absolute numbers.
>  
>
I didn't mean you have to post absolute numbers, i only meant these 
stats would be more useful with that numbers, but they are still useful 
without them.

Toni
Lead Designer/Programmer
insideo.com

RE: [GD-General] OS split for UT2003

[Gareth L. <gl...@cl...>]

(Mod, sorry I forgot to change my email address, please refuse the previous
post, I have reregistered)

I think you read the table backwards, what the table shows (to me) are

On the server side
- Windows NT is gone.
- There has been a major shift from WinNT and Linux over to WindowsXP. 9x
and 2k hardly changed. I doubt people upgraded from NT or linux to 2k, I
would more expect XP to be the reason.
- It's interesting that Windows Server 2k3 doesn't show up. I'm not sure
what the reasons for that are.

On the client side
- Linux and Mac are not really viable targets. The large figures that linux
servers have imply to me one of the following options
- 1) People are running linux servers and then playing on a Wintel box.
- 2) (more likely) about 1% of the players also run servers (assuming a
guestimate of 50% of linux players running a server)[2]

[1]This is not to say that people should or should not target them in the
games they make (that is an opinion, I'm just deducing information from the
stats.

[2] Daniel could you give us the stats on that. I understand you don't want
to give out numbers, but could you please give us a 'number of servers vs
number of clients' ratio ? 

Again Daniel, thanks for the information, it is extremly interesting. If
only some online game that targeted all 3 consoles existed that we could get
similar numbers out of :)

Just my 2c
_____________________________________________________
Programmer, Sudeki - http://www.xbox.com/en-US/Sudeki
Gareth Lewin       - http://www.garethlewin.com

"Try or Try not, there is no Do" 


> -----Original Message-----
> From: Toni [mailto:to...@4d...]
> Sent: 20 January 2004 20:56
> 
> Well, even when data is nice to see (i like that linux growth 
> in servers 
> and clients and well, i see the XP shifting too) I think data is not 
> representative.
> I mean if you don't have the number of players/connections 
> whatever you 
> can't compare both data statistics, am i right?. I mean, i don't know 
> how successful UT2003 is but it could be easily biassed,  for example 
> because there are less people that plays UT2003 (i don't know 
> that, i've 
> never played ut2003) than in 2002 (that would explain, for 
> example the 
> linux growth, as there are less fps in linux than in windws).
> 
> Just my 2 cents
> 
> Toni
> Lead Designer/Programmer
> insideo.com