| |
From: Shawn Hargreaves <shargreaves@cl...> - 2004-08-04 14:56
|
Once you move past core things like searching, sorting, and hashing, though,
libraries become rather specialised.
One of the great strengths of Python is the huge range of available
libraries, which makes it trivial to do things like parse an incoming CGI
request, talk to a database, manipulate some XML, then dynamically generate
a bitmap based on the resulting data and pipe it over an HTTP connection.
Lua doesn't have libraries for any of those things, and writing them
yourself would clearly be a huge task.
But that doesn't apply if your goal is to script AI or game logic. In that
sort of embedded situation, you are mostly using the scripts for control
flow and basic data structures, with library support for things like
pathfinding generally being provided by the C++ side of your game.
My argument is that, although Python comes with far more extensive standard
libraries, for embedded use they should be judged on the core syntax rather
than the availability of an XML module. And in fact, the cores of Python and
Lua are almost identical!
--
Shawn Hargreaves
Climax Brighton
> -----Original Message-----
> From: gdalgorithms-list-admin@lists.sourceforge.net />
> [mailto:gdalgorithms-list-admin@lists.sourceforge.net]On Behalf Of
> Matthew MacLaurin
> Sent: 04 August 2004 15:45
> To: gdalgorithms-list@lists.sourceforge.net />
> Subject: RE: [Algorithms] My first scripting engine
>
>
> As with all languages, the libraries are going to make the biggest
> difference...unless you really like rewriting the classics of computer
> programming...over and over....
>
> -----Original Message-----
> From: gdalgorithms-list-admin@lists.sourceforge.net />
> [mailto:gdalgorithms-list-admin@lists.sourceforge.net] On Behalf Of
> Shawn Hargreaves
> Sent: Wednesday, August 04, 2004 3:47 AM
> To: 'gdalgorithms-list@lists.sourceforge.net' />
> Subject: RE: [Algorithms] My first scripting engine
>
> Having spent a while looking at both Lua and Python, I don't actually
> think
> there is much to choose between them in terms of power.
>
> Lua is marginally smaller/cleaner, while Python is slightly bigger and
> offers more types of construct, but if you strip out the
> various library
> modules (as would typically be the case when embedding in a game), the
> remaining differences are nowhere near as big as they initial appear.
>
> In fact, Python without all the standard Python libraries is
> remarkably
> small and clean, while if Lua had an equivalent to the enormous Python
> library set, I think the result would look and feel very close to
> Python!
>
> Both offer first order function objects, powerful hashed containers,
> user
> defined iterators, a reasonable level of object orientation, and can
> easily
> be extended with C++ types that behave like natural built-in features.
>
> The most significant differences that I've come across so far are:
>
> Lua is potentially slightly faster, because it holds numeric
> data types
> on
> the stack, while in Python everything is an object. In practice the
> difference is negligible, though.
>
> Lua is slightly smaller.
>
> Python has a very nice slicing syntax for list/string manipulation,
> which
> Lua lacks.
>
> Python has more flexible syntax for optional or named function
> parameters.
> You can emulate such things in Lua using a table, but the syntax isn't
> so
> nice.
>
> Lua has better syntax for defining anonymous functions and closures:
> nice if
> you are using a lot of callbacks or functional programming styles. The
> Python lambda keyword is horribly restrictive in comparison.
>
> Python has three main data types: lists, dictionaries, and tuples. Lua
> has
> only one: the table, which is internally implemented as
> either an array
> or a
> hash table (or both) depending on the type of key. Tough to
> say which is
> better: Python gives the programmer more control, but if you
> scripts are
> going to be written by non-programmers, the Lua approach
> might be better
> because there is less to learn (always use a table, and it will do the
> right
> thing behind the scenes).
>
>
> --
> Shawn Hargreaves
> Climax Brighton
>
>
>
>
> > -----Original Message-----
> > From: gdalgorithms-list-admin@lists.sourceforge.net />
> > [mailto:gdalgorithms-list-admin@lists.sourceforge.net]On
> Behalf Of Tom
> > Forsyth
> > Sent: 03 August 2004 17:47
> > To: gdalgorithms-list@lists.sourceforge.net />
> > Subject: RE: [Algorithms] My first scripting engine
> >
> >
> > For simple stuff, Lua seems tty good. For stuff like
> Goran's case,
> you
> > may want to look at Python. Python's not as quick as Lua, but it's
> absurdly
> > powerful.
> >
> > TomF.
> >
> > > -----Original Message-----
> > > From: gdalgorithms-list-admin@lists.sourceforge.net
> > > [mailto:gdalgorithms-list-admin@lists.sourceforge.net] On
> > > Behalf Of Goran Zoricic
> > > Sent: 03 August 2004 10:17
> > > To: gdalgorithms-list@lists.sourceforge.net />
> > > Subject: Re: [Algorithms] My first scripting engine
> > >
> > >
> > > Hi all!
> > >
> > > This is my first appearance here (i've been lurking for a
> > > while), so an
> > > introdution is in order: i'm a programmer at Croteam, and my
> > > specialization
> > > is networking and compilers. I also handle some related parts
> > > of engine
> > > core, as well as the game menu system.
> > >
> > > Here at Croteam, we have rolled out our own scripting
> > > language that includes
> > > most basic features of C++. It doesn't support templates, multiple
> > > inheritance, function and operator overloads and
> > > private/protected class
> > > members. Our scripting language was intended to be used for
> > > implementation
> > > of AI - monsters, items, NPCs... As such, we implemented a
> > > lot of features
> > > that C++ doesn't have - states (each object is a state
> > > machine), latent
> > > functions (do not return immediately, but can span any number
> > > of frames),
> > > specification of entity components (models, textures...),
> > > integration with
> > > C++ (transparent calls to functions implemented in C++,
> > > inheritance from C++
> > > classes, compilation of parts of script code with the C++
> > > compiler...).
> > > Also, we have integrated the script language and virtual
> > > machine with our
> > > networking system and with all level design tools, making it
> > > very easy to
> > > manipulate all game objects in all circumstances.
> > >
> > > After doing all this work, my strong recomendation is that
> > > you should very
> > > carefully weight all pros and cons of using an existing
> > > language vs writing
> > > your own scripting engine. I think that the main factor here
> > > is time - it
> > > takes a lot of time to implement a complex and powerfull
> > > scripting engine.
> > > Rewards are great, since it can do exactly what you need, and
> > > do it in such
> > > a way that is best for you. On the other hand, it takes a
> > > huge ammount of
> > > work to do properly, and takes manpower away from other
> > > tasks. For us, the
> > > decision to write our own script system turned out to be a
> > great one,
> > > because the time and work invested in it will repay with
> > > interest while
> > > puting the game together.
> > >
> > > To conclude: if you can find an existing solution that will
> > > satisfy your
> > > needs (i.e. Lua), use it. Also, if you don't have time or
> > > manpower to create
> > > your own scripting engine, also use an existing one. If you
> > > can afford it,
> > > you think it'll be worth it, and have the neccessary
> > > expertise, you will do
> > > well to write your own scripting engine that will satisfy all
> > > your needs.
> > >
> > > Cheers,
> > >
> > > Goran
> > >
> > > ----------------------------------------------------
> > > Goran Zoricic, programmer, Croteam.
> > >
> > >
> > > ----- Original Message -----
> > > From: "CAVEY GERARD" <GERARD.CAVEY@sgam.com>
> > > To: <gdalgorithms-list@lists.sourceforge.net>
> > > Sent: Tuesday, August 03, 2004 8:36 AM
> > > Subject: [Algorithms] My first scripting engine
> > >
> > >
> > > > Hello
> > > >
> > > > Right now i m trying to implement my first script interter.
> > > > I know there s lot of libs and scripting languages out
> > there but i m
> > > > just interested in the how-to.
> > > > Could someone guide my first steps in this world because i
> > > really have no
> > > > idea
> > > > how to do it .I m looking for an elegant solution to solve
> > > the procedure
> > > > adress
> > > > (these procedures are classes menbers because of the OO
> > design of my
> > > > engine).
> > > > I found that the naive way with lot of "if" statements is
> > > ok when you have
> > > > only few and non structured commands but my objective is
> > > to reflect the
> > > > engine structure.
> > > > For example i wish i could use script commands like the folowing
> > > > "Renderer.Batch.UploadToVB() "
> > > > "Renderer.SetShader ( ...)"
> > > > "Renderer.Draw()"
> > > > etc...
> > > > I can achieve it easily by writing lines like the
> > folowing for EACH
> > > > instruction
> > > > switch(token_count) {
> > > > case 3:
> > > > if(!strcmp(token1,"Renderer")&&!strcmp(token2,"Batch")&&
> > > > !strcmp(token3,"UploadToVB"))
> > > > Renderer.Batch.UploadToVB(); etc...
> > > > but it seems very ugly and very heavy
> > > > no doubt there s a much better solution.
> > > > Do you have any orientations about my little problem?
> > > >
> > > > Regards
> > > > GC.
> > > >
> > > >
> > > >
> > > **************************************************************
> > > ***********
> > > > Ce message et toutes les pieces jointes (ci-as le
> > "message") sont
> > > > confidentiels et etablis a l'intention exclusive de ses
> > > destinataires.
> > > > Toute utilisation ou diffusion non autorisee est interdite.
> > > > Tout message electronique est susceptible d'alteration.
> > > > SG Asset Management et ses filiales declinent toute
> > > responsabilite au
> > > titre
> > > > de ce message s'il a ete altere, deforme ou falsifie.
> > > >
> > > > Decouvrez l'offre et les services de SG Asset Management
> > sur le site
> > > > www.sgam.fr
> > > >
> > > > ********
> > > >
> > > > This message and any attachments (the "message") are
> > > confidential and
> > > > intended solely for the addressees.
> > > > Any unauthorised use or dissemination is prohibited.
> > > > E-mails are susceptible to alteration.
> > > > Neither SG Asset Management nor any of its subsidiaries or
> > > affiliates
> > > shall
> > > > be liable for the message if altered, changed or falsified.
> > > >
> > > >
> > > **************************************************************
> > > ***********
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.Net email is sponsored by OSTG. Have you noticed
> > > the changes on
> > > > Linux.com, ITManagersJournal and NewsForge in the past few
> > > weeks? Now,
> > > > one more big change to announce. We are now OSTG- Open
> > > Source Technology
> > > > Group. Come see the changes on the new OSTG site. www.ostg.com
> > > > _______________________________________________
> > > > GDAlgorithms-list mailing list
> > > > GDAlgorithms-list@lists.sourceforge.net />
> > > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> > > > Archives:
> > > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188
> > > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by OSTG. Have you noticed the
> > > changes on
> > > Linux.com, ITManagersJournal and NewsForge in the past few
> > weeks? Now,
> > > one more big change to announce. We are now OSTG- Open Source
> > > Technology
> > > Group. Come see the changes on the new OSTG site. www.ostg.com
> > > _______________________________________________
> > > GDAlgorithms-list mailing list
> > > GDAlgorithms-list@lists.sourceforge.net />
> > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> > > Archives:
> > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by OSTG. Have you noticed the
> > changes on
> > Linux.com, ITManagersJournal and NewsForge in the past few
> weeks? Now,
> > one more big change to announce. We are now OSTG- Open Source
> > Technology
> > Group. Come see the changes on the new OSTG site. www.ostg.com
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDAlgorithms-list@lists.sourceforge.net />
> > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=6188
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the
> changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source
> Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-list@lists.sourceforge.net />
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=6188
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the
> changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source
> Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-list@lists.sourceforge.net />
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_ida88
>
|
|