Thread: [GD-General] Games using off-the-shelf scripting languages other than Python or Lua?
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: Noel L. <nl...@co...> - 2004-08-16 15:14:44
|
Just curious, does anybody know of any commercial games (PC and console) using off-the-shelf scripting languages other than Python and Lua? (there are plenty of those) Specifically, is anybody using Small, Perl, Ruby, or Javascript in games? Thanks. --Noel Games from Within http://www.gamesfromwithin.com |
|
From: <phi...@pl...> - 2004-08-16 20:57:24
|
> Specifically, is anybody using Small, Perl, Ruby, or Javascript in games? Perl holds our pipeline together, but that's about it. Cheers, Phil |
|
From: Thatcher U. <tu...@tu...> - 2004-08-17 15:55:46
|
On Aug 16, 2004 at 08:14 -0700, Noel Llopis wrote: > > Specifically, is anybody using Small, Perl, Ruby, or Javascript in games? The Small site lists a couple of games, "Baldur's Gate: Dark Alliance" and "Champions of Norrath: Realms of Everquest". http://www.compuphase.com/small.htm -- Thatcher Ulrich http://tulrich.com |
|
From: mike w. <mi...@ge...> - 2004-08-18 07:47:45
|
we have used simkin (www.simkin.co.uk) for our scripting language for several years, it is a c-like language, very nice, simple to use and easily extensible. it is also cross-platform and can be integrated into many languages, including embedded devices and more. mike w www.realityfactory.ca Noel Llopis wrote: > Just curious, does anybody know of any commercial games (PC and console) using > off-the-shelf scripting languages other than Python and Lua? (there are > plenty of those) > > Specifically, is anybody using Small, Perl, Ruby, or Javascript in games? > Thanks. > > > --Noel > Games from Within > http://www.gamesfromwithin.com |
|
From: Zach B. <za...@za...> - 2004-08-19 02:31:10
|
mike wuetherick wrote: > we have used simkin (www.simkin.co.uk) for our scripting language for > several years, it is a c-like language, very nice, simple to use and > easily extensible. > > it is also cross-platform and can be integrated into many languages, > including embedded devices and more. Are you actually using it under the terms of the LGPL? The LGPL is a pretty demanding license to attach to a scripting language and in particular to a language that might otherwise be suitable for being embedded in a commercial game. To give my personal experience, I'm a Ruby fan but it's far too slow and large to consider embedding. JavaScript would be nice but I do console work and even stripped to the bone it is too large. I've evaluated Lua. It's okay, I think, and very good in theory, but the code is really comment-deficient, the invocation overhead is not low enough for me, and the syntax is just different enough from C that bugs like leaving out a "then" after an if statement would seem common. But it is closer than anything else to the kind of language you would typically want to embed in a commercial game, except maybe Small. I've rolled my own scripting languages and the control is worth it. It's always been for "little languages" rather than full-blown scripting languages. The two huge abilities I gain with any scripting language (from Ruby to formatting strings) are representing behavior as data and specifying behavior with problem-specific semantics. An off-the-shelf language that happened to be suitable would be great, but my needs are always too specific. But just gaining those two abilities tends to be enough unless the game needs widespread scripting or deep scripting, which hasn't happened on any games I've worked on. A need for widespread scripting suggests that a more scripty language (Lisp, say) should be at the core of the game architecture in order to minimize inevitable cross-language hangups. A need for deep scripting suggests the use of a scripting language that meets some very specific needs, which may make it difficult to use an off-the-shelf scripting language. So as far as I can see, it all comes down to the more mundane issues -- memory, memory, memory, speed, C/C++ interface, familiar syntax -- rather than language features. I don't foresee anyone embedding a language like Ruby in a commercial game. -- Zach. |
|
From: tweety <mi...@sy...> - 2004-08-20 00:59:47
|
What about java? I've seen a few games using it... ---------------------------------- Peace and love, Tweety mi...@sy... - twe...@us... YahooID: tweety_04_01 > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...] On > Behalf Of Zach Baker > Sent: August 18, 2004 10:31 PM > To: gam...@li... > Subject: Re: [GD-General] Games using off-the-shelf scripting > languages other than Python or Lua? > > mike wuetherick wrote: > > we have used simkin (www.simkin.co.uk) for our scripting > language for > > several years, it is a c-like language, very nice, simple to use and > > easily extensible. > > > > it is also cross-platform and can be integrated into many languages, > > including embedded devices and more. > > Are you actually using it under the terms of the LGPL? The LGPL is a > pretty demanding license to attach to a scripting language and in > particular to a language that might otherwise be suitable for being > embedded in a commercial game. > > To give my personal experience, I'm a Ruby fan but it's far > too slow and > large to consider embedding. JavaScript would be nice but I > do console > work and even stripped to the bone it is too large. > > I've evaluated Lua. It's okay, I think, and very good in theory, but > the code is really comment-deficient, the invocation overhead is not > low enough for me, and the syntax is just different enough from C that > bugs like leaving out a "then" after an if statement would > seem common. > But it is closer than anything else to the kind of language you would > typically want to embed in a commercial game, except maybe Small. > > I've rolled my own scripting languages and the control is worth it. > It's always been for "little languages" rather than > full-blown scripting > languages. The two huge abilities I gain with any scripting language > (from Ruby to formatting strings) are representing behavior > as data and > specifying behavior with problem-specific semantics. An off-the-shelf > language that happened to be suitable would be great, but my needs are > always too specific. But just gaining those two abilities tends to be > enough unless the game needs widespread scripting or deep scripting, > which hasn't happened on any games I've worked on. > > A need for widespread scripting suggests that a more scripty language > (Lisp, say) should be at the core of the game architecture in order to > minimize inevitable cross-language hangups. A need for deep scripting > suggests the use of a scripting language that meets some very specific > needs, which may make it difficult to use an off-the-shelf scripting > language. So as far as I can see, it all comes down to the more > mundane issues -- memory, memory, memory, speed, C/C++ interface, > familiar syntax -- rather than language features. I don't foresee > anyone embedding a language like Ruby in a commercial game. > > -- Zach. > > > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=557 > |
|
From: mike w. <mi...@ge...> - 2004-08-21 05:26:49
|
Zach Baker wrote: > Are you actually using it under the terms of the LGPL? The LGPL is a > pretty demanding license to attach to a scripting language and in > particular to a language that might otherwise be suitable for being > embedded in a commercial game. what about the lgpl do you think would cause problems for a commercial game? you don't have to provide your scripts, you don't have to provide the code for the application you created with simkin, you just have to provide any changes you make to simkin itself - which in our case has been almost zero. in any case, the game engine itself is open-source under an mit license so it the source is always available online anyways. not sure what the problem here would be, the source has been released properly, we have commercial teams using the engine and for most requirements, you wouldn't need to modify the simkin portions of the code even if you wanted to add new scripting commands or modify the gameshell itself... mike w www.realityfactory.ca |
|
From: Patrick D. <pa...@wa...> - 2004-08-21 16:29:16
|
I think it is well understood that any modifications made to the library
must be distributed under LGPL.
However, one of the primary goals of the LGPL is to ensure that a user
can modify the library covered by the LPGL and use those modifications
with the application. The requirements of the LGPL make it the
developer's responsibility to ensure the user has access to the
necessary materials to make those modifications and relink them with the
application.
Section 6 of the license covers the distribution requirements of a "work
that uses the library" that has been linked with the library. In
particular, the distribution must:
- permit the user to modify and reverse engineer the game
- give prominent notice that the library is used and covered by LGPL
- include a copy of the LGPL license
- for every copyright notice displayed by the game, also include
the copyright notice for the library and information about how
to obtain the LGPL license
- do one of the following:
1. include complete source code for the library, source code
and/or object code for the game, source code and/or object
code for all other libraries used
2. use dynamic linking for access the library
3. include a written offer to give a user the material in
choice #1
- and if the distribution is an executable:
- include any data and utility programs needed for
reproducing the executable from it (exception: materials
normally included with the OS do not need to be included)
I expect most of us deliver games as an executable, so to comply with
that last requirement, I think you will need to include .obj files and
any other .lib files that you statically link against.
Your game may use a middleware library with a license that does not
permit redistribution or reverse engineering. If this is the case, then
the LGPL is explicit: you cannot use the the two libraries in the same
executable.
The problem may get worse for console developers. Since development
kits are not normally distributed or obtainable by end users, I think
you would need to provide one to be compliant.
I'm not a lawyer, so my interpretations may be incorrect. However,
there are enough issues here to make LGPL an unattractive license for
commerical developers.
mike wuetherick wrote:
> Zach Baker wrote:
>
>> Are you actually using it under the terms of the LGPL? The LGPL is a
>> pretty demanding license to attach to a scripting language and in
>> particular to a language that might otherwise be suitable for being
>> embedded in a commercial game.
>
>
> what about the lgpl do you think would cause problems for a commercial
> game? you don't have to provide your scripts, you don't have to provide
> the code for the application you created with simkin, you just have to
> provide any changes you make to simkin itself - which in our case has
> been almost zero.
>
> in any case, the game engine itself is open-source under an mit license
> so it the source is always available online anyways.
>
> not sure what the problem here would be, the source has been released
> properly, we have commercial teams using the engine and for most
> requirements, you wouldn't need to modify the simkin portions of the
> code even if you wanted to add new scripting commands or modify the
> gameshell itself...
>
> mike w
> www.realityfactory.ca
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
|
|
From: Thatcher U. <tu...@tu...> - 2004-08-22 00:57:28
|
On Aug 20, 2004 at 10:26 -0700, mike wuetherick wrote: > Zach Baker wrote: > >Are you actually using it under the terms of the LGPL? The LGPL is a > >pretty demanding license to attach to a scripting language and in > >particular to a language that might otherwise be suitable for being > >embedded in a commercial game. > > what about the lgpl do you think would cause problems for a commercial > game? It's a big problem for console games. For PC it's just an annoyance I guess. -- Thatcher Ulrich http://tulrich.com |
|
From: Tham <th...@ga...> - 2004-08-29 05:41:55
|
Hi, Probably this is an age old question. If so please point me to the correct place if this topic is already discussed in great length. I would like to know what are the techniques and its pros/cons that are used to produce complex in game GUI (such as those found in Star Wars Galaxy) with trees, split panes, child windows etc. Will appreciate any ideas, urls, advice... Many thanks tham |
|
From: Javier A. <ja...@py...> - 2004-08-30 07:02:16
|
- Get started with it. - Use an existing UI framework like Windows, the MFC, Forms.NET as a guideline. - Make sure the layout is data-driven through a script. - Separate description of visual appearance (styles) from description of layout. - Don't make its behaviour scriptable the first time around, but design with that in mind. - Be ready to rewrite it halfway through. Tham wrote: > Probably this is an age old question. If so please point me to the > correct place if this topic is already discussed in great length. > > I would like to know what are the techniques and its pros/cons that > are used to produce complex in game GUI (such as those found in Star > Wars Galaxy) with trees, split panes, child windows etc. > > Will appreciate any ideas, urls, advice... -- Javier Arevalo Pyro Studios |
|
From: Ignacio <cas...@ya...> - 2004-09-13 08:56:45
|
If you really need a complex GUI, an option that may be worth to consider i= s=20 to use any of the existing comercial gui libraries that have proven to work= =20 well and have nice tools to design the ui layout. For example, Qt4 provides= =20 different painter engines, one of them implemented using OpenGL. You can al= so=20 provide your own implementation of QPaintEngine using DirectX, you would ju= st=20 have to write some simple drawing routines. You would also have to implemen= t=20 a custom style engine so to adapt the ui to the look&feel of your game. http://doc.trolltech.com/4.0/qpaintengine.html http://doc.trolltech.com/4.0/qstyle.html =2D-=20 Ignacio Casta=F1o cas...@ya... On Saturday 28 August 2004 22:41, Tham wrote: > Hi, > > Probably this is an age old question. If so please point me to the correct > place if this topic is already discussed in great length. > > I would like to know what are the techniques and its pros/cons that are > used to produce complex in game GUI (such as those found in Star Wars > Galaxy) with trees, split panes, child windows etc. > > Will appreciate any ideas, urls, advice... > > Many thanks > tham |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X