gamedevlists-consoles

RE: [GD-Consoles] question: Embedded scripting language on consol e

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

We've been using Python and SWIG for a while on all three consoles. =
It's
pretty good.


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

-----Original Message-----
From: Lagarde S=E9bastien [mailto:Lag...@wa...]
Sent: 17 February 2003 22:33
To: gam...@li...
Subject: [GD-Consoles] question: Embedded scripting language on console


Hello all,

I looking for some information on existing embedded scripting language =
on
console (ps2, gc).

My goal is to design some behavior with UML state diagram then =
generating
the code for the
scripting language. I have found that Java or python are appropriate
language (with rational rose , together soft etc...)
but after some research i have this result:

java is use in Vampire the masquarade base on embedded java language =
and
JNI. But no information
on other game (PC or console).
Is java interpreter (jvm) can be support on console because the lack of
ressource ?
(Nota: About vampire, a presentatoin of this script engine have been =
made in
GDC99 by Robert Huebner of Nihilistic but the slide are now =
unavailable, is
someone have it or can send a link, thanks)

python is use in many PC game , again i found only few console game =
base on
python scripting
but i think some use it.

I want use a popular existing language in order to each new team member =
are
quickly functionnal
so no proprietary language.

The lua language seem to be a good alternative for embeded scripting on
console (light an easy)
but there is no support for UML stuff.

I already know some web site on glue code for scripting language (SWIG) =
but=20
i think the major problem is beetween the virtual machine and the need =
of
ressource and on this point
few information is available.

In last is multithreading in scripting language (like java) can be =
emulate
on console
for a real-time game ?
Is there programmer that have already implement one of this language =
and can
give feedback ?
Thank a lot

Sorry for my english
Best regards.
----------------------------------
Lagarde S=E9bastien
junior programmer
Neko

RE: [GD-Consoles] question: Embedded scripting language on consol e

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

We tried that with StarTopia, and found that the designers have to learn the
basics of coding and syntax anyway. If you dress it up to look like English,
they'll try and use it like English. And that leads to all sorts of
misunderstandings. StarTopia's scripting language was pretty good, but
high-maintenance, and not as powerful as we'd have liked.

We now let ours use Python, but only with the really basic features of the
language, and a restricted view of the "world". This means we've got a
ready-made language, easily extendable, good debugging tools, etc. If a
complex function needs coding, one of the coders can do it (either in Python
or C according to choice). But more and more the gameplay _coders_ are
moving to Python anyway, because it's such a nice language to do
non-speed-critical gameplay coding in.

I suspect similar arguemnts apply to Java and Lua.

We chose Python because it's a lot higher-level than Lua, and has pretty
much every library you could ever want (want to read .ZIP files? Sure. XTML?
Certainly. Handy stuff like that). Java is out because we need it to run on
PS2, GC, XB, etc.


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: Mickael Pointier [mailto:mpo...@ed...]
> Sent: 18 February 2003 17:37
> To: gam...@li...
> Subject: Re: [GD-Consoles] question: Embedded scripting language on
> console
> 
> 
> Ron Hay wrote:
> > Has anyone on the list actually thought deeply about which scripting
> > language they choose?  If
> > so, care to share your thoughts?  We're in the middle of 
> choosing the
> > language, and Lua seems
> > to be our current top pick.  The team member that is in charge of
> > scripting is the type of person
> > that just likes to pick and go, so I'm worried that there may be a
> > better alternative out there...
> 
> Well, I would not like to use a generic language to make 
> in-game scripting
> language. Instead I would better make a dedicated small minimalistic
> language specially made for that particular game.
> 
> The reason is that I think that asking to designers to use 
> some generic
> language with non intuitive syntax (what are these ";" "{" 
> and "}" ???),
> very non expressive content, side effects... is not really a 
> good choice.
> 
> 
>     Mickael Pointier
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-consoles mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=553
> 

Re: [GD-Consoles] question: Embedded scripting language on console

[<Lag...@wa...>]

First, Thanx for all answer people send.

> We chose Python because it's a lot higher-level than Lua, and has pretty
> much every library you could ever want (want to read .ZIP files? Sure.
XTML?
> Certainly. Handy stuff like that). Java is out because we need it to run
on
> PS2, GC, XB, etc.
>

About the java question i have something:
Kaffe (www.kaffe.org) is an open source  JVM (garbage collector, native
library, multitasking)
with interpreter mode or jit which work on some processor like i386, powerPC
and mips.
It support jni interface too.

There are already an implementation for PS2 plateform, with few modification
(few weeks of work)
i think you can adapt this JVM for game cube and xbox. But i don't know if
it's viable in term of ressource and speed...

And with EmbeddedJava (java.sun.org) you can import only needed class
library for your JVM.

Other JVM are available like Japhar (www.japhar.org)...

I focus on java scripting because it's largely know with some great tools
(debugger, IDE...)
but python and lua are pretty good and they are my backup solution.

RE: [GD-Consoles] question: Embedded scripting language on console

[Andrew P. <aj...@eu...>]

Hi Tom,
	Can you tell us more of your experiences with using python on ps2/xbox/gc?
What problems have you had? What unexpected benefits did you get? What
worries do you have at the back of your mind? My feeling is that this was a
brave step to make at this time.
Regards,
Andrew


Dr Andrew Perella
Programming Manager
aj...@eu...

Eutechnyx Limited is a Deloitte & Touche Fast 50 and a Sunday Times Tech
Track 100 company.

Eutechnyx Limited
Metro Centre East Business Park
Gateshead
Tyne & Wear
NE11 9HU
UK
Phone: +44 (0) 191 460 60 60
Fax: +44 (0) 191 460 22 66
www.eutechnyx.com







_____________________________________________________________________
This e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. No communication sent by e-mail to or from Eutechnyx is intended to give rise to contractual or other legal liability, apart from liability which cannot be excluded under English law. 

This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre. 

www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322

RE: [GD-Consoles] question: Embedded scripting language on consol e

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

Normally our game objects just have the "brains" done in Python. Most of
them have low-level autonomic systems written in C ("keep walking toards
this point", "be bouncy and physics-y", "go to sleep", etc), and then the
script does the higher-level thinking - this is usually not done every
frame, it's done in an event queue style. So people walking around plot a
route of waypoints in Python (with raycast & A* assistance from C
libraries), and then feed the waypoint list to the autonomic
waypoint-follower. Then the script goes to sleep until it reaches a
waypoint, or there's something in the way (the autonomic system prods it
awake) or they get shot at or whatever.

But the script can render stuff - the whole frontend menu system and HUD
(with little 3D world map) is done that way.


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: Mark Wayland [mailto:Mwa...@to...]
> Sent: 19 February 2003 03:52
> To: gam...@li...
> Subject: RE: [GD-Consoles] question: Embedded scripting language on
> console
> 
> 
> You pretty much answered it with "create a game object" rather
> than exposing some of your lower level systems. Pretty obvious
> stuff, but some scripters want more and more power - I was just
> wondering at what level you restricted this.
> 
> Mark.
> 
> > -----Original Message-----
> > From: Mick West [mailto:mi...@ne...]
> > Sent: Wednesday, 19 February 2003 2:05 PM
> > To: gam...@li...
> > Subject: RE: [GD-Consoles] question: Embedded scripting language on
> > console
> > 
> > 
> > Well now, that depends on how you look at it.
> > 
> > The meshes are rendered by the rendering engine, but the 
> > object that is
> > comprised of meshes is created and modified by script.  For 
> > example, the
> > skater is comprised of several meshes with various scales, 
> > materials and
> > colors, all of which is controlled by script.
> > 
> > The scripts could not render a mesh in isolation, and I 
> can't see why
> > you would want to.  But they could create a game object that just
> > comprised of a mesh component, which is essentially the same 
> > thing, just
> > with some useful framework. 
> > 
> > Maybe I'm not understanding your question?  
> > 
> > Mick
> > 
> > > -----Original Message-----
> > > From: gam...@li... 
> > > [mailto:gam...@li...] On 
> > > Behalf Of Mark Wayland
> > > Sent: Tuesday, February 18, 2003 6:35 PM
> > > To: gam...@li...
> > > Subject: RE: [GD-Consoles] question: Embedded scripting 
> > > language on console
> > > 
> > > 
> > > Mick,
> > > 
> > > At what level do access your game objects/classes? Can a 
> > > script perform something like rendering a mesh or is it 
> > > completely game object centric?
> > > 
> > > Cheers,
> > > Mark
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Mick West [mailto:mi...@ne...]
> > > > Sent: Wednesday, 19 February 2003 5:15 AM
> > > > To: gam...@li...
> > > > Subject: RE: [GD-Consoles] question: Embedded scripting 
> > language on 
> > > > console
> > > > 
> > > > 
> > > > We (Neversoft) discussed this at some length when starting 
> > > our first 
> > > > game for the PS2.  There was some movement towards using a 
> > > > pre-existing script language (Java was mentioned).  However 
> > > I decided 
> > > > we should roll
> > > > our own, as we'd need control over what it was doing.
> > > > 
> > > > I'm now insanely glad we did this.  The fine control we 
> get over 
> > > > debugging, memory usage and  performance is invaluable.  
> > > Those kind of 
> > > > things may be less of a consideration on the PC, where you 
> > > have memory 
> > > > and CPU cycles to spare.  But on the PS2, I feel that if 
> > > we'd used a 
> > > > pre-existing language, then we would have had a lot more 
> > > trouble than 
> > > > we did.
> > > > 
> > > > It does not take that long either.  We shipped THPS3 less 
> > > than a year 
> > > > after we started programming our scripting language.
> > > > 
> > > > Of course, YMMV, it depends on what you use the script
> > > > language for.  We
> > > > have over 4MB of script, and a lot of the game's high 
> > level logic is
> > > > running in script, and a lot of the high level data is held 
> > > in script
> > > > data structures.
> > > > 
> > > > Anyway, the original questioner intends to generate their 
> > > scripts from 
> > > > UML diagrams.  This approach is inherently doomed, so 
> the actual 
> > > > choice of script language is irrelevant.
> > > > 
> > > > Mick
> > > > 
> > > > > -----Original Message-----
> > > > > From: gam...@li...
> > > > > [mailto:gam...@li...] On 
> > > > > Behalf Of Ron Hay
> > > > > Sent: Tuesday, February 18, 2003 7:04 AM
> > > > > To: gam...@li...
> > > > > Subject: Re: [GD-Consoles] question: Embedded scripting 
> > > > > language on console
> > > > > 
> > > > > 
> > > > > Has anyone on the list actually thought deeply about which
> > > > scripting
> > > > > language they choose?  If
> > > > > so, care to share your thoughts?  We're in the middle of
> > > > choosing the
> > > > > language, and Lua seems
> > > > > to be our current top pick.  The team member that is in 
> > charge of
> > > > > scripting is the type of person
> > > > > that just likes to pick and go, so I'm worried that there 
> > > may be a 
> > > > > better alternative out there...
> > > > > 
> > > > >   Ron
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > -------------------------------------------------------
> > > > > This sf.net email is sponsored by:ThinkGeek
> > > > > Welcome to geek heaven.
> > > > > http://thinkgeek.com/sf
> > > > > _______________________________________________
> > > > > Gamedevlists-consoles mailing list 
> > > > > Gam...@li...
> > > > > 
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
> > > > Archives: 
> > http://sourceforge.net/mailarchive/forum.php?> forum_id=553
> > > > 
> > 
> > > 
> > > 
> > > 
> > > 
> > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf 
> > > _______________________________________________
> > > Gamedevlists-consoles mailing list 
> > > Gam...@li...
> > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
> > > Archives: 
http://sourceforge.net/mailarchive/forum.php?forum_id=553
> > 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an 
> edge. The most comprehensive and flexible code editor you can 
> use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 
> 30-Day Trial. www.slickedit.com/sourceforge 
> _______________________________________________
> Gamedevlists-consoles mailing list 
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
> Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU3
> 



-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Gamedevlists-consoles mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=553


-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Gamedevlists-consoles mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU3

RE: [GD-Consoles] question: Embedded scripting language on consol e

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

Bear in mind that the project is only about a third of the way through, so
we haven't hit any evil crunch times yet.

Porting was pretty simple. You need to override the memory handling stuff to
use your own heaps of course, but that was pretty simple.

You also probably want to give Python its own heap because it does a lot of
12-byte allocations, and if you throw that in the general heap you'll get
horrible fragmentation. We used a stack-based allocator hard-coded to
deliver 12-byte entries - nice and fast, no fragmentation.

Biggest worry is speed on the PS2, because its cache is sooo tiny. But
Python is hardly a speed demon in the best of times, so you need to make
sure you're not using a "heartbeat" system (i.e. calling each object each
frame) - you need a queue-based event system and a C "autonomic" system to
do the mundane work. This is just good programming practice, whatever
language you use, but it's especially important when using a slow scripting
language for your high-level stuff.

SWIG takes a bit of work to integrate into the toolchain, and it's still not
great - it doesn't auto-SWIG headers very well, and we do tend to have to
manually do a "SWIG rebuild" quite often. However, it is pretty fast, so
that's not a big problem, it's just a bit annoying. I suspect we could fix
it easily if we just wrote a makefile (rather than trying to use VC.net's
stuff, which isn't very suited to this sort of stuff).

Benefits are that Python is incredibly easy to code, and we've got some good
stuff up and working very quickly. And of course you get a scripting
language that the designers can use "for free".

Yes, it's a brave step. But we know that if it does all fall down around our
ears and speed is a big problem, we can just port the code back to C, and
only use Python for actual "level scripts" (this switch opens this door,
stuff like that). SWIG is probably the most important bit of the puzzle,
because it means that you can freely mix and match Python and C - they can
access each others members and fucntions quite happily, which means you can
throw code from one to the other in case of speed emergencies. But we've not
had to so far.

Even if the worst happens and no trace of Python survives to the shipped
game (which I very very much doubt), Python is a great prototyping tool.

We were inspired by Humungous's work with Python and SWIG - they've
definately had more experience with this sort of stuff. IIRC, there's a GDC
talk they did on the pros and cons and gotchas. Definately worth checking
out.


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: Andrew Perella [mailto:aj...@eu...]
> Sent: 20 February 2003 10:54
> To: gam...@li...
> Subject: RE: [GD-Consoles] question: Embedded scripting language on
> console
> 
> 
> Hi Tom,
> 	Can you tell us more of your experiences with using 
> python on ps2/xbox/gc?
> What problems have you had? What unexpected benefits did you get? What
> worries do you have at the back of your mind? My feeling is 
> that this was a
> brave step to make at this time.
> Regards,
> Andrew
> 
> 
> Dr Andrew Perella
> Programming Manager
> aj...@eu...
> 
> Eutechnyx Limited is a Deloitte & Touche Fast 50 and a Sunday 
> Times Tech
> Track 100 company.
> 
> Eutechnyx Limited
> Metro Centre East Business Park
> Gateshead
> Tyne & Wear
> NE11 9HU
> UK
> Phone: +44 (0) 191 460 60 60
> Fax: +44 (0) 191 460 22 66
> www.eutechnyx.com

RE: [GD-Consoles] question: Embedded scripting language on console

[Andrew P. <aj...@eu...>]

Thanks Tom.
Its good of you to spend the time giving such a detailed reply.
Given your experience, it is certainly something I will look into here.
Have you know what sort of memory footprint this takes up?
Cheers,
Andrew

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Tom Forsyth
Sent: 20 February 2003 11:23
To: gam...@li...
Subject: RE: [GD-Consoles] question: Embedded scripting language on
console


Bear in mind that the project is only about a third of the way through, so
we haven't hit any evil crunch times yet.

Porting was pretty simple. You need to override the memory handling stuff to
use your own heaps of course, but that was pretty simple.

You also probably want to give Python its own heap because it does a lot of
12-byte allocations, and if you throw that in the general heap you'll get
horrible fragmentation. We used a stack-based allocator hard-coded to
deliver 12-byte entries - nice and fast, no fragmentation.

Biggest worry is speed on the PS2, because its cache is sooo tiny. But
Python is hardly a speed demon in the best of times, so you need to make
sure you're not using a "heartbeat" system (i.e. calling each object each
frame) - you need a queue-based event system and a C "autonomic" system to
do the mundane work. This is just good programming practice, whatever
language you use, but it's especially important when using a slow scripting
language for your high-level stuff.

SWIG takes a bit of work to integrate into the toolchain, and it's still not
great - it doesn't auto-SWIG headers very well, and we do tend to have to
manually do a "SWIG rebuild" quite often. However, it is pretty fast, so
that's not a big problem, it's just a bit annoying. I suspect we could fix
it easily if we just wrote a makefile (rather than trying to use VC.net's
stuff, which isn't very suited to this sort of stuff).

Benefits are that Python is incredibly easy to code, and we've got some good
stuff up and working very quickly. And of course you get a scripting
language that the designers can use "for free".

Yes, it's a brave step. But we know that if it does all fall down around our
ears and speed is a big problem, we can just port the code back to C, and
only use Python for actual "level scripts" (this switch opens this door,
stuff like that). SWIG is probably the most important bit of the puzzle,
because it means that you can freely mix and match Python and C - they can
access each others members and fucntions quite happily, which means you can
throw code from one to the other in case of speed emergencies. But we've not
had to so far.

Even if the worst happens and no trace of Python survives to the shipped
game (which I very very much doubt), Python is a great prototyping tool.

We were inspired by Humungous's work with Python and SWIG - they've
definately had more experience with this sort of stuff. IIRC, there's a GDC
talk they did on the pros and cons and gotchas. Definately worth checking
out.


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: Andrew Perella [mailto:aj...@eu...]
> Sent: 20 February 2003 10:54
> To: gam...@li...
> Subject: RE: [GD-Consoles] question: Embedded scripting language on
> console
>
>
> Hi Tom,
> 	Can you tell us more of your experiences with using
> python on ps2/xbox/gc?
> What problems have you had? What unexpected benefits did you get? What
> worries do you have at the back of your mind? My feeling is
> that this was a
> brave step to make at this time.
> Regards,
> Andrew
>
>
> Dr Andrew Perella
> Programming Manager
> aj...@eu...
>
> Eutechnyx Limited is a Deloitte & Touche Fast 50 and a Sunday
> Times Tech
> Track 100 company.
>
> Eutechnyx Limited
> Metro Centre East Business Park
> Gateshead
> Tyne & Wear
> NE11 9HU
> UK
> Phone: +44 (0) 191 460 60 60
> Fax: +44 (0) 191 460 22 66
> www.eutechnyx.com




-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Gamedevlists-consoles mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=553

_____________________________________________________________________
This e-mail is confidential and may be privileged. It may be read, copied
and used only by the intended recipient. No communication sent by e-mail to
or from Eutechnyx is intended to give rise to contractual or other legal
liability, apart from liability which cannot be excluded under English law.

This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Control Centre.

www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322


_____________________________________________________________________
This e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. No communication sent by e-mail to or from Eutechnyx is intended to give rise to contractual or other legal liability, apart from liability which cannot be excluded under English law. 

This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre. 

www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322

RE: [GD-Consoles] question: Embedded scripting language on console

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

Something that I've found no good explanation of, or even 
a bad explanation for that matter: a good debugger is touted as
one of the pros of integrating an external language for scripting.
But how do you integrate a debugger into the typical
massively multithreaded, realtime environment of a game?

How would a standard Python debugger like your heavily customized
interpreter?

We're using a custom scripting language, and we basically resort
to printf-style debugging, along with a few tricks like "last 100
script lines executed", displaying AI info where the unit's health
is supposed to be shown, etc.

RE: [GD-Consoles] question: Embedded scripting language on consol e

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

The actual memory size is pretty tiny - it's "compiled" to bytecode, and all
the symbol names are referenced, not passed around, so it's fine on that
respects. It was the fragmentation and new/delete performance that was
killing us, but that's all solved with a stack-based allocator.

Speed is the major concern - we'll have to see how we get on with that, and
just how much stuff we'll have to throw over the wall to C. The PS2 is
definately the worst case - the other platforms have bigger caches and
faster CPUs and don't have much of a problem with it.


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: Andrew Perella [mailto:aj...@eu...]
> Sent: 21 February 2003 11:31
> To: gam...@li...
> Subject: RE: [GD-Consoles] question: Embedded scripting language on
> console
> 
> 
> Thanks Tom.
> Its good of you to spend the time giving such a detailed reply.
> Given your experience, it is certainly something I will look 
> into here.
> Have you know what sort of memory footprint this takes up?
> Cheers,
> Andrew
> 
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Tom Forsyth
> Sent: 20 February 2003 11:23
> To: gam...@li...
> Subject: RE: [GD-Consoles] question: Embedded scripting language on
> console
> 
> 
> Bear in mind that the project is only about a third of the 
> way through, so
> we haven't hit any evil crunch times yet.
> 
> Porting was pretty simple. You need to override the memory 
> handling stuff to
> use your own heaps of course, but that was pretty simple.
> 
> You also probably want to give Python its own heap because it 
> does a lot of
> 12-byte allocations, and if you throw that in the general 
> heap you'll get
> horrible fragmentation. We used a stack-based allocator hard-coded to
> deliver 12-byte entries - nice and fast, no fragmentation.
> 
> Biggest worry is speed on the PS2, because its cache is sooo tiny. But
> Python is hardly a speed demon in the best of times, so you 
> need to make
> sure you're not using a "heartbeat" system (i.e. calling each 
> object each
> frame) - you need a queue-based event system and a C 
> "autonomic" system to
> do the mundane work. This is just good programming practice, whatever
> language you use, but it's especially important when using a 
> slow scripting
> language for your high-level stuff.
> 
> SWIG takes a bit of work to integrate into the toolchain, and 
> it's still not
> great - it doesn't auto-SWIG headers very well, and we do 
> tend to have to
> manually do a "SWIG rebuild" quite often. However, it is 
> pretty fast, so
> that's not a big problem, it's just a bit annoying. I suspect 
> we could fix
> it easily if we just wrote a makefile (rather than trying to 
> use VC.net's
> stuff, which isn't very suited to this sort of stuff).
> 
> Benefits are that Python is incredibly easy to code, and 
> we've got some good
> stuff up and working very quickly. And of course you get a scripting
> language that the designers can use "for free".
> 
> Yes, it's a brave step. But we know that if it does all fall 
> down around our
> ears and speed is a big problem, we can just port the code 
> back to C, and
> only use Python for actual "level scripts" (this switch opens 
> this door,
> stuff like that). SWIG is probably the most important bit of 
> the puzzle,
> because it means that you can freely mix and match Python and 
> C - they can
> access each others members and fucntions quite happily, which 
> means you can
> throw code from one to the other in case of speed 
> emergencies. But we've not
> had to so far.
> 
> Even if the worst happens and no trace of Python survives to 
> the shipped
> game (which I very very much doubt), Python is a great 
> prototyping tool.
> 
> We were inspired by Humungous's work with Python and SWIG - they've
> definately had more experience with this sort of stuff. IIRC, 
> there's a GDC
> talk they did on the pros and cons and gotchas. Definately 
> worth checking
> out.
> 
> 
> 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: Andrew Perella [mailto:aj...@eu...]
> > Sent: 20 February 2003 10:54
> > To: gam...@li...
> > Subject: RE: [GD-Consoles] question: Embedded scripting language on
> > console
> >
> >
> > Hi Tom,
> > 	Can you tell us more of your experiences with using
> > python on ps2/xbox/gc?
> > What problems have you had? What unexpected benefits did 
> you get? What
> > worries do you have at the back of your mind? My feeling is
> > that this was a
> > brave step to make at this time.
> > Regards,
> > Andrew
> >
> >
> > Dr Andrew Perella
> > Programming Manager
> > aj...@eu...
> >
> > Eutechnyx Limited is a Deloitte & Touche Fast 50 and a Sunday
> > Times Tech
> > Track 100 company.
> >
> > Eutechnyx Limited
> > Metro Centre East Business Park
> > Gateshead
> > Tyne & Wear
> > NE11 9HU
> > UK
> > Phone: +44 (0) 191 460 60 60
> > Fax: +44 (0) 191 460 22 66
> > www.eutechnyx.com
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Gamedevlists-consoles mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=553
> 
> _____________________________________________________________________
> This e-mail is confidential and may be privileged. It may be 
> read, copied
> and used only by the intended recipient. No communication 
> sent by e-mail to
> or from Eutechnyx is intended to give rise to contractual or 
> other legal
> liability, apart from liability which cannot be excluded 
> under English law.
> 
> This message has been checked for all known viruses by Star Internet
> delivered through the MessageLabs Virus Control Centre.
> 
> www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322
> 
> 
> _____________________________________________________________________
> This e-mail is confidential and may be privileged. It may be 
> read, copied and used only by the intended recipient. No 
> communication sent by e-mail to or from Eutechnyx is intended 
> to give rise to contractual or other legal liability, apart 
> from liability which cannot be excluded under English law. 
> 
> This message has been checked for all known viruses by Star 
> Internet delivered through the MessageLabs Virus Control Centre. 
> 
> www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Gamedevlists-consoles mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=553
> 

RE: [GD-Consoles] question: Embedded scripting language on consol e

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

Python is a strange case, because everything is incredibly introspective -
every Python class knows what its members are, and you can simply ask it. In
fact, that's what a lot of Python programs use as a core feature - you don't
check what class things are, you just ask them if they have a certain member
function/variable - because you can construct classes at runtime (i.e. add
and remove members dynamically). Coming from an assembly/C background, this
messed with my head a bit before I learned to stop worrying and love the
snake :-)

So the Python debugger is written in Python, and it's not a normal "take
over the machine" debugger - it doesn't "run" the code under scrutiny, it
just runs "beside" it - they're both just different programs both running
under the same bytecode interpreter, and one happens to know about the
other. It's a fairly crazy concept, but it works wonderfully.


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: Ivan-Assen Ivanov [mailto:as...@ha...]
> Sent: 21 February 2003 11:52
> To: gam...@li...
> Subject: RE: [GD-Consoles] question: Embedded scripting language on
> console
> 
> 
> Something that I've found no good explanation of, or even 
> a bad explanation for that matter: a good debugger is touted as
> one of the pros of integrating an external language for scripting.
> But how do you integrate a debugger into the typical
> massively multithreaded, realtime environment of a game?
> 
> How would a standard Python debugger like your heavily customized
> interpreter?
> 
> We're using a custom scripting language, and we basically resort
> to printf-style debugging, along with a few tricks like "last 100
> script lines executed", displaying AI info where the unit's health
> is supposed to be shown, etc.
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Gamedevlists-consoles mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=553
> 

Re: [GD-Consoles] question: Embedded scripting language on console

[Ron H. <rh...@cy...>]

Has anyone on the list actually thought deeply about which scripting 
language they choose?  If
so, care to share your thoughts?  We're in the middle of choosing the 
language, and Lua seems
to be our current top pick.  The team member that is in charge of 
scripting is the type of person
that just likes to pick and go, so I'm worried that there may be a 
better alternative out there...

  Ron

Re: [GD-Consoles] question: Embedded scripting language on console

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

Ron Hay wrote:
> Has anyone on the list actually thought deeply about which scripting
> language they choose?  If
> so, care to share your thoughts?  We're in the middle of choosing the
> language, and Lua seems
> to be our current top pick.  The team member that is in charge of
> scripting is the type of person
> that just likes to pick and go, so I'm worried that there may be a
> better alternative out there...

Well, I would not like to use a generic language to make in-game scripting
language. Instead I would better make a dedicated small minimalistic
language specially made for that particular game.

The reason is that I think that asking to designers to use some generic
language with non intuitive syntax (what are these ";" "{" and "}" ???),
very non expressive content, side effects... is not really a good choice.


    Mickael Pointier

RE: [GD-Consoles] question: Embedded scripting language on console

[Mick W. <mi...@ne...>]

We (Neversoft) discussed this at some length when starting our first
game for the PS2.  There was some movement towards using a pre-existing
script language (Java was mentioned).  However I decided we should roll
our own, as we'd need control over what it was doing.

I'm now insanely glad we did this.  The fine control we get over
debugging, memory usage and  performance is invaluable.  Those kind of
things may be less of a consideration on the PC, where you have memory
and CPU cycles to spare.  But on the PS2, I feel that if we'd used a
pre-existing language, then we would have had a lot more trouble than we
did.

It does not take that long either.  We shipped THPS3 less than a year
after we started programming our scripting language.

Of course, YMMV, it depends on what you use the script language for.  We
have over 4MB of script, and a lot of the game's high level logic is
running in script, and a lot of the high level data is held in script
data structures.

Anyway, the original questioner intends to generate their scripts from
UML diagrams.  This approach is inherently doomed, so the actual choice
of script language is irrelevant.

Mick

> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Ron Hay
> Sent: Tuesday, February 18, 2003 7:04 AM
> To: gam...@li...
> Subject: Re: [GD-Consoles] question: Embedded scripting 
> language on console
> 
> 
> Has anyone on the list actually thought deeply about which scripting 
> language they choose?  If
> so, care to share your thoughts?  We're in the middle of choosing the 
> language, and Lua seems
> to be our current top pick.  The team member that is in charge of 
> scripting is the type of person
> that just likes to pick and go, so I'm worried that there may be a 
> better alternative out there...
> 
>   Ron
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf 
> _______________________________________________
> Gamedevlists-consoles mailing list 
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
> Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=553
> 

Re: [GD-Consoles] question: Embedded scripting language on console

[Ron H. <rh...@cy...>]

Mick West wrote:

>Anyway, the original questioner intends to generate their scripts from
>UML diagrams.  This approach is inherently doomed, so the actual choice
>of script language is irrelevant.
>  
>

Heh.  One of my peeves is when people have the "brilliant" idea to 
create a "graphical method to
express software".  Last I checked, text *was* a graphical method to 
express software...

Re: [GD-Consoles] question: Embedded scripting language on console

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

There's also a middle-ground approach you might consider, and I would be
curious as to other peoples experience in implenting, and that is using
libraries.  In our case the programmers are doing the scripting, performance
is a high priority, and we can't compile the game code into the engine
because there is too much.  Our plan is to build a lib from normal C source
for the target platform and runtime link it (similar to CodeWarrior overlays
on PS2).  This translates to ELF for GC and PS2 and COFF for PC.  It is
pretty straightforward so far, but memory handling for function variables is
looking like it will give us some headaches.  We may impose some rules on
how memory is used and declared to solve that, but has anybody implemented
this before?
Brett
GameBrains

----- Original Message -----
From: "Ron Hay" <rh...@cy...>
To: <gam...@li...>
Sent: Tuesday, February 18, 2003 11:03 PM
Subject: Re: [GD-Consoles] question: Embedded scripting language on console


> Has anyone on the list actually thought deeply about which scripting
> language they choose?  If
> so, care to share your thoughts?  We're in the middle of choosing the
> language, and Lua seems
> to be our current top pick.  The team member that is in charge of
> scripting is the type of person
> that just likes to pick and go, so I'm worried that there may be a
> better alternative out there...
>
>   Ron
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-consoles mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=553